What is agile?

• Agile is a process that allows a team to

more efficiently manage a project by
breaking it down into several stages,
each of which allows for consistent
collaboration with stakeholders to
promote steady improvements at every
stage.
• In software development, agile practices
involve discovering requirements and
developing solutions through the
collaborative effort of self-organizing
and cross-functional teams and their
customer/end user.
Some of the real life examples of agile model:

• Restaurant orders:
• Preparation of some of the food before
opening the shop (sprint planning)
• continuous delivery of orders (adhoc stories)
• number of successful orders (velocity)
• cricket team:
• Run rate (velocity)
• team (scrum team self sufficient)
• over (sprint length)
• captain/ coach (scrum master)
What are the 12 principles of agile?

• Customer satisfaction
• Early and continuous delivery
• Embrace change
• Frequent delivery
• Collaboration of businesses and developers
• Motivated individuals
• Face-to-face conversation
• Functional products
• Technical excellence
• Simplicity
• Self-organized teams
• Regulation, reflection and adjustment
Agile methodology
• Agile methodology is a type of project management process, mainly used
for software development, where demands and solutions evolve through
the collaborative effort of self-organizing and cross-functional teams and
their customers.
• Agile software development refers to a group of software development
methodologies based on iterative development, where requirements and
solutions evolve through collaboration between self-organizing cross-
functional teams. Agile methods or Agile processes generally promote a
disciplined project management process that encourages frequent
inspection and adaptation, a leadership philosophy that encourages
teamwork, self-organization and accountability, a set of engineering best
practices intended to allow for rapid delivery of high-quality software, and
a business approach that aligns development with customer needs and
company goals.
Examples of Agile Methodology

• Agile Scrum Methodology.

• Lean Software Development.
• Kanban.
• Extreme Programming (XP)
• Crystal.
• Dynamic Systems Development Method (DSDM)
• Feature Driven Development (FDD)
scrum
• The software development term scrum was first used in a 1986 paper titled "The
New Product Development Game". The term is borrowed from rugby, where
a scrum is a formation of players. The term scrum was chosen by the paper's
authors because it emphasizes teamwork.
• Scrum is a subset of Agile. It is a lightweight process framework for agile
development, and the most widely-used one.
• Scrum is an agile project management methodology or framework used primarily
for software development projects with the goal of delivering
new software capability every 2-4 weeks.

• Scrum is an agile framework for developing, delivering, and sustaining complex

products, with an initial emphasis on software development, although it has been
used in other fields including research, sales, marketing and advanced
technologies.
Agile scrum methodology
• Agile scrum methodology is a project management system that relies on
incremental development. Each iteration consists of two- to four-week sprints,
where each sprint's goal is to build the most important features first and come
out with a potentially deliverable product. More features are built into the
product in subsequent sprints and are adjusted based on stakeholder and
customer feedback between sprints.
• Whereas other project management methods emphasize building an entire
product in one iteration from start to finish, agile scrum methodology focuses on
delivering several iterations of a product to provide stakeholders with the highest
business value in the least amount of time.
• Agile scrum methodology has several benefits. First, it encourages products to be
built faster, since each set of goals must be completed within each sprint's time
frame. It also requires frequent planning and goal setting, which helps the scrum
team focus on the current sprint's objectives and increase productivity.
Lifecycle of Scrum:

• Sprint:
A Sprint is a time-box of one month or less. A new Sprint starts
immediately after the completion of the previous Sprint.
• Release:
When the product is completed then it goes to the Release stage.
• Sprint Review:
If the product still have some non-achievable features then it will
be checked in this stage and then the product is passed to the
Sprint Retrospective stage.
• Sprint Retrospective:
In this stage quality or status of the product is checked.
• Product Backlog:
According to the prioritize features the product is organized.
• Sprint Backlog:
Sprint Backlog is divided into two parts Product assigned features
to sprint and Sprint planning meeting.
How Scrum Works

• In a rugby scrum, all the players literally put their heads together. When it comes to
software development, a scrum can be characterized by developers putting their heads
together to address complex problems.
• Scrum software development starts with a wish list of features — a.k.a. a product
backlog. The team meets to discuss:
• The backlog.
• What still needs to be completed.
• How long it will take.
• Scrum relies on an agile software development concept called sprints:
• Sprints are periods of time when software development is actually done.
• A sprint usually lasts from one week to one month to complete an item from the backlog.
• The goal of each sprint is to create a saleable product.
• Each sprint ends with a sprint review.
• Then the team chooses another piece of backlog to develop — which starts a new sprint.
• Sprints continue until the project deadline or the project budget is spent.
• In daily scrums, teams meet to discuss their progress since the previous meeting and
make plans for that day.
• The meetings should be brief — no longer than 15 minutes.
• Each team member needs to be present and prepared.
• The ScrumMaster keeps the team focused on the goal.
How Scrum Works
Introduction to Scrum Terms
• An introduction to Scrum would not be complete without knowing
the Scrum terms you'll be using. This section in the Scrum overview
will discuss common concepts in Scrum.
• Scrum team: A typical scrum team has between five and nine people,
but Scrum projects can easily scale into the hundreds. However,
Scrum can easily be used by one-person teams and often is. This team
does not include any of the traditional software engineering roles
such as programmer, designer, tester or architect. Everyone on the
project works together to complete the set of work they have
collectively committed to complete within a sprint. Scrum teams
develop a deep form of camaraderie and a feeling that “we’re all in
this together.”
Who is in the Scrum?/Scrum Terms
• Product owner: The product owner is the project’s key stakeholder and
represents users, customers and others in the process. The product owner
is often someone from product management or marketing, a key
stakeholder or a key user.
• Scrum Master: The Scrum Master is responsible for making sure the team
is as productive as possible. The Scrum Master does this by helping the
team use the Scrum process, by removing impediments to progress, by
protecting the team from outside, and so on.
• Product backlog: The product backlog is a prioritized features list
containing every desired feature or change to the product. Note: The term
“backlog” can get confusing because it’s used for two different things. To
clarify, the product backlog is a list of desired features for the product. The
sprint backlog is a list of tasks to be completed in a sprint.
• Sprint planning meeting: At the start of each sprint, a sprint planning meeting is held, during
which the product owner presents the top items on the product backlog to the team. The Scrum
team selects the work they can complete during the coming sprint. That work is then moved from
the product backlog to a sprint backlog, which is the list of tasks needed to complete the product
backlog items the team has committed to complete in the sprint.
• Daily Scrum: Each day during the sprint, a brief meeting called the daily scrum is conducted. This
meeting helps set the context for each day’s work and helps the team stay on track. All team
members are required to attend the daily scrum.
• Sprint review meeting: At the end of each sprint, the team demonstrates the completed
functionality at a sprint review meeting, during which, the team shows what they accomplished
during the sprint. Typically, this takes the form of a demonstration of the new features, but in an
informal way; for example, PowerPoint slides are not allowed. The meeting must not become a
task in itself nor a distraction from the process.
• Sprint retrospective: Also at the end of each sprint, the team conducts a sprint retrospective,
which is a meeting during which the team (including its ScrumMaster and product owner) reflect
on how well Scrum is working for them and what changes they may wish to make for it to work
even better.
• Each of the Scrum terms has its own page within the Scrum section, so be sure to check out all the
pages in the navigation.
A Visual Introduction to Scrum

This graphic is an introduction to the

essential elements of using Scrum for agile
software development. On the left, we see
the product backlog, which has been
prioritized by the product owner and
contains everything desired in the product
that’s known at the time. The two to four
week sprints are shown by the larger green
circle.
• At the start of each sprint, the team selects some amount of work from
the product backlog and commits to completing that work during the
sprint. Part of figuring out how much they can commit to is creating the
sprint backlog, which is the list of tasks (and an estimate of how long each
will take) needed to deliver the selected set of product backlog items to
be completed in the sprint.
• At the end of each sprint, the team produces a potentially shippable
product increment — i.e. working, high-quality software. Each day during
the sprint, team members meet to discuss their progress and any
impediments to completing the work for that sprint. This is known as the
daily scrum, and is shown as the smaller green circle above.
• Scrum is the type of Agile framework. It is a framework within which
people can address complex adaptive problem while productivity and
creativity of delivering product is at highest possible values. Scrum
uses Iterative process.
Key Features of Scrum Methodology

• Scrum has a short fixed schedule of release

cycles with adjustable scope known
as sprints to address rapidly changing
development needs. Each release could have
multiple sprints. Each Scrum Project could
have multiple Release Cycles.
• A repeating sequence of meetings, events,
and milestones
• A practice of testing and implementing new
requirements, known as stories, to make sure
some work is released ready after each sprint
Who can benefit from scrum?

• While scrum can benefit a wide variety of businesses and projects,

these are the most likely beneficiaries:
• Complicated projects: Scrum methodology is ideal for projects that
require teams to complete a backlog.

• Companies that value results: Scrum is also beneficial to companies

that value results over the documented progress of the process.

• Companies that cater to customers: Scrum can help companies that

develop products in accordance with customer preferences and
specifications.
What are the benefits of agile scrum
methodology?
• Here are some of the collective benefits of agile scrum methodology:
• Flexibility and adaptability
• Creativity and innovation
• Lower costs
• Quality improvement
• Organizational synergy
• Employee satisfaction
• Customer satisfaction
Benefits of Scrum
• Rugby players try to gain control of the ball in the scrum and move it downfield.
Software developers use scrum to move their projects quickly. And the benefits
trickle down to software developers:
• Developers who want the freedom to make decisions thrive in scrum teams.
Team morale tends to be high.
• Each sprint produces a product that is ready for market even though the project
is ongoing. The highest priority requirements are addressed first so a high-
quality, low-risk product can be on the market.
• The incremental process shortens the time to market by about 30 percent to 40
percent. Because the product owner is part of the scrum team, requirements can
be delivered as they are needed.
• Scrum projects often realize a higher return on investment (ROI). This is
attributed to:
• Decreased time to market.
• Early and regular feedback that prompts course corrections early when they are less
costly.
• Defects that are fewer and less costly.
• Projects failing early and quickly when it’s less costly.
• Reviewing each sprint before the team moves on to the next sprint spreads
testing throughout development.
• Project focus and goals can change with evolving business goals.
Disadvantages of Scrum

• While a rugby scrum may get rough and bloody, software developers
shouldn’t have to worry about that. Nonetheless, scrum is not for all
developer teams or software development projects. There
are disadvantages to implementing scrum projects:
• There is a danger of scope creep if stakeholders keep adding functionality
to the backlog. This could be encouraged by the fixed deadline.
• Scrum works best with small teams of experienced software developers.
They need to be able to work quickly.
• Scrum teams do not work well when the scrum master micromanages their
work.
• Losing any team members can hurt the progress of the project.
Scrum Best Practices
• Teamwork wins rugby games and helps software developers create
quality products. To get the best quality out of scrum:
• Define requirements just in time to keep product features as
relevant as possible.
• Test and incorporate product owner feedback daily.
• Sprint reviews with stakeholders need to be regular.
• The scrum team needs to use the sprint retrospectives to improve
how they work.
• Conduct face-to-face conversations to reduce miscommunications.
• Trust the teams to do the best job possible.
• Allow the teams to self-organize around people’s skills, work styles
and personalities.
• Don’t burn out the team members. Respect the balance between
their personal and professional lives to ease stress.
Role of test engineer in scrum team
• The tester should be actively engaged in the team's work during
the Sprint and meetings. It is the tester's role to ensure the quality of the
developed product and the delivery process itself
• The development team in Scrum is responsible for developing the product
by working closely with the Product Owner. As per the testing quadrants,
the testers are responsible for technology-facing tests that support team &
critique the product and business-facing tests that help the team &
critiques the product.
• Even though an entire Scrum team has responsibility for testing and code
quality, someone on the team needs to be good at testing, and someone
on the team needs to set up unit and regression test automation, run the
end-to-end integration tests, and do manual exploratory testing on the
whole product
 Scrum in Software Testing
• Scrum in Software Testing is a methodology for building complex
software applications. It provides easy solutions for executing
complicated tasks. Scrum helps the development team to focus on all
aspects of the software product development like quality,
performance, usability and so on. It provides with transparency,
inspection and adaptation during the software development to avoid
complexity.
Scrum Testing

• Scrum Testing is a testing done in scrum methodology to verify the

software application requirements are met. It involves checking non-
functional parameters like security, usability, performance etc. There
is no active role of tester in the process so it is usually performed by
developers with Unit Test. Sometimes dedicated test teams are
needed depending on nature & complexity of project.
Role of test engineer in scrum team
• 1) Attend sprint-planning sessions
• 2) Attend daily stand-ups.
• 3) Don’t save all the testing for the end; test throughout the sprint.
• 4) Meet with developers for short hand-off demonstrations.
• 5) Attend sprint retrospectives
• 6) Document Test cases
The Role of a Tester in an Agile Team
• Understanding, implementing, and updating the Agile Test Strategy
• Work with Product Owners to define Acceptance Criteria and the Definition of Done.
• Measuring and reporting test coverage across all applicable coverage dimensions
• Ensuring proper use of testing tools
• Configuring, using, and managing test environments and test data
• Writing and executing automated checks and reporting back to the team
• Reporting defects and working with the team to resolve them
• Coaching other team members in relevant aspects of testing
• Ensuring the appropriate testing tasks are scheduled during release and iteration planning
• Actively collaborating with developers and business stakeholders to clarify requirements, especially in terms of testability, consistency, and
completeness
• Participating proactively in daily standup meetings, story grooming sessions, team retrospectives, suggesting and implementing improvements
• Within an Agile team, each team member is responsible for product quality and plays a role in performing test-related tasks.
Agile organizations may encounter some test-related organizational risks:
• Testers work so closely to developers that they lose the appropriate tester mindset
• Testers become tolerant of or silent about inefficient, ineffective, or low-quality practices within the team
• Testers cannot keep pace with the incoming changes in time-constrained iterations
What is the role of a QA tester on a Scrum team?
What is the role of a QA tester on a Scrum
team?
• Face – To – Face Communication:
Face to face discussion with the team is the most efficient way to communicate ideas to
the time. A tester participates in Planning/ Release of the Sprint: The design meetings are
held every time before the sprint planning is done. The testers can participate in this
meeting and ask questions on the stories being discussed. The tester should make a model
in his mind about how the system would look and work based on the discussions.
• Capability to find ambiguity:
The tester would work collaboratively and productively with the product owner and the
customer to form acceptance criteria. An agile tester would be able to describe the feature
well. Before any user story is sent for development the tester and other team members
would discuss the complete user story with the team member to find out what the
customer wants.
• Absolute Role:
The tester should have good interpersonal skills .Tester should have Technical skills apart
from that he should have good communication skills to deliver the project to the client .
This shows that the tester should have a broader range of functionality.
What is the role of a QA tester on a Scrum
team?
• Technical Skills:
An agile tester understands the relevance of technical skills. He/She is always prepared to
contribute to the technical discussions of the team. His contribution may extend up to code
reviews, user stories grooming, requirements understanding. The Agile Software Tester
would work with the developers when they are performing unit testing and share the
perspective of testing from a tester point of view instead of developer point.
• Automation:
Agile testing involves automation at the time of unit testing and integration testing. For
automation There are many tools available for automation which does not require prior
training for language.
• Exploratory Tester:
The skill of exploratory testing is a very useful and powerful method sometimes in the agile
process. An exploratory tester can utilize his skills to perform testing avoiding risks and
uncertainty in the product. The tester can get ideas from the initial design discussions and
the meetings with the team to uncover the system and explore more in the system. Once
the tester is able to find out the areas of ambiguity the tester can work more systematically
and efficiently in the product. An agile tester should share their knowledge and
information with the rest of the scrum team.
What are the various testing activity on scrum
process
• sprint meeting : Which Item should be picked from backlogs and
estimated time for developing the component. It should also on the
prioritizing the work.
• Daily scrum : In daily scrum meeting tester should get the information
about previously done tasks and also do plan for next task to deliver
the developer.
• Daily work : Tester should perform acceptance test ,system test and
on the unit test and integration test tester should perform
Automation test on the Daily work of the current sprint
In Review and Retrospection meeting

• The tester needs to identify what went wrong and what went right in
the current sprint
• He needs to learn new lessons and best practices from the current
sprint
• The tester is encouraged to write new user stories that would help in
testing and also user stories that would help the customer
• The tester will discuss like if any user story was not covered in current
sprint.
• Any obstructions in the project will be put under consideration of
Scrum Master.
Introduction to Data
Structure
Definition

•Data structure is representation of the logical

relationship existing between individual
elements of data.
•In other words, a data structure is a way of
organizing all data items that considers not
only the elements stored but also their
relationship to each other.
Introduction

•Data structure affects the design of both

structural & functional aspects of a program.
Program = algorithm + Data Structure
•A algorithm is a step by step procedure to
solve a particular function.
Introduction

•Algorithm is a set of instruction written to

carry out certain tasks and the data structure
is the way of organizing the data with their
logical relationship retained.
•To develop a program of an algorithm, we
should select an appropriate data structure for
that algorithm.
•Therefore algorithm and its associated data
structures from a program.
Classification of Data Structure
•Data structure are normally divided into two broad
categories:
• Primitive Data Structure
• Non-Primitive Data Structure
 Classification of Data Structure

Data structure

Primitive DS Non-Primitive DS

Integer Float Character Pointer

 Classification of Data Structure

Non-Primitive DS

Linear List Non-Linear List

Array Queue Graph Trees

Link List Stack

Primitive Data Structure

•There are basic structures and directly

operated upon by the machine instructions.
•In general, there are different representation
on different computers.
•Integer, Floating-point number, Character
constants, string constants, pointers etc., fall
in this category.
Non-Primitive Data Structure

•There are more sophisticated data structures.

•These are derived from the primitive data
structures.
•The non-primitive data structures emphasize
on structuring of a group of homogeneous
(same type) or heterogeneous (different type)
data items.
Non-Primitive Data Structure

•Lists, Stack, Queue, Tree, Graph are example

of non-primitive data structures.
•The design of an efficient data structure must
take operations to be performed on the data
structure.
Non-Primitive Data Structure
•The most commonly used operation on data structure
are broadly categorized into following types:
• Create
• Selection
• Updating
• Searching
• Sorting
• Merging
• Destroy or Delete
Differences
•A primitive data structure is generally a basic
structure that is usually built into the language, such
as an integer, a float.
•A non-primitive data structure is built out of
primitive data structures linked together in
meaningful ways, such as a or a linked-list, binary
search tree, AVL Tree, graph etc.
Descriptions: Arrays
•An array is defined as a set of finite number of
homogeneous elements or same data items.
•It means an array can contain one type of data only,
either all integer, all float-point number or all
character.
Arrays
•Simply, declaration of array is as follows:
int arr[10]
•Where int specifies the data type or type of
elements arrays stores.
•“arr” is the name of array & the number specified
inside the square brackets is the number of elements
an array can store, this is also called sized or length
of array.
Arrays
•Following are some of the concepts to be
remembered about arrays:
• The individual element of an array can be
accessed by specifying name of the array,
following by index or subscript inside square
brackets.

• The first element of the array has index zero[0]. It

means the first element and last element will be
specified as: arr[0] and arr[9] respectively.
Arrays
• The elements of array will always be stored in the
consecutive (continues) memory location.

• The number of elements that can be stored in an

array, that is the size of array or its length is given
by the following equation:
(Upperbound-lowerbound)+1
Arrays
• For the above array it would be ( 9 – 0 ) + 1 = 10
where 0 is the lower bound of array and 9 is the
upper bound of array.

• Array can always be read or written through loop.

If we read a one-dimensional array it require one
loop for reading and other for writing the array.
Arrays
• For example: Reading an array

for(i=0; i <= 9; i++)

scanf(“%d”,&arr[i]);

• For example: Writing an array

for(i=0; i<=9; i++)

printf(“%d”,arr[i]);
Arrays
• If we are reading or writing two-dimensional array
it would require two loops. And similarly the array
of a N dimension would required N loops.

• Some common operation performed on array are:

• Creation of an array
• Traversing an array
Arrays

•Insertion of new element

•Deletion of required element
•Modification of an element
•Merging of arrays
Lists
•A lists (Linear linked list) can be defined as a
collection of variable number of data items.
•Lists are the most commonly used non-primitive
data structures.
•An element of list must contain at least two fields,
one for storing data or information and other for
storing address of next element.
•As you know for storing address we have a special
data structure of list the address must be pointer
type.
Lists
•Technically each such element is referred to as a node,
therefore a list can be defined as a collection of nodes as
show bellow:

Head
Pointer field Information field

AAA BBB CCC

[Linear Liked List]

Lists
•Types of linked lists:
• Single linked list
• Doubly linked list
• Single circular linked list
• Doubly circular linked list
Stack
•A stack is also an ordered collection of elements like
arrays, but it has a special feature that deletion and
insertion of elements can be done only from one end
called the top of the stack (TOP)
•Due to this property it is also called as last in first out
type of data structure (LIFO).
Stack
•It could be through of just like a stack of plates
placed on table in a party, a guest always takes off a
fresh plate from the top and the new plates are
placed on to the stack at the top.
•It is a non-primitive data structure.
•When an element is inserted into a stack or removed
from the stack, its base remains fixed where the top
of stack changes.
Stack
•Insertion of element into stack is called PUSH and deletion
of element from stack is called POP.
•The bellow show figure how the operations take place on a
stack:
PUSH POP

[STACK]
Stack
•The stack can be implemented into two ways:
• Using arrays (Static implementation)
• Using pointer (Dynamic implementation)
Queue
•Queue are first in first out type of data structure (i.e.,
FIFO)
•In a queue new elements are added to the queue
from one end called REAR end and the element are
always removed from other end called the FRONT
end.
•The people standing in a railway reservation row are
an example of queue.
Queue
•Each new person comes and stands at the end of the row
and person getting their reservation confirmed get out of
the row from the front end.
•The bellow show figure how the operations take place on a
stack:

10 20 30 40 50

front rear
Queue
•The queue can be implemented into two ways:
• Using arrays (Static implementation)
• Using pointer (Dynamic implementation)
Trees
•A tree can be defined as finite set of data items
(nodes).
•Tree is non-linear type of data structure in which
data items are arranged or stored in a sorted
sequence.
•Tree represent the hierarchical relationship between
various elements.
Trees
•There is a special data item at the top of hierarchy
called the Root of the tree.
•The remaining data items are partitioned into
number of mutually exclusive subset, each of which
is itself, a tree which is called the sub tree.
•The tree always grows in length towards bottom in
data structures, unlike natural trees which grows
upwards.
Trees
•The tree structure organizes the data into branches,
which related the information.

A root

B C

D E F G
Graph
•Graph is a mathematical non-linear data structure
capable of representing many kind of physical
structures.
•It has found application in Geography, Chemistry and
Engineering sciences.
•Definition: A graph G(V,E) is a set of vertices V and a
set of edges E.
Graph
•An edge connects a pair of vertices and many have
weight such as length, cost and another measuring
instrument for according the graph.
•Vertices on the graph are shown as point or circles
and edges are drawn as arcs or line segment.
Graph

6
v2 v5
v1 v3
10

v1 8 11
15
9 v2
v3 v4 v4

a. Directed & Weighted Graph b. Undirected Graph

Graph
•Types of Graphs:
• Directed graph
• Undirected graph
• Simple graph
• Weighted graph
• Connected graph
• Non-connected graph
Software Quality Assurance

1
 Organization of this Lecture:

•Introduction Quality Engineering.

•Quality control and Quality Assurance
•ISO 9000
•SEI CMM
•Summary

2
 Introduction

•Traditional definition of quality:

•fitness of purpose,
•a quality product does exactly what
the users want it to do.

3
 Fitness of purpose

•For software products,

•fitness of purpose:
•satisfaction of the requirements
specified in SRS document.

4
 Fitness of purpose

•A satisfactory definition of quality

for many products:
•a car, a table fan, a food mixer,
microwave oven, etc.
•But, not satisfactory for software
products.

5
 Introduction
•Consider a software product:
•functionally correct,
•i.e. performs all functions as
specified in the SRS document,
•but has an almost unusable user
interface.
•cannot be considered as a quality
product.
6
 Introduction

•Another example:
•a product which does everything
that users want.
•but has an almost
incomprehensible and
unmaintainable code.

7
 Modern view of quality

•Associates several quality factors with a

software product :
• Correctness
• Reliability
• Efficiency (includes efficiency of resource utilization)
• Portability
• Usability
• Reusability
• Maintainability

8
 Correctness

•A software product is correct,

•if different requirements as
specified in the SRS document
have been correctly implemented.
•Accuracy of results.

9
 Portability

•A software product is said to be

portable,
•if it can be easily made to work in
different operating systems,
•in different machines,
•with other software products, etc.

10
 Reusability

•A software product has good

reusability,
•if different modules of the
product can easily be reused to
develop new products.

11
 Usability

•A software product has good

usability,
•if different categories of users (i.e.
both expert and novice users) can
easily invoke the functions of the
product.

12
 Maintainability

•A software product is maintainable,

•if errors can be easily corrected as and
when they show up,
•new functions can be easily added to the
product,
•functionalities of the product can be easily
modified, etc.

13
Software Quality Management System

•Quality management system (or

quality system):
•principal methodology used by
organizations to ensure that the
products have desired quality.

14
 Quality system

•A quality system consists of the

following:
•Managerial Structure
•Individual Responsibilities.
•Responsibility of the organization as
a whole.

15
 Quality system

• Every quality conscious organization has an independent quality

department:
• performs several quality system activities.
• needs support of top management.
• Without support at a high level in a company,
• many employees may not take the quality system seriously.

16
 Quality System Activities:

•Auditing of projects
•Development of:
•standards, procedures, and guidelines, etc.
•Production of reports for the top
management
•summarizing the effectiveness of the
quality system in the organization.
• Review of the quality system itself.

17
 Quality system

•A good quality system must be well

documented.
•Without a properly documented quality
system,
• application of quality procedures become ad
hoc,
• results in large variations in the quality of the
products delivered.

18
 Quality system
• An undocumented quality system:
• sends clear messages to the staff about the attitude of the organization
towards quality assurance.
• International standards such as ISO 9000 provide:
• guidance on how to organize a quality system.

19
 Evolution of Quality Systems

•Quality systems have evolved:

•over the last five decades.
•Prior to World War II,
•way to produce quality products:
•inspect the finished products
•eliminate defective products.

20
 Evolution of Quality Systems

•Since that time,

•quality systems of organizations
have undergone
•four stages of evolution.

21
Evolution of Quality Systems

22
 Evolution of Quality Systems

•Initial product inspection method :

•gave way to quality control (QC).
•Quality control:
•not only detect the defective products and
eliminate them
•but also determine the causes behind the
defects.

23
 Quality control (QC)

•Quality control aims at correcting the

causes of errors:
•not just rejecting defective products.
• Statistical quality control
•quality of the output of the process is
inferred using statistical methods
•in stead of inspection or testing of all
products

24
Quality control (QC)

•The next breakthrough,

•development of quality assurance
principles

25
 Quality assurance

•Basic premise of modern quality

assurance:
•if an organization's processes are good
and are followed rigorously,
•the products are bound to be of good
quality.

26
 Quality assurance

•All modern quality paradigms

include:
•guidance for recognizing, defining,
analyzing, and improving the
production process.

27
 Total quality management (TQM)

•Advocates:
•continuous process improvements
through process measurements.

28
Business Process reengineering

•A term related to TQM.

•Process reengineering goes a
step further than quality
assurance:
•aims at continuous process
improvement.

29
Business Process reengineering

•Our focus is reengineering of the

software process.
•Whereas BPR aims at reengineering
the way business is carried out in
any organization
•not just software development
organizations.
30
 Total quality management (TQM)

•TQM goes beyond documenting

processes
•optimizes them through redesign.
•Over the years the quality paradigm has
shifted:
•from product assurance to process
assurance.

31
 ISO 9000
•ISO (international Standards
Organization):
•a consortium of 63 countries established to
formulate and foster standardization.
•ISO published its 9000 series of
standards in 1987.

32
 What is ISO 9000 Certification?

•ISO 9000 certification:

•serves as a reference for contract
between independent parties.
•The ISO 9000 standard:
•specifies guidelines for maintaining a
quality system.

33
 What is ISO 9000 Certification?

•ISO 9000 specifies:

•guidelines for repeatable and high quality
product development.
•Also addresses organizational aspects
• responsibilities, reporting, procedures,
processes, and resources for implementing
quality management.

34
 ISO 9000

•A set of guidelines for the

production process.
•not directly concerned about the
product it self.
•a series of three standards:
•ISO 9001, ISO 9002, and ISO 9003.

35
 ISO 9000

•Based on the premise:

•if a proper process is followed for
production:
•good quality products are bound to
follow.

36
 ISO 9001:

•Applies to:
•organizations engaged in design,
development, production, and
servicing of goods.
•applicable to most software
development organizations.

37
 ISO 9002:

• ISO 9002 applies to:

• organizations who do not design products:
• but are only involved in production.
• Examples of this category of industries:
• steel or car manufacturing industries
• buy the product and plant designs from external sources:
• only manufacture products.
• not applicable to software development organizations.

38
 ISO 9003

•ISO 9003 applies to:

•organizations involved only in
installation and testing of the products.

39
 ISO 9000 for Software Industry

• ISO 9000 is a generic standard:

• applicable to many industries,
• starting from a steel manufacturing industry to a service rendering company.

• Many clauses of ISO 9000 documents:

• use generic terminologies
• very difficult to interpret them in the context of software organizations.

40
 Software vs. other industries

•Very difficult to interpret many

clauses for software industry:
•software development is radically
different from development of other
products.

41
 Software vs. other industries

• Software is intangible
• therefore difficult to control.
• It is difficult to control anything that we cannot see and feel.
• In contrast, in a car manufacturing unit:
• we can see a product being developed through stages such as fitting engine, fitting
doors, etc.
• one can accurately tell about the status of the product at any time.
• Software project management is an altogether different ball game.

42
 Software vs. other industries

• During software development:

• the only raw material consumed is data.
• For any other product development:
• Lot of raw materials consumed
• e.g. Steel industry consumes large volumes of iron ore, coal, limestone, etc.

• ISO 9000 standards have many clauses corresponding to raw material

control .
• not relevant to software organizations.

43
 Software vs. other industries

•Radical differences exist between

software and other product
development,
•difficult to interpret various clauses of
the original ISO standard in the
context of software industry.

44
 ISO 9000 Part-3

•ISO released a separate document called

ISO 9000 part-3 in 1991
•to help interpret the ISO standard for
software industry.
•At present,
•official guidance is inadequate

45
 Why Get ISO 9000 Certification?

•Several benefits:
•Confidence of customers in an
organization increases
•if organization qualified for ISO 9001
certification.
•This is especially true in the international
market.

46
 Why Get ISO 9000 Certification?

•Many international software

development contracts insist:
•development organization to have ISO
9000 certification.

47
 Why Get ISO 9000 Certification?

•Requires:
•a well-documented software production
process to be in place.
•contributes to repeatable and higher
quality software.
•Makes development process:
•focussed, efficient, and cost-effective

48
 Why Get ISO 9000 Certification?

•Points out the weakness of an

organizations:
•recommends remedial action.
•Sets the basic framework:
•for development of an optimal process and
TQM.

49
How to Get ISO 9000 Certification?

•An organization intending to obtain ISO

9000 certification:
•applies to a ISO 9000 registrar for
registration.
•ISO 9000 registration process consists of
several stages.

50
How to Get ISO 9000 Certification?

•Application stage:
•Applies to a registrar for registration.
•Pre-assessment:
•the registrar makes a rough
assessment of the organization.

51
How to Get ISO 9000 Certification?

•Document review and adequacy

audit:
•process and quality-related
documents.
•the registrar reviews the documents
•makes suggestions for improvements.

52
 How to Get ISO 9000 Certification?

•Compliance audit: the registrar

checks
•whether the suggestions made by it
during review have been complied.

53
How to Get ISO 9000 Certification?

•Registration:
•The registrar awards ISO 9000 certificate
after successful completions of all previous
phases.
•Continued surveillance:
• The registrar continues monitoring the
organization periodically.

54
 ISO 9000 Certification

•An ISO certified organization

•can use the certificate for corporate
advertizements
•cannot use the certificate to advertize
products.
• ISO 9000 certifies organization's process
• not any product of the organization.
•An organization using ISO certificate for
product advertizements:
• risks withdrawal of the certificate.
55
Summary of ISO 9001 Requirements

• Management responsibility(4.1):
•Management must have an effective
quality policy.
•The responsibility and authority of all
those whose work affects quality:
• must be defined and documented.

56
 Management responsibility(4.1)

•Responsibility of the quality system.

•independent of the development process,
•can work in an unbiased manner.
•The effectiveness of the quality system:
•must be periodically by audited.

57
 Quality system (4.2) and contract reviews (4.3):

•A quality system must be

maintained and documented.
•Contract reviews (4.3):
•Before entering into a contract, an
organization must review the contract
•ensure that it is understood,
•organization has the capability for
carrying out its obligations.

58
 Design control (4.4):

•The design process must be

properly controlled,
•this includes controlling coding also.
•A good configuration control system
must be in place.

59
 Design control (4.4):

•Design inputs must be verified as

adequate.
•Design must be verified.
•Design output must be of required
quality.
•Design changes must be controlled.

60
 Document control (4.5):

•Proper procedures for

•document approval, issue and removal.
•Document changes must be controlled.
•use of some configuration management
tools is necessary.

61
 Purchasing (4.6):

•Purchased material, including

bought-in software:
•must be checked for conforming to
requirements.

62
 Purchaser Supplied Products (4.7):

•Material supplied by a purchaser,

• for example,
•client-provided software must be
properly managed and checked.

63
 Product Identification (4.8):

•The product must be identifiable at

all stages of the process.
•In software development context this
means configuration management.

64
 Process Control (4.9) :

•The development must be properly

managed.
•Quality requirements must be identified
in a quality plan.

65
 Inspection and Testing (4.10) :

•In software terms this requires

effective testing i.e.,
•unit testing, integration testing and
system testing.
•Test records must be maintained.

66
 Inspection, measuring and test equipment(4.11):

•If integration, measuring, and test

equipments are used,
•must be properly maintained and
calibrated.

67
 Control of nonconforming product (4.13) :

•In software terms,

•keeping untested or faulty
software out of released product,
•or other places whether it might
cause damage.

68
 Corrective Action (4.14) :

• This is both about correcting errors when found,

• investigating why they occurred
• improving the process to prevent further occurrences.
• If an error reoccurs despite the quality system,
• the system needs improvement.

69
Handling (4.15) and Quality audits (4.17):

•Handling (4.15) Deals with:

•storage, packing, and delivery of
the software product.
•Quality Audits (4.17) :
•quality system audit must be
carried out to ensure its
effectiveness.
70
 Training (4.18) :

•Training needs must be identified

and met.
•Most items of ISO standard
•are largely common sense.

71
Salient features of ISO 9001 requirements:

•All documents concerned with the

development of a software product
•should be properly managed, authorized,
and controlled.
•Proper plans should be prepared
•progress against these plans should be
monitored.

72
Salient features of ISO 9001 requirements:

•Important documents independently

checked and reviewed:
• for effectiveness and correctness.
•The product should be tested :
•against specification.
•Several organizational aspects:
•e.g., management reporting of the quality
team.

73
Shortcomings of ISO 9001 Certification (1)

•ISO 9000 requires a production

process to be adhered to:
•but does not guarantee the process to
be of high quality.
•Does not give any guideline for
defining an appropriate process.

74
Shortcomings of ISO 9001 Certification (2)

•ISO 9000 certification process

•not fool-proof
•no international accredition agency
exists.
•likely variations in the norms of
awarding certificates:
•among different accredition agencies and
among the registrars.

75
Shortcomings of ISO 9001 Certification (3)

•Organizations qualifying for ISO 9001

certification:
•tend to downplay domain expertise.
•tend to believe that since a good process is
in place,
• any engineer is as effective as any other
engineer in doing any particular activity
relating to software development.

76
Shortcomings of ISO 9001 Certification (4)

•In manufacturing industry

•clear link between process quality and
product quality
•once a process is calibrated:
• can be run again and again producing quality
goods
•Software development is a creative
process:
•individual skills and experience is
significant
77
Shortcomings of ISO 9001 Certification (5)

•Many areas of software development

are very specialized:
•special expertize and experience (domain
expertize) required.
•ISO 9001
•does not automatically lead to continuous
process improvement,
•does not automatically lead to TQM.

78
 Shortcomings of ISO 9001 Certification (6)

• ISO 9001 addresses mostly management aspects.

• Techniques specific to software development have
been ignored
• Configuration management
• Reviews
• Release builds
• Problem Notification system
• Intranets

79
 SEI Capability Maturity Model

•Developed by Software Engineering

Institute (SEI) of the Carnegie Mellon
University, USA:
•to assist the U.S. Department of Defense
(DoD) in software acquisition.
•The rationale was to include:
• likely contractor performance as a factor in
contract awards.

80
 SEI Capability Maturity Model

• Major DoD contractors began CMM-based process improvement

initiatives:
• as they vied for DoD contracts.
• SEI CMM helped organizations:
• Improve quality of software they developed
• Realize adoption of SEI CMM model had significant business benefits.
• Other organizations adopted CMM.

81
 SEI Capability Maturity Model

•In simple words,

•CMM is a model for apprising the software
process maturity of a contractor into
different levels.
•Can be used to predict the most likely
outcome to be expected from the next
project that the organization undertakes.

82
 SEI Capability Maturity Model

•Can be used in two ways:

•Capability evaluation
•Software process assessment.

83
 Capability Evaluation

•Provides a way to assess the

software process capability of an
organization
•Helps in selecting a contractor
•Indicates the likely contractor performance

84
 Software Process Assessment

•Used by an organization to assess its

current process:
•Suggests ways to improve the process
capability.
•This type of assessment is for purely
internal use.

85
 SEI Capability Maturity Model

•The SEI CMM classifies software

development industries into:
•Five maturity levels.
•Stages are ordered so that improvements at
one stage provide foundations for the next
•Based on the pioneering work of Philip Crosby

86
SEI Capability Maturity Model

Optimizing (5)

Managed (4)

Defined (3)

Repeatable (2)

Initial (1)

87
 Level 1: (Initial)
•Organization operates
•without any formalized process or
project plans
•An organization at this level is
characterized by
•ad hoc and often chaotic activities.

88
 Level 1: (Initial)
•Software production processes are not
defined,
•different engineers follow their own
process
•development efforts become chaotic.
•The success of projects depend on
individual efforts and heroics.

89
 Level 2: (Repeatable)

•Basic project management practices

•tracking cost, schedule, and functionality
are followed.
•Size and cost estimation techniques
•function point analysis, COCOMO, etc.
used.
• Production process is ad hoc
•not formally defined
•also not documented.

90
 Level 2: (Repeatable)

•Process used for different projects might

vary between projects:
•earlier success on projects with similar
applications can be repeated.
•Opportunity to repeat process exist when a
company produces a family of products.

91
 Level 3: (Defined)

•Management and development

activities:
•defined and documented.
•Common organization-wide
understanding of activities, roles,
and responsibilities.

92
 Level 3: (Defined)

•The process though defined,

•process and product qualities are
not measured.
•ISO 9001 aims at achieving this
level.

93
 Level 4: (Managed)

• Quantitative quality goals for products are set.

• Software process and product quality are measured:
• The measured values are used to control the product quality.
• Results of measurement used to evaluate project performance
• rather than improve process.

94
 Level 4: (Managed)

•Organization sets quantitative

quality goals
•World-wide about 100 organizations
assessed at this level.

95
 Level 5: (Optimizing)

•Statistics collected from process and

product measurements are analyzed:
•continuous process improvement based on
the measurements.
• Known types of defects are prevented from
recurring by tuning the process
• lessons learned from specific projects
incorporated into the process

96
 Level 5: (Optimizing)

•Identify best software engineering

practices and innovations:
• tools, methods, or process are identified
•transferred throughout the organization
• World-wide about 50 organizations have been assessed at this level.

97
 Key Process Areas

•Each level is associated with a key

process area (KPA) identifies
•where an organization at the previous
level must focus to reach this level

98
 Level 2 KPAs

•Software project planning

•Size, cost, schedule.
•project monitoring
•Configuration management
•Subcontract management

99
 Level 3 KPAs

•Process definition and

documentation
•Reviews
•Training program

100
 Level 4 KPAs

•Quantitative measurements
•Process management

101
 Level 5 KPAs
•Defect prevention
•Technology change management
•Process change management

102
Comparison between ISO 9001 and SEI CMM

•ISO 9001 awarded by an international

standards body
•can be quoted in official documents and
communications
•SEI CMM assessment is purely for
internal use.

103
Comparison between ISO 9001 and SEI CMM

•SEI CMM was developed specifically for

software industry:
•addresses many issues specific to software
industry.
• SEI goes beyond quality assurance
• aims for TQM
• ISO 9001 correspond to SEI level 3.

104
Comparison between ISO 9001 and SEI CMM

• SEI CMM provides a list of key areas

• on which to focus to take an organization from one level to the other
• Provides a way for gradual quality improvements over several stages.
• e.g trying to implement a defined process before a repeatable process:
• counterproductive as managers are overwhelmed by schedule and budget pressure.

105
 Remarks on Quality Model Usage

• Highly systematic and measured approach to

software development process suits certain
circumstances
• negotiated software, safety-critical software, etc
• What about small organizations?
• Typically handle applications such as internet, e-comm.
• without an established product range,
• without revenue base, experience on past projects, etc.
• CMM may be incompatible

106
 Small Organizations

• Small organizations tend to believe:

• We are all competent people hired to do a job, we can’t afford training
• We all communicate with one another
• Osmosis works because we are so close
• We are all heroes
• We do what needs to be done
• Therefore rules do not apply to us

107
 Small Organizations

• Often have problems:

• Undocumented requirements
• Inexperienced managers
• Documenting the product
• Resource allocation
• Training
• Peer reviews

108
 Small Organizations

• A two week CMM-based appraisal is probably excessive:

• Small organizations need to operate more efficiently at lower levels of
maturity
• Must first fluorish if eventually they are to mature

109
 Personal Software Process (PSP)

• Based on the work of Humphrey

• PSP is a scaled down version of industrial software process
• suitable for individual use
• Even CMM assumes that engineers use effective personal practices

110
Personal Software Process (PSP)

• A process is the set of steps for doing a job

• The quality and productivity of an engineer
• largely determined by his process
• PSP is framework that
• helps software engineers to measure and improve the way they work.

111
Personal Software Process (PSP)

• Helps developing personal skills and methods

• Estimating and planning method
• Shows how to track performance against plans
• Provides a defined process
• can be fine tuned by individuals
• Recognizes that a process for individual use is different from that necessary for a team
project.

112
Time Management

• Track the way you spend time

• Boring activities seem longer then actual
• Interesting activities seem short
• Record time for
• Designing
• Writing code
• Compiling
• Testing

113
Personal Software Process (PSP)

Planning
Design
Code Logs
Compile
Test
Project plan
Postmortem
summary

114
 PSP-Planning
• Problem definition
• Estimate max, min, and total LOC
• Determine minutes/LOC
• Calculate max,min, and total development times
• Enter the plan data in project plan summary form
• record the planned time in Log

115
 PSP-Design

• Design the program

• Record the design in specified format
• Record the Design time in time recording log

116
 PSP-Code

• Implement the design

• Use a standard format for code text
• Record the coding time in time recording log

117
 PSP-Compile

• Compile the program

• Fix all the defects
• Record compile time in time recording log

118
 PSP-Test/Postmortem

• Test
• Test the program
• Fix all the defects found
• Record testing time in time recording log
• Postmortem
• Complete project plan summary form with actual time and size data
• Record postmortem time in time record

119
Personal Software Process (PSP)

PSP 3 • Personal process

evolution

PSP 2 • Personal quality management

• Design and code reviews
PSP 1 •Personal planning
• Time and schedule
PSP 0 • Personal measurement
• Basic size measures
120
 Six Sigma

• Six sigma is a quantitative approach to eliminate defects

• Applicable to all types of industry - from manufacturing, product development,
to service
• The statistical representation of Six Sigma quantitatively describes
• how a process is performing

121
 Six Sigma
• To achieve six sigma
• a process must not produce more than 3.4 defects per million opportunities.
• 5 Sigma -> 230 defects per million
• 4 Sigma -> 6210 defects per million
• Six sigma methodologies
• DMAIC (Define, Measure, Analyze, Improve, Control)
• DMADV: (Define, Measure, Analyze, Design, Verify)

122
Six Sigma Methodologies

• The methodologies are implemented by Green belt and Black belt

workers
• Supervised by Master black belt worker
• Pareto Chart:
• Simple bar chart to represent defect data
• Identify the problems that occurs with greatest frequency
• or incur the highest cost

123
 Summary

•Evolution of quality system:

•product inspection
•quality control
•quality assurance
•total quality management (TQM)
•Quality paradigm change:
•from product to process
124
 Summary
•ISO 9000:
•basic premise:
•if a good process is followed
•good products are bound to follow
•provides guidelines for establishing a
quality system.

125
 Summary
•ISO 9000
•series of three standards
•9001, 9002, and 9003
•9001 is applicable to software
industry

126
 Summary
•SEI CMM
•developed specially for software
industry
•classifies software organizations into
five categories.
•According to the maturity of their
development process.

127
Current Trends

• Many organizations have already tuned their process for

• Budget,
• Schedule, and
• Quality product.
• Competition is challenging them to:
• Reduce time for delivery
• Adopt Six-Sigma methodology

128
Software Lifecycle Models

1
Lecture outline

• The software lifecycle

• evaluating models

• Lifecycle models
• code-and-fix
• waterfall
• spiral
• evolutionary prototyping
• staged delivery
• design-to-schedule

2
Ad-hoc development

• ad-hoc development: creating software without any formal

guidelines or process

• Some disadvantages of ad-hoc development:

• some important actions (testing, design) may go ignored
• not clear when to start or stop doing each task
• does not scale well to multiple people
• not easy to review or evaluate one's work

• a common observation: The later a problem is found in software, the

more costly it is to fix.

3
The software lifecycle

• software lifecycle: series of steps / phases, through which software is

produced
• can take months or years to complete

• goals of each phase:

• mark out a clear set of steps to perform
• produce a tangible document or item
• allow for review of work
• specify actions to perform in the next phase

4
Lifecycle phases

• standard phases
• Requirements Analysis & Specification
• High-level (Architectural) Design
• Detailed (Object-oriented) Design
• Implementation, Integration, Debugging
• Testing, Profiling, Quality Assurance
• Operation and Maintenance

• other possible phases

• risk assessment: examining what actions are critical and performing them
first (part of Spiral model)
• prototyping: building a rough/partial version of the product and using it to
guide design decisions

5
 One view of SW cycle phases

Requirements Requirements Arch. Detailed Implemen-

Testing
Elicitation Analysis Design Design tation

Implemented
Expressed in By
Structured By Realized By
Terms Of Verified
By

class...
class...
class... ?
class.... ?
Use Case Application Solution
Domain Subsystems Source Test
Model Domain
Objects Code Cases
Objects

6
Some software models

• Several models for developing software have been attempted,

varying the order and frequency in which these stages occur:
• code-and-fix: write some code, debug it, repeat until finished

• waterfall: perform the standard phases (requirements, design, code, test) in

sequence

• spiral: assess risks at each step, and do the most critical action immediately

• evolutionary prototyping: build an initial requirement spec, code it, then

"evolve" the spec and code as needed

• staged delivery: build initial requirement specs for several releases, then
design-and-code each in sequence

7
Model pros/cons

• value of models
• decomposing workflow
• understanding and managing the process
• as a management tool

• limitations of models
• a model is just a model
• abstracts away some aspects and highlights others
• artificial constraints
• compromises with model are often necessary
• (as with almost everything in SE)
• risk of overemphasizing the process
• the process is not the end in itself; product delivery is

8
Evaluating models

• Criteria for evaluation of models

• Risk management
• Quality / cost control
• Predictability
• Visibility of progress
• Customer involvement and feedback

• Theme: Overall aim for good, fast, and cheap.

But you can't have all three at the same time.

9
Code-and-fix model
code first
version

modify until
client is satisfied

operations mode

retirement

10
 Problems with code-and-fix

• benefits
• no planning whatsoever; little management overhead
• applicable for very small projects and short-lived prototypes

• What are some reasons not to use the code-and-fix model?

◼ code becomes expensive to fix (bugs are not found

until late in the process)
◼ code didn't match user's needs (no requirements!)
◼ code was not planned for modification, not flexible 11
Waterfall model

req. change
requirements

verify
design

verify
implementation

test

operations

retirement
12
Detailed waterfall view

13
 Waterfall issues

• waterfall model is perhaps the most common model for software

development
• we will use a waterfall-like model in this course

• benefits
• formal, standard; has specific phases with clear goals
• good feedback loops between adjacent phases

• What are some drawbacks to this method?

- rigid, too linear; not very adaptable to change in the product
- requires a lot of planning up front (not always easy / possible)
- assumes that requirements will be clear and well-understood
- costly to "swim upstream" by going back to a previous phase
- Nothing to show to anxious customers ("We're 90% done!") 14
 Modified waterfalls

• sashimi (waterfall with overlapping phases): phases overlap

• team can learn insights from later cycles to aid earlier ones

• waterfall with subprojects

• can begin coding simple features while designing tough ones

• What are some problems with these models?

- harder to track progress of the overall project

- communication can be tougher
- unforeseen dependencies can occur
15
Another view of the spiral

16
 Another view of spiral model
Risk Assessment
Req. Change
Requirements
Risk Assessment
Verify
Design
Risk Assessment
Verify
Implementation

Test
Adds a Risk Analysis
step to each phase
Operations

(phases may not be

completed in this order Retirement
any more!) 17
Spiral details

• breaks up the project into mini-projects based on risk

• purpose: risk reduction
• example: in first phase,
• great when charting new territories (with high risks)

• steps taken at each loop of the spiral (roughly):

• determine objectives, options, constraints
• identify risks
• evaluate options to resolve the risks
• develop and verify any deliverable items
• plan the next phase
• commit to approach for next phase

18
Spiral benefits

• benefits of spiral
• provides early indication of unforeseen problems
• as costs increase, risks decrease
• always addresses the biggest risk first
• focuses attention on reuse
• accommodates changes, growth
• eliminates errors and unattractive choices early
• limits to how much is enough (not too much design, reqs, etc)
• treats development, maintenance same way

19
 Spiral problems

• What are some drawbacks to the spiral model?

- complicated
- relies on developers to have risk-assessment expertise
- possibly more management overhead to assess risk
- need for more elaboration of project steps
(clearer milestones)
- matching to contract software
(doesn't work well when you're bound to a fixed
inflexible contract)

20
Evolutionary prototype model
requirements

verify
arch. design

verify
for each build:
perform detailed
design, implement,
test, deliver

operations

retirement

21
 Evolutionary details

• idea: build an initial requirement spec, code it, then "evolve" the
spec and code as needed
• each repetition is an "evolution" of the code, not necessarily bug fixes

• What is the difference between evolutionary prototyping and

evolutionary delivery?

◼ e. delivery is a mixing of evolutionary prototyping

and staged delivery
◼ focuses more on internals, parts of system unlikely
to be changed by customer feedback
◼ e. prototyping rushes initial release with perhaps
less focus on requirements and design 22
Benefits of evolutionary

• benefits of evolutionary prototyping

• produces steady signs of progress
• useful when requirements are not very well known, changing rapidly, or
customer is non-committing
• allows close customer involvement
• "What do you think of this version?"
• can improve customer confidence / satisfaction
• customers must be available on a short notice to give feedback

23
 Problems with evolutionary

• What are some problems with this model?

◼ sometimes difficult to distinguish from code-and-fix

◼ assumes user's initial spec will be flexible; fails for:
◼ separate pieces that must then be integrated
◼ "information sclerosis": temporary fixes become permanent
constraints
◼ bridging; new software trying to gradually replace old
◼ unclear how many iterations will be needed to finish
◼ wrong order: makes lots of hard-to-change code

24
 Staged delivery

• staged delivery
• waterfall-like beginnings, then develop in short stages
• requires tight coordination with documentation, management, and
marketing
• can ship at any time during implementation
• from the outside (to customers) it looks like a successful delivery even if it is
not the final goal the team aimed for

• How does staged delivery differ from evolutionary prototyping?

◼ In staged delivery, requirements are better known

ahead of time rather than discovered through customer
feedback after each release. 25
Design-to-*

• design-to-schedule
• useful when you absolutely need to ship by a certain date
• similar to the staged delivery model
• but less flexible because of the fixed shipping date
• requires careful prioritization of features and risks to address

• design-to-tools
• a model where the project only incorporates features that are easy to
implement by using or combining existing components
• reduces development time at cost of losing control of project

26
Which model is best?

• The choice of a model depends on the project circumstances and

requirements.
• A good choice of a model can result in a vastly more productive
environment than a bad choice.
• A cocktail of models is frequently used in practice to get the best of
all worlds.
• care must be applied; some models can't mix easily or at all

• Reminder: criteria for judging models:

• Risk management
• Quality / cost control
• Predictability
• Visibility of progress
• Customer involvement and feedback

27
 Model category matrix
Risk Quality/ Predict- Visibility Customer
mgmt. cost ctrl. ability involvement
• Rate each model 1-5 in each of the categories shown:
code-and-fix

waterfall

spiral

evolutionary
prototyping
staged delivery

design-to-
schedule
28
 Possible answer

• Rate each modelRisk

1-5 in each of the categories
Quality/ Predict-shown:
Visibility Customer
mgmt. cost ctrl. ability involvement
code-and-fix
1 1 1 3 2
waterfall
2 4 3 1 2
spiral
5 5 3 3 3
evolutionary
prototyping 3 3 2 5 5
staged delivery
3 5 3 3 4
design-to-
schedule 4 3 5 3 2
29
Software Metrics and
Reliability
 Reiiabiiity
• The most important dynamic characteristic
of software is its reliability.
• The reliability of a software system is a
measure of how well it provides the
services expected by its users.
 RELIABILITY ISSUES
Some of the contributing factors are given
below:
• Change in environment
• Change in infrastructure/technology
• Major change in requirements
• Increase in complexity
• Extremely difficult to maintain
 RELIABILITY METRICS
• Reliability metrics are used to
quantitatively express the reliability of a
software product.
• Some reliability metrics, which can be
used to quantify the reliability of a software
product are:
MTTF (Mean Time to Failure). The MTTF is the
mean time for which a component is expected to
be operational.
• The MTTF is the average time between
observed system failures. An MTTF of 500
means that one failure can be expected every
500 time units.
• The time units are totally dependent on the
system and it can even be specified in the
number of transactions, as is the case of
database query systems.
 MTTR (Mean Time to Repair) Once a
hardware component fails then the failure
is usually permanent
• so the Mean Time to Repair (MTTR)
reflects the time taken to repair or replace
the component.
 MTBF (Mean Time Between Failures).
• We can combine the MTTF and MTTR
metrics to get the MTBF metric:
MTBF=MTTF+MTTR
• Thus, a MTBF of 300 hours indicates that
once a failure occurs, the next failure is
expected to occur only after 300 hours.
ROCOF (Rate of Occurrences of Failure).
• ROCOF is the frequency of occurrence
with which unexpected behavior is likely to
occur.
• A ROCOF of 2/100 means that two
failures are likely to occur in each 100
operational time units
• Ex: It is relevant for operating systems
and transaction-processing systems
• where the system has to process a large
number of similar requests that are
relatively frequent; for example, credit-card
processing systems, airline- booking
systems, etc.
• AVAIL (Availability). Availability is the
probability that the system is available for
use at a given time.
• An availability of 0.998 means that in
every 1000 time units, the system is likely
to be available for 998 of these.
 RELIABILITY GROWTH
MODELING
• A reliability growth model is a
mathematical model of how software
reliability improves as errors are detected
and repaired
 Step Function Model
• The simplest reliability growth model is a
step function model, where it is assumed
that the reliability increases by a constant
increment each time an error is detected
and repaired.
 Jelinski and Moranda Modei
• In this model, it is realized that reliability
does not increase by a constant amount
each time an error is repaired.
• The improvement in reliability due to fixing
of an error is assumed to be proportional
to the number of errors remaining in the
system at that time.
 Definitions
• According to ANSI, “ Software Reliability is defined as the probability of failure —free
software operation for a specified period of time in a specified environment”.

• IEEE defines Reliability as “ The ability of a system or component to perform its

required functions under stated conditions for a specified period of time”
 Software Reliability and Hardware
Reliability
• Software Reliability • Hardware Reliability

• It is not a direct function ol time • It is a direct function of time.

Software Reliabiiity
Integration and Testing

Useful life

obsolete

Integration Useful Life obsolete

and Testing
Hardware Reìiabiìity

Burn In

Useful Life

Wear Out

Burn In Useful Life Wear Out

 Fauits and Failures

FAILURE

• It is the departure of the external results of program operation from

requirements
 FAULT

• A Fault is a defect in a program which arises when programmer

makes an error.

• It Causes Failure when executed under particular conditions

 Achieving Reliabiiity

• Software Reliability can be achieved by using metrics at different stages of

software development cycle.
 Phases
• Requirement Phase

• Design and coding phase

• Testing phase
 Software Metrics For Reliability

• Requirements Reliability Metrics

• Design and Code Reliability Metrics

• Testing Reliability Metrics

Requirements Reiiabiiity Metrics

• A clear understanding between client and developer should exist.

• Must Contain valid Strucure
• Must be complete
• Ease to communicate
Design and Code Reliability Metrics
Quality Factors

• Complexity
• Size
 Testing Reiiability Metrics

• First approach is “ensuring that the system is fully equipped with the
functions that are specified in the requirements”.

• Second approach is “Evaluating the code, Finding the errors and fixing
them”.
• Software Reliability is the probability that the software will work without
failure for a specified period of time

• Achieving the software reliability is hard as the complexity of the software

tends to be high

• Software Reliability can be increased by applying metrics at different stages

of software development life cycle.
Thank You
Any Questions?
Software Project Planning
 The Four 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

People Product Process Project

 The People: The Stakeholders

• Five categories of 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.
Software Teams

How to lead?
How to organize?
How to collaborate?

How to motivate? How to create good ideas?

 The People: Team Leaders

• Qualities to look for in a team leader

• 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.
 The People: The Software Team

• Seven project factors to consider when structuring a software

development team
• the difficulty of the problem to be solved
• the size of the resultant program(s) in lines of code or function
points
• the time that the team will stay together (team lifetime)
• the degree to which the problem can be modularized
• the required quality and reliability of the system to be built
• the rigidity of the delivery date
• the degree of sociability (communication) required for the project
 The Product Scope

• Scope
• 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?
• 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?
• Software project scope must be unambiguous and
understandable at the management and technical levels.
 Problem Decomposition

• Sometimes called partitioning or problem elaboration

• Once scope is defined …
• It is decomposed into constituent functions
• It is decomposed into user-visible data objects
or
• It is decomposed into a set of problem classes
• Decomposition process continues until all functions or
problem classes have been defined
 The Process

• Once a process framework has been established

• Consider project characteristics
• Determine the degree of rigor required
• Define a task set for each software engineering activity
• Task set =
• Software engineering tasks
• Work products
• Quality assurance points
• Milestones
 The 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.
• 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.
 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?
Process and Project Metrics
A Good Manager Measures

process
process metrics
project metrics
measurement
product metrics
product
What do we
use as a
basis?
• size?
• function?
 Why Do We Measure?

• assess the status of an ongoing project

• track potential risks
• uncover problem areas before they go “critical,”
• adjust work flow or tasks,
• evaluate the project team’s ability to control quality of software
work products.
 Process Metrics
• Quality-related
• focus on quality of work products and deliverables
• Productivity-related
• Production of work-products related to effort expended
• Statistical SQA data
• error categorization & analysis
• Defect removal efficiency
• propagation of errors from process activity to activity
• Reuse data
• The number of components produced and their degree of
reusability
 Typical Project Metrics

• Effort/time per software engineering task

• Errors uncovered per review hour
• Scheduled vs. actual milestone dates
• Changes (number) and their characteristics
• Distribution of effort on software engineering tasks
 Typical Size-Oriented Metrics

• errors per KLOC (thousand lines of code)

• defects per KLOC
• $ per LOC
• pages of documentation per KLOC
• errors per person-month
• errors per review hour
• LOC per person-month
• $ per page of documentation
 Typical Function-Oriented Metrics
• errors per FP (thousand lines of code)
• defects per FP
• $ per FP
• pages of documentation per FP
• FP per person-month
 Function-Oriented Metrics
• FP are computed by
FP = count-total * [0.65 + 0.01 * Sum(Fi)]
• count-total is the sum of all FP entries
• The Fi (i = 1 to 14) are "complexity adjustment values" based on
responses to the following questions [ART85]:
1. Does the system require reliable backup and recovery?
2. Are data communications required?
3. Are there distributed processing functions?
4. Is performance critical?
...
• Each of these questions is answered using a scale that ranges from 0 (not
important or applicable) to 5 (absolutely essential).
Comparing LOC and FP

Programming LOC per Function point

Language avg. median low high
Ada 154 - 104 205
Assembler 337 315 91 694
C 162 109 33 704
C++ 66 53 29 178
COBOL 77 77 14 400
Java 63 53 77 -
JavaSc ript 58 63 42 75
Perl 60 - - -
PL/1 78 67 22 263
Powerbuilder 32 31 11 105
SAS 40 41 33 49
Smalltalk 26 19 10 55
SQL 40 37 7 110
Visual Basic 47 42 16 158

Representative values developed by QSM

 Object-Oriented Metrics

• Number of scenario scripts (use-cases)

• Number of support classes (required to implement
the system but are not immediately related to the
problem domain)
• Average number of support classes per key class
(analysis class)
• Number of subsystems (an aggregation of classes that
support a function that is visible to the end-user of a
system)
 WebApp Project Metrics
• Number of static Web pages (the end-user has no control over the content
displayed on the page)
• Number of dynamic Web pages (end-user actions result in customized
content displayed on the page)
• Number of internal page links (internal page links are pointers that provide
a hyperlink to some other Web page within the WebApp)
• Number of persistent data objects
• Number of external systems interfaced
• Number of static content objects
• Number of dynamic content objects
• Number of executable functions
 Measuring Quality

• Correctness — the degree to which a program

operates according to specification
• Maintainability—the degree to which a program is
amenable to change
• Integrity—the degree to which a program is
impervious to outside attack
• Usability—the degree to which a program is easy to
use
Defect Removal Efficiency

DRE = E /(E + D)

where:
E is the number of errors found before
delivery of the software to the end-user
D is the number of defects found after
delivery.
 Estimation for Software
Projects
Software 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 required human resources
• Define reusable software resources
• Identify environmental resources
 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
• Establish a meaningful task set
• Define a task network
• Use scheduling tools to develop a timeline chart
• Define schedule tracking mechanisms
 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
 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.
 Resource Estimation

• Three major categories of software engineering resources

• People
• Development environment
• Reusable software components
• Often neglected during planning but become a paramount concern during
the construction phase of the software process
• Each resource is specified with
• A description of the resource
• A statement of availability
• The time when the resource will be required
• The duration of time that the resource will be applied
Time window
 Categories of Resources
People Development Environment
- Number required - Software tools
- Skills required - Computer hardware
- Geographical location - Network resources

The
Project

Reusable Software Components

- Off-the-shelf components
- Full-experience components
- Partial-experience components
- New components
 Human Resources

• Planners need to select the number and the kind of people

skills needed to complete the project
• They need to specify the organizational position and job
specialty for each person
• Small projects of a few person-months may only need one
individual
• Large projects spanning many person-months or years require
the location of the person to be specified also
• The number of people required can be determined only after
an estimate of the development effort
 Development Environment Resources

• A software engineering environment (SEE) incorporates

hardware, software, and network resources that provide
platforms and tools to develop and test software work products
• Most software organizations have many projects that require
access to the SEE provided by the organization
• Planners must identify the time window required for hardware
and software and verify that these resources will be available
 Reusable Software Resources

• Off-the-shelf components
• Components are from a third party or were developed for a
previous project
• Ready to use; fully validated and documented; virtually no risk
• Full-experience components
• Components are similar to the software that needs to be built
• Software team has full experience in the application area of these
components
• Modification of components will incur relatively low risk
 Reusable Software Resources

• Partial-experience components
• Components are related somehow to the software that needs to
be built but will require substantial modification
• Software team has only limited experience in the application area
of these components
• Modifications that are required have a fair degree of risk
• New components
• Components must be built from scratch by the software team
specifically for the needs of the current project
• Software team has no practical experience in the application area
• Software development of components has a high degree of risk
Estimation Techniques

• Past (similar) project experience

• Conventional estimation techniques
– task breakdown and effort estimates
– size (e.g., FP) estimates
• Empirical models
• Automated tools
Functional Decomposition

Statement functional
of decomposition
Scope Perform a Grammatical
“parse”
 Problem-Based Estimation
• Start with a bounded statement of scope
• Decompose the software into problem functions that can
each be estimated individually
• Compute an LOC or FP value for each function
• Derive cost or effort estimates by applying the LOC or FP
values to your baseline productivity metrics (e.g.,
LOC/person-month or FP/person-month)
• Combine function estimates to produce an overall estimate
for the entire project
 Problem-Based Estimation
• In general, the LOC/pm and FP/pm metrics should be computed
by project domain
• Important factors are team size, application area, and complexity
• LOC and FP estimation differ in the level of detail required for
decomposition with each value
• For LOC, decomposition of functions is essential and should go
into considerable detail (the more detail, the more accurate the
estimate)
• For FP, decomposition occurs for the five information domain
characteristics and the 14 adjustment factors
• External inputs, external outputs, external inquiries, internal logical
files, external interface files
 Problem-Based Estimation

• For both approaches, the planner uses lessons learned to

estimate an optimistic, most likely, and pessimistic size value
for each function or count (for each information domain value)
• Then the expected size value S is computed as follows:

S = (Sopt + 4Sm + Spess)/6

• Historical LOC or FP data is then compared to S in order to

cross-check it
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 estimated effort is
54 person-months.
 Example: FP Approach

The estimated number of FP is derived:

FPestimated = count-total * [0.65 + 0.01 * Sum(Fi)] (see next)
FPestimated = 375
organizational average productivity = 6.5 FP/pm.
burdened labor rate = $8000 per month, the cost per FP is approximately $1230.
Based on the FP estimate and the historical productivity data, the total estimated
project cost is $461,000 and the estimated effort is 58 person-months.
 Complexity Adjustment Factor
Factor Value • Answer the factors
• Backup and recovery 4 using a scale that
• Data communications 2 ranges from 0 (not
• Distributed processing 0 important or applicable)
to 5 (absolutely
• Performance critical 4
essential)
• Existing operating environment 3
• Sum(Fi)=52
• On-line data entry 4
• Input transaction over multiple screens 5
• Master files updated on-line 3
• Information domain values complex 5
• Internal processing complex 5
• Code designed for reuse 4
• Conversion/installation in design 3
• Multiple installations 5
• Application designed for change 5
 Example: FP Approach

The estimated number of FP is derived:

FPestimated = count-total * [0.65 + 0.01 * Sum(Fi)]
FPestimated = 375
organizational average productivity = 6.5 FP/pm.
burdened labor rate = $8000 per month, the cost per FP is approximately $1230.
Based on the FP estimate and the historical productivity data, the total estimated
project cost is $461,000 and the estimated effort is 58 person-months.
 Process-Based Estimation
• Identify the set of functions that the software needs to
perform as obtained from the project scope
• Identify the series of framework activities that need to be
performed for each function
• Estimate the effort (in person months) that will be required
to accomplish each software process activity for each
function
 Process-Based Estimation
• Apply average labor rates (i.e., cost/unit effort) to the effort
estimated for each process activity
• Compute the total cost and effort for each function and
each framework activity (See table in Pressman, p. 655)
• Compare the resulting values to those obtained by way of
the LOC and FP estimates
• If both sets of estimates agree, then your numbers are highly
reliable
• Otherwise, conduct further investigation and analysis
concerning the function and activity breakdown

This is the most commonly used of the two estimation

techniques (problem and process)
Process-Based Estimation

Obtained from “process framework”

framework activities

application Effort required to

functions accomplish
each framework
activity for each
application function
 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.
Tool-Based Estimation

project characteristics

calibration factors

LOC/FP data
Estimation with Use-Cases

use cases scenarios pages scenarios pages LOC LOC estimate

e subsystem
User interface subsystem 6 10 6 12 5 560 3,366
Engineering subsystem group
subsystem group 10 20 8 16 8 3100 31,233
Infrastructure subsystemgroup
e subsystem group 5 6 5 10 6 1650 7,970
Total LOC estimate
stimate 42,568

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.
Empirical Estimation Models
General form:

exponent
effort = tuning coefficient * size

usually derived
as person-months empirically
of effort required derived

usually LOC but

may also be
function point
either a constant or
a number derived based
on complexity of project
 COCOMO-II

• 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.
 The Software Equation

A dynamic multivariable model

E = [LOC x B0.333/P]3 x (1/t4)

where
E = effort in person-months or person-years
t = project duration in months or years
B = “special skills factor”
P = “productivity parameter”
 Estimation for OO Projects-I
• Develop estimates using effort decomposition, FP analysis, and any other
method that is applicable for conventional applications.
• Using object-oriented analysis modeling (Chapter 8), develop use-cases and
determine a count.
• From the analysis model, determine the number of key classes (called
analysis classes in Chapter 8).
• Categorize the type of interface for the application and develop a multiplier
for support classes:
• Interface type Multiplier
• No GUI 2.0
• Text-based user interface 2.25
• GUI 2.5
• Complex GUI 3.0
 Estimation for OO Projects-II

• Multiply the number of key classes (step 3) by the multiplier to

obtain an estimate for the number of support classes.
• Multiply the total number of classes (key + support) by the
average number of work-units per class. Lorenz and Kidd
suggest 15 to 20 person-days per class.
• Cross check the class-based estimate by multiplying the
average number of work-units per use-case
The Make-Buy Decision
Computing Expected Cost

expected cost =
(path probability) x (estimated path cost)
i i

For example, the expected cost to build is:

expected cost = 0.30 ($380K) + 0.70 ($450K)

build
= $429 K
similarly,

expected cost = $382K

reuse
expected cost = $267K
buy
expected cost = $410K
contr
Project Scheduling
 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
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
Scheduling Principles

• “front end” activities

40-50% – customer communication
– analysis
– design
– review and modification
• construction activities
15-20% – coding or code generation
• testing and installation
– unit, integration
– white-box, black box
– regression
30-40%
 40-20-40 Distribution of Effort

• A recommended distribution of effort across the software process is

40% (analysis and design), 20% (coding), and 40% (testing)
• Work expended on project planning rarely accounts for more than 2 -
3% of the total effort
• Requirements analysis may comprise 10 - 25%
• Effort spent on prototyping and project complexity may increase this
• Software design normally needs 20 – 25%
• Coding should need only 15 - 20% based on the effort applied to
software design
• Testing and subsequent debugging can account for 30 - 40%
• Safety or security-related software requires more time for testing
 Basic Principles for Project Scheduling

• Compartmentalization
• The project must be compartmentalized into a number of
manageable activities, actions, and tasks; both the product and
the process are decomposed
• Interdependency
• The interdependency of each compartmentalized activity, action,
or task must be determined
• Some tasks must occur in sequence while others can occur in
parallel
• Some actions or activities cannot commence until the work
product produced by another is available
 Basic Principles for Project Scheduling

• Time allocation
• Each task to be scheduled must be allocated some number of
work units
• In addition, each task must be assigned a start date and a
completion date that are a function of the interdependencies
• Start and stop dates are also established based on whether work
will be conducted on a full-time or part-time basis
• Effort validation
• Every project has a defined number of people on the team
• 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
 Basic Principles for Project Scheduling
• 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 such as a work product or part of a work
product
• Work products are often combined in deliverables
• Defined milestones
• Every task or group of tasks should be associated with a project
milestone
• A milestone is accomplished when one or more work products has
been reviewed for quality and has been approved
 Relationship Between
People and Effort
• Common management myth: If we fall behind schedule, we can
always add more programmers and catch up later in the
project
• This practice actually has a disruptive effect and causes the
schedule to slip even further
• The added people must learn the system
• The people who teach them are the same people who were
earlier doing the work
• During teaching, no work is being accomplished
• Lines of communication (and the inherent delays) increase for
each new person added
 Factors that Influence a Project’s
Schedule
• Size of the project
• Number of potential users
• Mission criticality
• Application longevity
• Stability of requirements
• Ease of customer/developer communication
• Maturity of applicable technology
• Performance constraints
• Embedded and non-embedded characteristics
• Project staff
• Reengineering factors
 Purpose of a Task Network

• Also called an activity network

• It is a graphic representation of the task flow for a project
• It depicts task length, sequence, concurrency, and dependency
• Points out inter-task dependencies to help the manager ensure
continuous progress toward project completion
• The critical path
• A single path leading from start to finish in a task network
• It contains the sequence of tasks that must be completed on
schedule if the project as a whole is to be completed on schedule
• It also determines the minimum duration of the project
 Example Task Network

Task F Task G Task H

Task B 2 3 5
3
Task N
Task A 2
Task C Task E Task I Task J
3
7 8 4 5
Task M
0
Task D
5 Task K Task L
3 10

Where is the critical path and what tasks are on it?

 Example Task Network

Task F Task G Task H

Task B 2 3 5
3
Task N
Task A 2
Task C Task E Task I Task J
3
7 8 4 5
Task M
0
Task D
5 Task K Task L
3 10

Critical path: A-B-C-E-K-L-M-N

Timeline Charts
Tasks Week 1 Week 2 Week 3 Week 4 Week n

Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Task 11
Task 12
Use Automated Tools to
Derive a Timeline Chart
Example Timeline Charts
Proposed Tasks for a Long-Distance Move
of 8,000 lbs of Household Goods
Pack Arrange for
Make household Determine
workers to
decision goods destination
unload truck
to move location
Determine
Make
Drive truck date to move Reserve lodging
from origin out or move in rental truck Get money
reservations
to destination and supplies to pay for
the move
Decide on Find lodging
Unload type/size of with space Lease or buy
Plan travel
truck rental truck to park truck home at
route and
overnight stops destination

Arrange for Return

workers to truck and Pick up Load Arrange for
load truck supplies rental truck truck person to
drive truck/car

• Where is the critical path and what tasks are on it?

• Given a firm start date, on what date will the project be completed?
• Given a firm stop date, when is the latest date that the project must start by?
 2. Get money
to pay for
the move
Proposed Tasks for a Long-Distance
3. Determine
date to move
out or move in
Move of 8,000 lbs of Household Goods
12. Plan travel 13. Find lodging 14. Make
4. Determine
route and with space lodging
destination
overnight stops to park truck reservations
location
5. Lease or buy
home at
destination

6. Decide on 18. Drive truck

19. Unload
type/size of 11. Milestone from origin
truck
rental truck to destination

7. Arrange for
workers to
load truck
15. Reserve
16. Pick up 17. Load 20. Return
8. Arrange for rental truck
rental truck truck truck and
person to and supplies
drive truck/car supplies

9. Arrange for
workers to
unload truck

10. Pack • Where is the critical path and what tasks are on it?
household • Given a firm start date, on what date will the project be completed?
goods • Given a firm stop date, when is the latest date that the project must start by?
Timeline Chart for Long Distance Move