Software Engineering

Chapter- One
Introduction

1
 What is software?
Computer programs and associated documentation

Software products may be developed for a particular

customer or may be developed for a general market
Software products may be
◦ Generic - developed to be sold to a range of different customers
◦ Bespoke (custom) - developed for a single customer according to
their specification

2
Why Software Engineering ?
1950s and 1960s, Systems Development was
unstructured & unorganized
Leap-year bug
 A supermarket was fined $1000 for having meat around 1 day too long, on February 29, 1988.

Interface misuse
 On April 10, 1990, in London, an underground train left the station without its driver.

Security
 On November 2, 1988, a self-propagating program, subsequently called the Internet Worm, An estimated
10% of all Internet nodes were affected. The infection took several days to eradicate.

3
Cont…
Late and over budget
 In 1995, bugs in the automated luggage system of the new Denver International Airport caused
suitcases to be chewed up. The airport opened 16 months late, $3.2 billion over-budget, with a mostly
manual luggage system.

On-time delivery
 After 18 months of development, a $200 million system was delivered to a health insurance company
in Wisconsin in 1984. However, the system did not work correctly: $60 million in overpayments were
issued. The system took 3 years to fix.

Unnecessary complexity
 The C-17 cargo plane by McDonnell Douglas ran $500 million over budget because of problems with its
avionics software. The C-17 included 19 onboard computers, 80 microprocessors, and 6 different
programming languages.

4
 Cont..
SE introduced first in 1968 – conference about “software
crisis” when the introduction of third generation
computer hardware led more complex software systems
then before
Early approaches based on informal methodologies
leading to
◦ Delays in software delivery
◦ Higher costs than initially estimated
◦ Unreliable, difficult to maintain software
Need for new methods and techniques to manage the
production of complex software.

5
However …
Important progress:
Ability to produce more complex software has
increased
New technologies have led to new SE approaches
A better understanding of the activities involved in
software development
Effective methods to specify, design and implement
software have been developed
New notations and tools have been produced

6
I. What is Software Engineering?
Software engineering is the establishment and use of sound engineering
principles in order to obtain economically software that is reliable and works
efficiently on real machines.

Software engineering is a modeling activity.

Software engineering is a problem-solving activity.
Software engineering is a knowledge acquisition activity.
Software engineering is a rationale-driven activity.

7
Cont..
1. Modeling Activity:
A model is an abstract representation of a system that enables us to answer
questions about the system.
Software engineers deal with complexity through modeling, by focusing at any
one time on only the relevant details and ignoring everything else.
Models are useful when dealing with systems that are too large, too small, too
complicated, or too expensive to experience firsthand.

8
Cont…
2. Problem solving
Engineering is a problem-solving activity. It is not algorithmic. In its
simplest form, the engineering method includes five steps:
1. formulate the problem
2. analyze the problem
3. search for solutions
4. decide on the appropriate solution
5. specify the solution

9
Cont…
3. Knowledge acquisition
In modeling the application and solution domain, software engineers collect
data, organize it into information, and formalize it into knowledge.

Knowledge acquisition is nonlinear, as a single piece of data can invalidate

complete models.

A common mistake that software engineers and managers make is to assume

that the acquisition of knowledge needed to develop a system is linear.

10
 Cont…
4. Rationale management
When acquiring knowledge and making decisions about the system or its
application domain, software engineers also need to capture the context in
which decisions were made and the rationale behind these decisions.
◦ Enables software engineers to understand the implication of a proposed change when
revisiting a decision.

11
 What is the difference between software
engineering and computer science?
Computer Science Software Engineering
is concerned with
 theory  the practicalities of developing
 fundamentals  delivering useful software

Algorithms, date structures, SE deals with practical problems in

complexity theory, numerical complex software products
methods
Computer science theories are currently insufficient to act as a complete underpinning for
software engineering, BUT it is a foundation for practical aspects of software engineering

12
 Software Engineering Body of Knowledge

Source: http://www.sei.cmu.edu/pub/documents/99.reports/pdf/99tr004.pdf

13
 What is a software process?
SP is a set of activities whose goal is the development or
evolution of software
Fundamental activities in all software processes are:
◦ Specification - what the system should do
and its development constraints
◦ Development - production of the software system
(design and implementation)
◦ Validation - checking that the software is what the customer wants
◦ Evolution - changing the software in response to changing
demands

14
 What is a software process model?
SPM is a simplified representation of a software process,
presented from a specific perspective

Examples of process perspectives:

Workflow perspective represents inputs, outputs and dependencies
Data-flow perspective represents data transformation activities
Role/action perspective represents the roles/activities of the
people involved in software process
Generic process models
◦ Waterfall
◦ Evolutionary development
◦ Formal transformation
◦ Integration from reusable components

15
 What is CASE ?
(Computer-Aided Software Engineering)
Software systems which are intended to provide
automated support for software process activities,
such as requirements analysis, system modelling,
debugging and testing
Upper-CASE
◦ Tools to support the early process activities of
requirements and design

Lower-CASE
◦ Tools to support later activities such as programming, debugging and testing

16
What are the attributes of good software?
The software should deliver the required functionality and
performance to the user and should be maintainable,
dependable and usable

Maintainability
◦ Software must evolve to meet changing needs
Dependability
◦ Software must be trustworthy
Efficiency
◦ Software should not make wasteful use of system resources
Usability
◦ Software must be usable by the users for which it was designed
17
 What are the key challenges
facing software engineering?
Software engineering in the 21st century faces three key challenges:

Legacy systems
◦ Old, valuable systems must be maintained and updated
Heterogeneity
◦ Systems are distributed and include
a mix of hardware and software
Delivery
◦ There is increasing pressure
for faster delivery of software

18
Thank You!
Q?

19
Software Engineering

Chapter Two
Software processes

20
The software process
Software process: organizing a structured set of
activities to develop software systems.
Many different software processes but all involve the
following activities:

◦ Specification – defining what the system should do;

◦ Design and implementation – defining the organization of
the system and implementing the system;
◦ Validation – checking that it does what the customer
wants;
◦ Evolution – changing the system in response to changing
customer needs.

21
The Software Process
A structured set of activities required to develop a software system
◦ Specification
◦ Analysis, design and implementation.
◦ Validation
◦ Evolution

A software process model is an abstract representation of a process

◦ It presents a description of a process from some particular perspective

22
Waterfall Model

Requirements
definition

System and
software design

Implementation
and unit testing

Integr ation and

system testing

Operation and
maintenance

23
Waterfall model phases
Requirements analysis and definition
System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance

The drawback of the waterfall model is the difficulty of accommodating

change after the process is underway

24
Waterfall model Requirement and Design

Artefacts produced in the requirements and Design

phases
SRS -Software Requirements specification document
SRS might include:
◦ User usage stories (scenarios) – Use cases.
◦ Static analysis – class diagrams.
◦ Behavioural analysis – sequence diagrams, state charts.

The specification and design activities are heavily time consuming.

25
Waterfall model problems
Inflexible partitioning of the project into distinct stages
Difficult to respond to changing customer requirements

This model is only appropriate when the requirements are well-understood

Waterfall model describes a staged development process

◦ Based on hardware engineering models
◦ Change during development is unlikely
◦ Widely used in large systems: military and aerospace
industries

26
When to use the Waterfall Model
Requirements are very well known
Product definition is stable
Technology is understood
New version of an existing product
Porting an existing product to a new platform.

27
V-Shaped SDLC Model
A variant of the Waterfall that
emphasizes the verification and
validation of the product.
Testing of the product is
planned in parallel with a
corresponding phase of
development

28
V-Shaped Steps
Project and Requirements Planning – Production, operation and maintenance –
allocate resources provide for enhancement and corrections
System and acceptance testing – check the
entire software system in its environment
Product Requirements and Specification
Analysis – complete specification of the
software system

Integration and Testing – check that modules

Architecture or High-Level Design – defines interconnect correctly
how software functions fulfill the design

Unit testing – check that each module acts

Detailed Design – develop algorithms for as expected
each architectural component

Coding – transform algorithms into software

29
V-Shaped Strengths
Emphasize planning for verification and validation of the product in
early stages of product development
Each deliverable must be testable
Project management can track progress by milestones
Easy to use

30
V-Shaped Weaknesses
Does not easily handle concurrent events
Does not handle iterations or phases
Does not easily handle dynamic changes in requirements
Does not contain risk analysis activities

31
When to use the V-Shaped Model
Excellent choice for systems requiring high reliability – hospital patient
control applications
All requirements are known up-front
When it can be modified to handle changing requirements beyond
analysis phase
Solution and technology are known

32
Structured Evolutionary Prototyping
Model
Developers build a prototype during the requirements phase
Prototype is evaluated by end users
Users give corrective feedback
Developers further refine the prototype
When the user is satisfied, the prototype code is brought up to the
standards needed for a final product.

33
34
Structured Evolutionary Prototyping
Steps
A preliminary project plan is developed
An partial high-level paper model is created
The model is source for a partial requirements specification
A prototype is built with basic and critical attributes
The designer builds
◦ the database
◦ user interface
◦ algorithmic functions
The designer demonstrates the prototype, the user evaluates for
problems and suggests improvements.
This loop continues until the user is satisfied

35
Structured Evolutionary Prototyping
Strengths
Customers can “see” the system requirements as they
are being gathered
Developers learn from customers
A more accurate end product
Unexpected requirements accommodated
Allows for flexible design and development
Steady, visible signs of progress produced
Interaction with the prototype stimulates awareness of
additional needed functionality

36
Structured Evolutionary Prototyping
Weaknesses
Tendency to abandon structured program
development for “code-and-fix” development
Bad reputation for “quick-and-dirty” methods
Overall maintainability may be overlooked
The customer may want the prototype delivered.
Process may continue forever (scope creep)

37
When to use
Structured Evolutionary Prototyping
Requirements are unstable or have to be clarified
As the requirements clarification stage of a
waterfall model
Develop user interfaces
Short-lived demonstrations
New, original development
With the analysis and design portions of object-
oriented development.

38
Rapid Application Model (RAD)
Requirements planning phase (a workshop utilizing
structured discussion of business problems)
User description phase – automated tools capture
information from users
Construction phase – productivity tools, such as code
generators, screen generators, etc. inside a time-box.
(“Do until done”)
Cutover phase -- installation of the system, user
acceptance testing and user training

39
RAD Strengths
Reduced cycle time and improved productivity with
fewer people means lower costs
Time-box approach mitigates cost and schedule risk
Customer involved throughout the complete cycle
minimizes risk of not achieving customer
satisfaction and business needs
Focus moves from documentation to code.
Uses modeling concepts to capture information
about business, data, and processes.

40
RAD Weaknesses
Accelerated development process must give quick
responses to the user
Risk of never achieving closure
Hard to use with legacy systems
Requires a system that can be modularized
Developers and customers must be committed to
rapid-fire activities in an abbreviated time frame.

41
When to use RAD
Reasonably well-known requirements
User involved throughout the life cycle
Project can be time-boxed
Functionality delivered in increments
High performance not required
Low technical risks
System can be modularized

42
Incremental Development
Rather than deliver the system as a single delivery, the development and
delivery is broken down into increments with each increment delivering
part of the required functionality.
User requirements are prioritised and the highest priority requirements
are included in early increments.
Once the development of an increment is started, the requirements are
frozen though requirements for later increments can continue to evolve.

43
Incremental Development

Define outline Assign requirements Design system

requirements to increments architecture

Develop system Valida te Integrate Valida te

increment increment increment system
Final
system
System incomplete

44
Incremental Development –Advantages
Customer value can be delivered with each
increment so system functionality is available earlier.
Early increments act as a prototype to help elicit
requirements for later increments.
Lower risk of overall project failure.
The highest priority system services
tend to receive the most testing.

45
Incremental Model Strengths
Each release delivers an operational product
Customer can respond to each build
Uses “divide and conquer” breakdown of tasks
Lowers initial delivery cost
Initial product delivery is faster
Customers get important functionality early
Risk of changing requirements is reduced

46
Incremental Development – Problems
Lack of process visibility.
Systems are often poorly structured.

Applicability claims in the literature:

◦ For small or medium-size interactive systems.
◦ For parts of large systems (e.g. the user interface).
◦ For short-lifetime systems.

47
When to use the Incremental Model
Risk, funding, schedule, program complexity, or need for
early realization of benefits.
Most of the requirements are known up-front but are
expected to evolve over time
A need to get basic functionality to the market early
On projects which have lengthy development schedules
On a project with new technology

48
Incremental means adding, iterative means
reworking (by Alistair Cockburn)
Incremental development is a staging and scheduling strategy in which the various
parts of the system are developed at different times or rates and integrated as
they are completed. The alternative is to develop the entire system with a big
bang integration at the end.
Iterative development is a rework scheduling strategy in which time is set aside to
revise and improve parts of the system. The alternative development is to get it
right the first time (or at least declare that it is right!).

Iterate Increment
fundamentally means fundamentally means “add
“change”. onto”.
repeating the process on the repeating the process on a
same section of work new section of work.
repeat the process (, design, repeat the process (, design,
implement, evaluate), implement, evaluate),

49
Problems with incremental development (from a
waterfall eye…)
Management problems
◦ Progress can be hard to judge and problems hard to find because
there is no documentation to demonstrate what has been done.

Contractual problems
◦ The normal contract may include a specification; without a
specification, different forms of contract have to be used.

Validation problems
◦ Without a specification, what is the system being tested against?

Maintenance problems
◦ Continual change tends to corrupt software structure making it
more expensive to change and evolve to meet new requirements.

50
Incremental & iterative - summary
Iterative model - This model iterates requirements, design, build and test
phases again and again for each requirement and builds up a system
iteratively till the system is completely build.
Incremental model - It is non integrated development model. This model
divides work in chunks and one team can work on many chunks. It is more
flexible.
Spiral model - This model uses series of prototypes in stages,
the development ends when the prototypes are developed into functional
system. It is flexible model and used for large and complicated projects.
Evolutionary model - It is more customer focused model. In this model the
software is divided in small units which is delivered earlier to the customers.
V-Model - It is more focused on testing. For every phase some testing activity
are done.

51
Spiral Development
Process is conceived as a spiral rather than as a sequence of activities
with backtracking.
Each loop in the spiral represents a phase in the process.
No fixed phases such as specification or design - loops in the spiral are
chosen depending on what is required.
Risks are explicitly assessed and resolved throughout the process.

52
Spiral model (Boehm 87)
Objective setting Risk assessment and reduction
Specific objectives for the Risks are assessed and activities
phase are identified. put in place to reduce the key
risks.

Planning Development and validation

The project is reviewed and the A development model for the
next phase of the spiral is system is chosen which can be
planned. any of the generic models.

53
Spiral model sectors
Objective setting
◦ Specific objectives for the phase are identified.

Risk assessment and reduction

◦ Risks are assessed and activities put in place to reduce the key risks.

Development and validation

◦ A development model for the system is chosen which can be any of the
generic models.

Planning
◦ The project is reviewed and the next phase of the spiral is planned.

54
Spiral Model Strengths
Provides early indication of insurmountable risks,
without much cost
Users see the system early because of rapid
prototyping tools
Critical high-risk functions are developed first
The design does not have to be perfect
Users can be closely tied to all lifecycle steps
Early and frequent feedback from users
Cumulative costs assessed frequently

55
Spiral Model Weaknesses
Time spent for evaluating risks too large for small or low-risk projects
Time spent planning, resetting objectives, doing risk analysis and
prototyping may be excessive
The model is complex
Risk assessment expertise is required
Spiral may continue indefinitely
Developers must be reassigned during non-development phase
activities
May be hard to define objective, verifiable milestones that indicate
readiness to proceed through the next iteration

56
When to use Spiral Model
When creation of a prototype is appropriate
When costs and risk evaluation is important
For medium to high-risk projects
Long-term project commitment unwise because of
potential changes to economic priorities
Users are unsure of their needs
Requirements are complex
New product line
Significant changes are expected (research and
exploration)

57
Agile Development

58
Project Failure – the trigger for Agility
One of the primary causes of project failure was the extended period of
time it took to develop a system.
Costs escalated and requirements changed.

Agile methods intend to develop systems more quickly with limited

time spent on analysis and design.

59
What is an Agile method? (1)
Focus on the code rather than the design.
Based on an iterative approach to software development.
Intended to deliver working software quickly.
Evolve quickly to meet changing requirements.
There are claims that agile methods are probably best
suited to small/medium-sized business systems or PC
products.

60
What is an agile method? (2)
Agile methods are considered
◦ Lightweight
◦ People-based rather than Plan-based

Several agile methods

◦ No single agile method
◦ Extreme Programming (XP) most popular

No single definition
Agile Manifesto closest to a definition
◦ Set of principles
◦ Developed by Agile Alliance

61
Summary of Principles of agile methods
Principle Description
Customer involvement The customer should be closely involved throughout the
development process. Their role is provide and prioritise new
system requirements and to evaluate the iterations of the system.
Incremental delivery The software is developed in increments with the customer
specifying the requirements to be included in each increment.
People not process The skills of the development team should be recognised and
exploited. The team should be left to develop their own ways of
working without prescriptive processes.
Embrace change Expect the system requirements to change and design the system
so that it can accommodate these changes.
Maintain simplicity Focus on simplicity in both the software being developed and in
the development process used. Wherever possible, actively work
to eliminate complexity from the system.

62
eXtreme Programming
Development and delivery of very small increments of functionality.
Relies on constant code improvement, user involvement in the
development team and pair wise programming.
Emphasizes Test Driven Development (TDD) as part of the small
development iterations.

63
XP Practices (1-6)
1. Planning game – determine scope of the next release by combining
business priorities and technical estimates
2. Small releases – put a simple system into production, then release
new versions in very short cycle
3. Metaphor – all development is guided by a simple shared story of
how the whole system works
4. Simple design – system is designed as simply as possible (extra
complexity removed as soon as found)
5. Testing – programmers continuously write unit tests; customers
write tests for features
6. Refactoring – programmers continuously restructure the system
without changing its behavior to remove duplication and simplify

64
XP Practices (7 – 12)
7. Pair-programming -- all production code is written with two
programmers at one machine
8. Collective ownership – anyone can change any code
anywhere in the system at any time.
9. Continuous integration – integrate and build the system
many times a day – every time a task is completed.
10. 40-hour week – work no more than 40 hours a week as a rule
11. On-site customer – a user is on the team and available full-
time to answer questions
12. Coding standards – programmers write all code in accordance
with rules emphasizing communication through the code

65
Software Engineering

Chapter Three
Requirement Engineering

66
 Software Requirements
Requirements are descriptions of the services that a software system
must provide and the constraints under which it must operate
Requirements Engineering is the process of establishing the services
that the customer requires from the system and the constraints under
which it is to be developed and operated
Requirements may serve a dual function:
As the basis of a bid for a contract
As the basis for the contract itself

67
Characteristics of a Good Requirement
Clear and Unambiguous
◦ standard structure
◦ has only one possible interpretation
◦ Not more than one requirement in one sentence
Correct
◦ A requirement contributes to a real need
Understandable
◦ A reader can easily understand the meaning of the requirement
Verifiable
◦ A requirement can be tested
Complete
Consistent
Traceable

68
The Requirement Engineering
Process
The process of establishing what services are required and the
constraints on the system’s operation and development
Requirements engineering help software engineers to better
understand the problem they will work to solve. It encompasses the set
of tasks that lead to an understanding of what the business impact of
the software will be, what the customer wants and how end-users will
interact with the software.

Requirement Engineering Process

◦ Feasibility Study
◦ Requirements elicitation and analysis
◦ Requirements Specification
◦ Requirements Validation

69
The Requirements Engineering
Process

70
Requirements Elicitation
It is the practice of obtaining the requirements of a system from users,
customers and other stakeholders. The practice is also sometimes
referred to as Requirement gathering.

Requirements elicitation practice include the following:

◦ Interviews
◦ Questionnaires
◦ User observation
◦ Workshops
◦ Brain storming
◦ Use cases
◦ Role playing
◦ And prototyping

71
Example 1:LIBSYS scenario (1)
Initial assumption: The user has logged on to the LIBSYS system and has located the journal containing
the copy of the article .
Norm al: The user selects the article to be copied. He or she is then prompted by the system to ei ther
provide subscriber information for the journal or to indicate how they will pay for the article . Alte rnative
payment me thods are by credit card or by quoting an organisational account number.
The user is then asked to fill in a copyright form that ma intains details of the transaction and they then
submit this to the LIBSYS sys tem.
The copyright fo rm is c hecked and, if OK, the PDF version of the artic le is d ownloaded to the LIBSYS
working area on the userÕscomputer and the user is informed that it is available. The user is asked to selec t
a printer and a copy of the article is printed. If the article has been flagged as Ōprint-onlyÕit i s deleted from
the userÕs system o nce the user has confirmed that printing is complete.

72
 LIBSYS scenario (2)
What can go wrong: The user may fail to fill in the copyright form correctly. In this case, the fo rm should
be re-presented to the user for correction. If the resubmitted form is s till incorrect then the userÕsrequest
for the article is rejected.
The payment ma y be rejected by the system. The userÕs er quest for the article is rejected.
The article download may fail. Retry until successful o r the user terminates the session.
It may not be possible to print the article. If the article is not flagged as Ōprint-onlyÕthen it is held in the
LIBSYS workspace. Otherwise, the artic le is d eleted and the userÕs account credited with the cost of the
article .
Other activities: Simultaneous d ownloads of other article s.
System state on completion: User is logged on. The downloaded article has been dele ted from LIBSYS
workspace if it has been flagged as print-only.

73
Use cases
A scenario-based technique in UML which identify the actors in an
interaction and which describe the interaction itself.
Used also to clarify the system boundaries.
A set of use cases should describe all possible interactions with the
system.
Sequence diagrams show the interactions and event processing inside a
use case.

74
Example 2:
Scenario for collecting medical history in MHC-PMS

76
Scenario for collecting medical
history in MHC-PMS

77
Use cases for the MHC-PMS

78
Requirements Elicitation
Problems of Requirement Elicitation
◦ Problems of scope: The boundary of system is ill-defined. Or unnecessary
details are provided.
◦ Problems of understanding: The users are not sure of what they need, and
don’t have full understanding of the problem domain.
◦ Problems of volatility: the requirements change overtime.

79
Problems of requirements elicitation
Stakeholders don’t know what they really want.
Stakeholders express requirements in their own terms.
Different stakeholders may have conflicting requirements.
Organisational and political factors may influence the
system requirements.
The requirements change during the analysis process. New
stakeholders may emerge and the business environment
change.

80
 Requirements Analysis
Requirements Analysis, determining whether the stated requirements are
clear, complete, consistent and unambiguous.

81
 Requirements Analysis
Stakeholder Identification
◦ Stakeholders are people or organizations that have a valid interest in the system.
They may be affected by it directly or indirectly.
◦ Stake holders may include:
◦ Anyone who operates the system
◦ Anyone who benefits from the system
◦ Anyone involved in purchasing or procuring the system
◦ People opposed to the system (negative stakeholders)
◦ Organizations responsible for the system

82
 Requirements Analysis
Stakeholder Interviews
◦ Interviews are a common technique used in requirement analysis.
◦ This technique can serve as a means of obtaining the highly focused knowledge
from different stakeholders perspectives

83
 Requirements Analysis
Types of Requirements:
◦ Customer Requirements:
◦ Operational distribution or deployment: Where will the system be used?
◦ Mission profile or scenario: How will the system accomplish its mission
objective?
◦ Performance and related parameters: What are the critical system parameters
to accomplish the mission?
◦ Utilization environments: how are the various system components to be
used?
◦ Effectiveness requirements: How effective or efficient must the system be in
performing its mission?
◦ Operational life cycle: How long will the system be in use by the user?
◦ Environment: what environments will the system be expected to operate in an
effective manner?

84
 Requirements Analysis
Types of Requirements:
◦ Architectural Requirements:
◦ A formal description and representation of a system, organized in a way that support reasoning about the
structure of the system which comprises system components, the externally visible properties of those
components, the relationships and the behavior between them, and provides a plan from which products
can be procured and systems developed, that will work together to implement the overall system.

85
 Requirements Analysis
Types of Requirements:
◦ Functional Requirements:
◦ Defines functions of a software system or its components. They may be calculations, technical details,
data manipulation and processing and other specific functionality that define “what a system is supposed
to accomplish?”
◦ They describe particular results of a system.
◦ Functional requirements are supported by Non-functional requirements.

86
 Requirements Analysis
Types of Requirements:
◦ Non-Functional Requirements:
◦ They are requirements that specify criteria that can be used to judge the
operation of a system, rather than specific behavior.
◦ Functional requirements define what the system is supposed to do, whereas
non-functional requirements define how a system is supposed to be.
◦ Non-functional requirements can be divided into two main categories:
◦ Execution qualities, such as security and usability, which are observable at
runtime.
◦ Evolution qualities, such as testability, maintainability and scalability.

87
 Cont…
Example: Problem statement

Idea: A Library Management System should be designed. Information on books,

CDs, DVDs, Journals, etc. can be stored and retrieved.

Possible Requirements:
◦ Searching by Title, Author, and/or ISDN should be possible
Functional Req.
◦ User Interface should be web-based (accessible via WWW Browser)
◦ At least 20 transactions per seconds should be possible
◦ All services should be available within 10 minutes
Implementation req.
◦ Users have no access to personal data of other users Problem Statement
Performance req.

Availability req.

Security req. 88
Requirements Specifications
Requirements Specification is the direct result of a requirement analysis
and can refer to:
◦ Software Requirements Specification
◦ Hardware Requirements Specification

89
Requirements Specifications
A Software Requirements Specification (SRS) –is a complete description
of the behavior of a system to be developed.
It includes a set of use cases that describe all the interactions the users
will have with the software. In addition to use cases, the SRS also
contains non-functional requirements (such as performance
requirements, quality standards, or design constraints)

90
Requirements Specifications
A Software Requirements Specification (SRS)
◦ The software requirement specification document enlists all necessary
requirements for project development. To derive the requirements we
need to have clear and thorough understanding of the products to be
developed.
◦ A general organization of an SRS is as follows:
◦ Introduction
◦ Purpose, Scope, Definitions, System Overview, References
◦ Overall Description
◦ Product Perspective, Product functions, User characteristics, constraints,
assumptions and dependencies.
◦ Specific Requirements
◦ External Interface requirements, functional requirements, performance
requirements, design constraints, logical database requirement, software
system attributes.

91
Requirements Validation and
Verification
Validation (& Verification), is the process of checking whether the
requirements, as identified, do not contradict the expectations about
the system of various stakeholders and do not contradict each other.
It is Requirements Quality Control

92
Validation Vs. Verification
Validation: “Am I building the right product?” checking a work product
against higher-level work products or authorities that frame this
particular product.
◦ Requirements are validated by stakeholders

Verification: “Am I building the product right?” checking a work product

against some standards and conditions imposed on this type of product
and the process of its development.
◦ Requirements are verified by the analysts mainly

93
Requirements management
Requirements management is the process of managing changing
requirements during the requirements engineering process and system
development
Requirements are inevitably incomplete and inconsistent
◦ New requirements emerge during the process as business needs change and
a better understanding of the system is developed
◦ Different viewpoints have different requirements and these are often
contradictory

94
Requirements change
The priority of requirements from different viewpoints changes during
the development process
System customers may specify requirements from a business
perspective that conflict with end-user requirements
The business and technical environment of the system changes during
its development

95
Requirements evolution
Initial Changed
understanding understanding
of problem of problem

Initial Changed
requirements requir ements

Time
96
Requirement Management
◦ Set of activities that help project team to identify, control, and track requirements and
changes as project proceeds
◦Requirements begin with identification. Each requirement is assigned a unique identifier.
Once requirement have been identified, traceability table are developed.
Traceability Table:
◦ Features traceability table - shows how requirements relate to customer observable
features
◦Source traceability table - identifies source of each requirement
◦Dependency traceability table - indicate relations among requirements
◦Subsystem traceability table - requirements categorized by subsystem
◦Interface traceability table - shows requirement relations to internal and external
interfaces
It will help to track, if change in one requirement will affect different aspects of the
system.

97
System models
Different models may be produced during the requirements analysis
activity
Requirements analysis may involve three structuring activities which
result in these different models
◦ Partitioning. Identifies the structural (part-of) relationships
between entities
◦ Abstraction. Identifies generalities among entities
◦ Projection. Identifies different ways of looking at a problem

98
Cont…

The analysis model is composed of three individual models:

1. Functional model , represented by use cases and scenarios
2. Analysis object model , represented by class and object diagrams
3. Dynamic model , represented by statechart and sequence diagrams.

Fig. The analysis model is composed of thefunctional model, the object model,
and the dynamic model.

99
 Cont.
Use case diagram
Derived from use-case study scenarios. It is an overview of use cases, actors, and
their communication relationships to demonstrate how the system reacts to
requests from external users. It is used to capture system requirements.
Sequence diagram
Describes time sequence of messages passed among objects in a timeline

100
Cont.…
Collaboration Diagram
Describes the sequence of message passing among objects in the
system. Equivalent to sequence diagram , except that it focuses on the
object—s role.
Each communication link is associated with a sequence order number
plus the passed messages.
Class Diagram
Class diagrams can be derived from use-case diagrams or from
text analysis of the given problem domain. A class diagram is
generated by system analysts and designers and will be iteratively
refined in the subsequent phases during the software development life
cycle.

101
Cont.
Activity Diagram
Outline of activity—s data and control flow among related objects. An
activity is an action for a system operation or a business process, such
as those outlined in the use-case diagram.
It also covers decision points and threads of complex operation
processes. It describes how activities are orchestrated to achieve the
required functionality.

102
Cont.…
State chart diagram
Describes the life cycle of objects using a finite state machine.
The diagram consists of states and the transitions between states.
Transitions are usually caused by external stimuli or events. They
can also represent internal moves by the object.
Component diagram
It is an Describes all components in a system, their
interrelationships, interactions, and the interface of the system. It
is an outline of the composition structure of components or
modules

103
Cont.
Deployment Diagram
Describes system hardware, software, and network connections for
distributed computing.
It covers server configuration and network connections between server
nodes in real-world setting.

104
Use case Diagram

105
Sequence Diagram

106
Collaboration diagram

107
Class Diagram

108
Activity Diagram

109
State Diagram

110
Component Diagram

111
Deployment Diagram

112
Thank You!
Q?

113
Software Engineering

Chapter Four
Software Project Management

114
Software Project Management

is an art and science of planning and leading software projects. It is a

sub-discipline of project management in which software projects are
planned, implemented, monitored and controlled.

115
Cont.s
As the industry has matured, analysis of software project management
failures has shown that the following are the most common causes:
Insufficient end-user involvement
Poor communication among customers, developers, users and project
managers
Unrealistic or unarticulated project goals
Inaccurate estimates of needed resources
Badly defined or incomplete system requirements and specifications

116
Cont.s
Poor reporting of the project's status
Poorly managed risks
Use of immature technology
Inability to handle the project's complexity
Sloppy development practices
Stakeholder politics (e.g. absence of executive support, or politics
between the customer and end-users)
Commercial pressures

117
 Software Project Management
Concerned with activities involved in ensuring
that software is delivered on time and on schedule and in accordance with the
requirements of the organisations developing and procuring the software.
Project management is needed because software development is always subject
to budget and schedule constraints that are set by the organisation developing
the software.

118
Cont..

119
Project Management Skills
Leadership
Communications
Problem Solving
Negotiating
Influencing the Organization
Mentoring
Process and technical expertise
A project is well-defined task, which is a collection of
several operations done in order to achieve a goal (for
example, software development and delivery).

120
 The Four P’s in Management
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

121
 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.

122
 Software Teams
How to lead?
How to organize?
How to collaborate?

How to motivate? How to create good ideas?

123
 Team Leader
The MOI Model
◦ 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.

124
 Software Teams
The following factors must be considered when
selecting a software project team structure ...
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

125
Activities in software project
management:
1) Project Planning
2) Project Scheduling
3) Risk Management
4) Managing people

126
1. Project Planning
The biggest single problem that afflicts software developing is that of
underestimating resources required for a project.
Developing a realistic project plan is essential to gain an understanding
of the resources required, and how these should be applied.

127
1.1 Types of plan:
Software development plan.
◦ The central plan, which describes how the system will be developed.

Quality assurance plan.

◦ Specifies the quality procedures & standards to be used.

Validation plan.
◦ Defines how a client will validate the system that has been developed.

128
Cont.
Configuration management plan.
◦ Defines how the system will be configured and installed.

Maintenance plan.
◦ Defines how the system will be maintained.

Staff development plan.

◦ Describes how the skills of the participants will be developed.

129
2.Project scheduling
Split project into tasks and estimate time and resources required to
complete each task.
Organize tasks concurrently to make optimal
use of workforce.
Minimize task dependencies to avoid delays
caused by one task waiting for another to complete.
Dependent on project managers intuition and experience.

130
2.1 The project scheduling
process

131
2.2 Scheduling problems
Estimating the difficulty of problems and hence the cost of developing
a solution is hard.
Productivity is not proportional to the number of people working on a
task.
Adding people to a late project makes it later because of
communication overheads.
The unexpected always happens. Always allow contingency in
planning.

132
3. Risk management
Risk management is concerned with identifying risks and drawing up
plans to minimise their effect on a project.
A risk is a probability that some adverse circumstance will occur
◦ Project risks affect schedule or resources;
◦ Product risks affect the quality or performance of the software being
developed;
◦ Business risks affect the organisation developing or procuring the software.

133
3.2 The risk management process
Risk identification
◦ Identify project, product and business risks;

Risk analysis
◦ Assess the likelihood and consequences of these risks;

Risk planning
◦ Draw up plans to avoid or minimise the effects of the risk;

Risk monitoring
◦ Monitor the risks throughout the project;

134
3.3.1 Risk identification
Technology risks.
People risks.
Organisational risks.
Requirements risks.
Estimation risks.

135
3.3.2 Risk analysis
Assess probability and seriousness of each risk.
Probability may be very low, low, moderate, high or very high.
Risk effects might be catastrophic, serious, tolerable or insignificant.

136
3.3.3 Risk planning
Consider each risk and develop a strategy to manage that risk.
Avoidance strategies
◦ The probability that the risk will arise is reduced;

Minimisation strategies
◦ The impact of the risk on the project or product will be reduced;

Contingency plans
◦ If the risk arises, contingency plans are plans to deal with that risk;

137
Thank You!
Q?

138
Fundamental Software
Engineering

Design and Coding

139
Why design is so important?
It is place where quality is fostered.
It provides us with representation of software that can be
assessed for quality.
Only way that can accurately translate a customer’s
requirements into a finished software product.
It serves as foundation for all software engineering
activities.
Without design difficult to assess:
◦ Risk
◦ Test
◦ Quality

140
Design Process and Design Quality
S/w design is an iterative process through which requirements are
translated into a “blueprint” for constructing the s/w.
As design iteration occur, subsequent refinement leads to design
representation at much lower levels of abstraction.

141
Goal of design process
The design must implement all of the explicit
requirements contained in the analysis model, and it
must accommodate all of the implicit requirements
desired by the customer.
The design must be a readable, understandable guide for
those who generate code and for those who test and
subsequently support the software.
The design should provide a complete picture of the
software, addressing the data, functional, and behavioral
domains from an implementation perspective.

142
Design Principles
S/W design is both a process and a model.
Design process - sequence of steps that enable the designer to describe
all aspects of the software to be built.
Design model - created for software provides a variety of different views
of the computer software

143
 Software architecture
A software architecture includes the system decomposition, the global control flow,
error-handling policies and inter subsystem communication protocols [Shaw & Garlan,
1996].
Some of architectural type
1. Repository architecture: An architecture where subsystems access and modify
data from a single data structure called the central repository.
◦ Control flow can be dictated either by the central repository
◦ The repository architecture is typical for database management systems, such as a
payroll system or a bank system.

Fig. Repository architecture (UML class diagram). Every subsystem depends only on a central
data structure called the repository. The repository in turn, has no knowledge of the other
144
 Cont…
2. Model/View/Controller:
◦ In the Model/View/Controller (MVC) architecture subsystems are classified into three
different types:
1. model subsystems are responsible for maintaining domain knowledge,
◦ It is developed such that they do not depend on any view or controller subsystem.
◦ It maintain the central data structure.
2. view subsystems are responsible for displaying it to the user, and
3. Controller subsystems are responsible for managing the sequence of interactions with the user. It gather
input from the user and send message to the model.

145
 Cont…
3. Client/server architecture
◦ In the client/server architecture a subsystem, the server, provides services
to instances of other subsystems called the clients, which are responsible
for interacting with the user.
◦ The request for a service is usually done via a remote procedure call
mechanism or a common object broker.
◦ The client/server architecture is a generalization of the repository
architecture.

◦ Fig. Client/server architecture (UML class diagram).

146
 Cont…
4. A peer-to-peer architecture
◦ It is a generalization of the client/server architecture in which subsystems
can act both as client or as servers, in the sense that each subsystem can
request and provide services.
◦ The control flow within each subsystem is independent from the others
except for synchronizations on requests.

◦ Fig. Peer-to-peer architecture (UML class diagram).

147
5.
Cont…
Pipe and filter architecture
◦ In this architecture subsystems process data received from a set of inputs
and send results to other subsystems via a set of outputs.
◦ The subsystems are called filters, and the associations between the
subsystems are called pipes.
◦ Each filter only knows the content and the format of the data received on
the input pipes, not the filters that produced them.
◦ Each filter is executed concurrently and synchronization is done via the pipes.
◦ Most operating systems and programming languages provide a data stream
mechanism; .
◦ A Filter can have many inputs and outputs. A Pipe connects one of the
outputs of a Filter to one of the inputs of another Filter.

148
 6. UML deployment diagrams
UML deployment diagrams: are used to depict the relationship among
run-time components and hardware nodes.
◦ Components are self-contained entities that provide services to other
components or actors. E. g. Web server, provides services to Web browsers.
◦ In UML deployment diagrams, nodes are represented by boxes containing
component icons.
◦ Dependencies between components are represented by dashed arrows.

149
 coding
In modern software engineering work, coding may be
the direct creation of programming language source code (e.g., Java),
the automatic generation of source code using an intermediate design-
like representation of the component to be built, or
the automatic generation of executable code using a “fourth-
generation programming language” (e.g., Visual C++).

150
Coding Principles
The principles that guide the coding task are closely aligned with
programming style, programming languages, and programming
methods.
However, there are a number of fundamental principles that can be
stated

151
Preparation principles:
Before you write one line of code, be sure
you
Understand of the problem you’re trying to solve.
Understand basic design principles and concepts.
Pick a programming language that meets the needs of the software to
be built and the environment in which it will operate.
Select a programming environment that provides tools that will make
your work easier.
Create a set of unit tests that will be applied once the component you
code is completed.

152
Programming principles: As you begin
writing code, be sure you
Constrain your algorithms by following structured
programming [Boh00] practice.
Consider the use of pair programming.
Select data structures that will meet the needs of
the design.
Understand the software architecture and create
interfaces that are consistent with it.
Keep conditional logic as simple as possible.

153
Cont..
Create nested loops in a way that makes them
easily testable.
Select meaningful variable names and follow other
local coding standards
Write code that is self-documenting.
Create a visual layout (e.g., indentation and blank lines) that aids
understanding.

154
 Validation Principles:
After you’ve completed your first coding pass , be sure you
Conduct a code walkthrough when appropriate.
Perform unit tests and correct errors you’ve uncovered.
Refactor the code

155
Goal: Self-Documenting Code
Self-documenting explains itself without need for
external documentation, like flowcharts, UML
diagrams, process-flow diagrams, etc.
◦ Doesn’t imply we don’t like/use those documents!
Coding conventions target:
◦ How you write statements in the language, organize
them into “modules,” format them in the source files
◦ Module: generic term meaning C function, Java/C++ class, etc.
◦ How you create names
◦ How you write comments

156
 Standard Coding Practices
Teams strive to use the same coding conventions in every regard:
◦ Name your classes similarly, your variables, your functions.
◦ Comment the same way, format your code the same way.
◦ By doing this, you ensure rapid understanding of whatever module needs changing, and as they
evolve, your modules will not degenerate into a HorseByCommittee appearance.

157
Benefits
Projects benefit from having strong Coding
Conventions/Standards because...
◦ People can stop reformatting code and renaming
variables and methods whenever working on code
written by other people.
◦ It's slightly easier to understand code that is consistently
formatted and uses a consistent naming standard.
◦ It's easier to integrate modules that use a common
consistent naming standard -- less need to look up and
cross-reference the different names that refer to the
same thing.

158
Which Coding Conventions?
Doesn't really matter that much, as long as everyone follows them (and
stops arguing about them!)
One sometimes encounters Bad Coding Standards, arbitrarily imposed
restrictions destructive to the development process, but that's the
exception rather than the rule.

159
Coding Conventions Apply To…
Comments, 3 types:
◦ File headers
◦ Function headers
◦ Explanations of variables and statements

Names (chosen by programmer)

Statements
◦ Organization: files, “modules,” nesting
◦ Format: spacing and alignment

160
Organization of Modules
Apply comp. sci. principle of information hiding
◦ Hide details of of implementation that users don’t need to know

Divide each module into a public part and a private part.

◦ public part goes into an include (.h) file
◦ private part goes into a source (.c) file

161
File Headers
Creation date
◦ Provides a creation timestamp for copyright purposes,
but it does more than that. It provides a quick clue to the
context that existed at the time the module was created.
Not as accurate as source control, but quick and
maintenance free.
Author's Name or Initials
Copyright banner
◦ This identifies the uses to which this code can be put.

162
Meaningful Comments
Comments provide meta information about the
program, reasons for choosing this algorithm or
implementation, known issues, hints for future
readers (including yourself).
“Meaningful” in this context has two parts:
◦ The comment can be understood by readers.
◦ The comment says something that is likely not to be
understood by the same readers unless it was present.
◦ Don’t “parrot the code”:
x = 2 + y; // add 2 to y
Avoid comments needing heavy maintenance
163
Variable Names
Use simple, descriptive variable names.
Good names can be created by using one word or
putting multiple words together joined by
underscores or caps
◦ prefer usual English word order

#define MAX_FIELD 127

int numStudents, studentID;
char *homeAddr;

164
Variable Names
Be careful of lower-case L (l) or upper-case O in
variable or constant names
int l, O; l = O + l/0.1; //bad

int length; FILE *outfile; //OK

#define KG_PER_TON 907.18474;
Do not use names of existing library functions or
constants → multiply-defined externals or worse
◦ do not use the names argc, argv for any other purpose
except command line argument manipulation
165
Variable Names
Avoid variable names that differ by only one or two characters.
Short names such as x, n, i are acceptable when their meaning is clear
and a longer name would not add any more information.
Trade off: long, unabbreviated names → statements become too long,
hard to follow
◦ studentIdentificationNumber, arraySubscript

166
Variable Names
Follow every variable declaration with a comment that defines it.
Group similar variables together.
◦ use similar names for variables that perform similar functions

167
Statement Style
Put each statement on a line by itself.
Avoid very long statements. Use two shorter statements instead.
Keep all lines to 80 characters or less.
Group statements in logical “chunks” separated with white space (blank
lines)
◦ Helps eye follow logic without getting overwhelmed

168
Use Vertical Alignment (Type
A)
Makes lines at same level of nesting stand out.
if ( flag == 0 ) {
var1 = 0;
if ( var2 > level1 ) {
var2 = level1;
level1 = 0;
}
printf ( "%d/n", var2 );
} 169
Ugly Code
How about this? Align Consistently!
if (WndHt < WIN_MIN) if ( WndHt < WIN_MIN ) {
{ ResetWin(WPtr);
ResetWin(WPtr ); while ( WndHt > WinHt ) {
while( WndHt> WinHt) WinHt = getWindow(pWin);
{ if ( WinHt == (winhite *
WND_CORR) ) {
WinHt =getWindow( pWin );
stepup (wdwhght);
if ( WinHt== ( winhite *
WND_CORR )) { STEPUP(wndwh);
stepup (wdwhght ); }
STEPUP( wndwh); }
170
} }
Vertical Alignment (Type B)
Makes tabular information easier to read.

int LineFactors[3][5] = { { 19, 2, 22, 32, 5 },

{ 99, 33, 55, 45, 4 },
{ 32, 6, 14, 21, 15 } };

171
Code-Tuning Strategies
Code tuning is the practice of modifying correct code to make it run
more efficiently
Less of a factor in many of today’s systems, particularly business
software
Problem: Efficient code isn’t necessarily better code

172
173

Fundamental Software Engineering

Chapter Seven
Software Testing
174

Observations about Testing

“Testing is the process of executing a program with the
intention of finding errors.” – Myers
“Testing can show the presence of bugs but never their
absence.” - Dijkstra
175

Characteristics of Testable Software

Operable
The better it works (i.e., better quality), the easier it is to test
Observable
Incorrect output is easily identified; internal errors are
automatically detected
Controllable
The states and variables of the software can be controlled
directly by the tester
Decomposable
The software is built from independent modules that can be
tested independently
176

Characteristics of Testable Software (continued)

Simple
The program should exhibit functional, structural, and code
simplicity
Stable
Changes to the software during testing are infrequent and do
not invalidate existing tests
Understandable
The architectural design is well understood; documentation is
available and organized
177

Good Testing Practices

A good test case is one that has a high probability of
detecting an undiscovered defect, not one that shows
that the program works correctly
It is impossible to test your own program
A necessary part of every test case is a description of
the expected result
178

Good Testing Practices (cont’d)

Avoid non-reproducible or on-the-fly testing
Write test cases for valid as well as invalid input
conditions.
Thoroughly inspect the results of each test
As the number of detected defects in a piece of software
increases, the probability of the existence of more
undetected defects also increases
179

Good Testing Practices (cont’d)

Assign your best people to testing
Ensure that testability is a key objective in your
software design
Never alter the program to make testing easier
Testing, like almost every other activity, must start with
objectives
180

Test Characteristics
A good test has a high probability of finding an error
The tester must understand the software and how it might fail
A good test is not redundant
Testing time is limited; one test should not serve the same
purpose as another test
A good test should be “best of breed”
Tests that have the highest likelihood of uncovering a whole
class of errors should be used
A good test should be neither too simple nor too complex
Each test should be executed separately; combining a series of
tests could cause side effects and mask certain errors
181

Two Unit Testing Techniques

Black-box testing
Knowing the specified function that a product has been designed to
perform, test to see if that function is fully operational and error free
Includes tests that are conducted at the software interface
Not concerned with internal logical structure of the software
White-box testing
Knowing the internal workings of a product, test that all internal
operations are performed according to specifications and all internal
components have been exercised
Involves tests that concentrate on close examination of procedural
detail
Logical paths through the software are tested
Test cases exercise specific sets of conditions and loops
182

Classification of testing techniques

Classification based on the criterion to measure the
adequacy of a set of test cases:
coverage-based testing
fault-based testing
error-based testing
Classification based on the source of information to
derive test cases:
black-box testing (functional, specification-based)
white-box testing (structural, program-based)
183

Cont.
Coverage-based: e.g. how many statements or
requirements have been tested so far
Fault-based: e.g., how many seeded faults are found
Error-based: focus on error-prone points, e.g. off-by-
one points

Black-box: you do not look inside, but only base

yourself on the specification/functional description
White-box: you do look inside, to the structure, the
actual program/specification.
184

Some preliminary questions

What exactly is an error?

How does the testing process look like?

When is test technique A superior to test technique B?

What do we want to achieve during testing?

When to stop testing?

185

Error, fault, failure

an error is a human activity resulting in software
containing a fault

a fault is the manifestation of an error

a fault may result in a failure

186

When exactly is a failure ?

Failure is a relative notion: e.g. a failure w.r.t. the
specification document

Verification: evaluate a product to see whether it

satisfies the conditions specified at the start:
Have we built the system right?

Validation: evaluate a product to see whether it does

what we think it should do:
Have we built the right system?
187

Testing process

subset of expected
input oracle output
input test
test
P compare results
strategy
P
subset of real
input output
188

Test adequacy criteria

Specifies requirements for testing
Can be used as stopping rule: stop testing if 100% of
the statements have been tested
Can be used as measurement: a test set that covers
80% of the test cases is better than one which covers
70%
Can be used as test case generator: look for a test
which exercises some statements not covered by the
tests so far
A given test adequacy criterion and the associated
test technique are opposite sides of the same coin
189

What is our goal during testing?

Objective 1: find as many faults as possible

Objective 2: make you feel confident that the software

works OK
W-Model for Testing

190
191

Testing and the life cycle

requirements engineering
criteria: completeness, consistency, feasibility, and testability.
typical errors: missing, wrong, and extra information
determine testing strategy
generate functional test cases
test specification, through reviews and the like
design
functional and structural tests can be devised on the basis of the
decomposition
the design itself can be tested (against the requirements)
formal verification techniques
the architecture can be evaluated
192

Testing and the life cycle (cont’d)

implementation
check consistency implementation and previous
documents
code-inspection and code-walkthrough
all kinds of functional and structural test techniques
extensive tool support
formal verification techniques
maintenance
regression testing: either retest all, or a more selective
retest
193

Levels of Testing
Unit Testing
Integration Testing
Validation Testing
Regression Testing
Alpha Testing
Beta Testing
Acceptance Testing
194

Unit Testing
Algorithms and logic
Data structures (global and local)
Interfaces
Independent paths
Boundary conditions
Error handling
195

Why Integration Testing Is Necessary

One module can have an adverse effect on another sub-
functions , when combined, may not produce the
desired major function
Individually acceptable imprecision in calculations may
be magnified to unacceptable levels
196

Why Integration Testing Is Necessary (cont’d)

Interfacing errors not detected in unit testing may
appear
Timing problems (in real-time systems) are not
detectable by unit testing
Resource contention problems are not detectable by
unit testing
197

Top-Down Integration
1.The main control module is used as a driver, and stubs
are substituted for all modules directly subordinate to
the main module.
2.Depending on the integration approach selected
(depth or breadth first), subordinate stubs are replaced
by modules one at a time.
198

Top-Down Integration (cont’d)

199

Problems with Top-Down Integration

Many times, calculations are performed in the

modules at the bottom of the hierarchy Stubs
typically do not pass data up to the higher modules
Delaying testing until lower-level modules are
ready usually results in integrating many modules at
the same time rather than one at a time
Developing stubs that can pass data up is almost as
much work as developing the actual module
200

Bottom-Up Integration
Integration begins with the lowest-level modules, which are
combined into clusters, or builds, that perform a specific
software subfunction
Drivers (control programs developed as stubs) are written to
coordinate test case input and output
The cluster is tested
Drivers are removed and clusters are combined moving
upward in the program structure
201

Problems with Bottom-Up Integration

The whole program does not exist until the last

module is integrated
Timing and resource contention problems are
not found until late in the process
202

Validation Testing
Determine if the software meets all of the requirements
defined in the SRS
Having written requirements is essential
Regression testing is performed to determine if the software
still meets all of its requirements in light of changes and
modifications to the software
Regression testing involves selectively repeating existing
validation tests, not developing new tests
203

Alpha and Beta Testing

It’s best to provide customers with an outline of the
things that you would like them to focus on and specific
test scenarios for them to execute.
Provide with customers who are actively involved with a
commitment to fix defects that they discover.
204

Acceptance Testing
Similar to validation testing except that
customers are present or directly involved.
Usually the tests are developed by the
customer
205

System Testing
Recovery testing
checks system’s ability to recover from failures
Security testing
verifies that system protection mechanism prevents
improper penetration or data alteration
Stress testing
program is checked to see how well it deals with
abnormal resource demands
Performance testing
tests the run-time performance of software
206

Test Planning
The Test Plan – defines the scope of the work to be
performed
The Test Procedure – a container document that holds
all of the individual tests (test scripts) that are to be
executed
The Test Report – documents what occurred when the
test scripts were run
207

Test Plan
Questions to be answered:
How many tests are needed?
How long will it take to develop those tests?
How long will it take to execute those tests?
Topics to be addressed:
Test estimation
Test development and informal validation
Validation readiness review and formal validation
Test completion criteria
208

Test Estimation
Number of test cases required is based on:
Testing all functions and features in the SRS
Including an appropriate number of ALAC (Act Like
A Customer) tests including:
Do it wrong
Use wrong or illegal combination of inputs
Don’t do enough
Do nothing
Do too much
Achieving some test coverage goal
Achieving a software reliability goal
209

Considerations in Test Estimation

Test Complexity – It is better to have many small tests
that a few large ones.
Different Platforms – Does testing need to be
modified for different platforms, operating systems, etc.
Automated or Manual Tests – Will automated tests be
developed? Automated tests take more time to create
but do not require human intervention to run.
210

Test Team Members

Professional testers.
Analysts.
System designers.
Configuration management specialists.
Users.
211

Debugging
Debugging (removal of a defect) occurs as a
consequence of successful testing.
Some people better at debugging than others.
Is the cause of the bug reproduced in another part
of the program?
What “next bug” might be introduced by the fix
that is being proposed?
What could have been done to prevent this bug in
the first place?
 Test Report
Completed copy of each test script with evidence that it
was executed (i.e., dated with the signature of the person
who ran the test)
Software Problem Reports (SPRs) are submitted for
each test that fails.
Copy of each SPR(Software Problem Reports ) showing
resolution
List of open or unresolved SPRs
Identification of SPRs found in each baseline along with
total number of SPRs in each baseline
Regression tests executed for each software baseline
213

Thank You!
Q?
Fundamental Software Engineering

Chapter Eight
Software Maintenance
 Software maintenance
Software maintenance is the process of
changing a system after it has been delivered.
 Modifying a program after it has been put
into use.
Maintenance does not normally involve major
changes to the system’s architecture.
Changes are implemented by modifying
Need for software
maintenance
Maintenance to repair software faults –
Changing a system to correct deficiencies in
the way meets its requirements.
Maintenance to adapt software to a different
operating environment – Changing a system so
that it operates in a different environment
(computer, OS, etc.) from its initial
 Sources of change
New business or market conditions which cause
changes in product requirements or business rules.
New customer needs that demand modification of data,
functionality or services delivered by the system.
Reorganization and/or business downsizing that
changes priorities team structures
Budgetary or scheduling constraints that cause a
redefinition of the system
Most changes are justified
 Maintenance and the
SDLC
In the Waterfall software development
lifecycle, we had a nice little box at the end of
the process and one which was generally
ignored in descriptions of the process
In more advanced lifecycles such as the Spiral
Model, maintenance was accorded a much
more prominent place
 The Cost of Maintenance
One study found
̶Requirements Definition 3%

̶Preliminary Design 3%

̶Detailed Design 5%

̶Implementation 7%

̶Testing 15%

̶Maintenance 67%
Another study found at least 50% of effort spent on
maintenance
Another study found between 65% and 75% on
maintenance
In embedded real-time systems, maintenance costs may
 Why is Maintenance so
Costly
Most software is between 10 and 15 years old
Much of that software is showing its age as it was created
when program size and storage space were far more
important factors
This has lead to inflexible designs, coding and
documentation
Maintenance is usually done by inexperienced staff
unfamiliar with the application
Developers don’t like maintenance
 Factors Affecting Maintenance
Costs(1)
Module Independence
the ability to modify one part of the system

potential advantage of OO

Programming Language
the higher the level of the language, the cheaper the

maintenance
Programming Style
the way in which a program is written

Program Validation and Testing

the more time and effort spent on design validation and
 Factors Affecting Maintenance
Costs (2)
Quality of Program Documentation
the better the documentation, the easier it is to maintain

Configuration Management Techniques

keeping track of all the system documents and ensuring

they are consistent is a major cost of maintenance, therefore

good CM tools and practices reduce this cost
Application Domain
the less well-understood the domain, the greater the

likelihood of the need for adaptive maintenance as users

and developers begin to understand the domain
 Factors Affecting Maintenance
Costs (3)
Age of the System
the older the system, the more likely that its structure has

degraded and the harder the maintenance will be

Attracting staff who know the old

languages/databases/operating systems becomes harder

and more expensive
Dependence of the System on the External Environment
the higher the dependence, the far more likely that

adaptive maintenance will be needed

Hardware Stability
Differences between Maintenance and
New Development
Constraints of an Existing System
Changes must conform or be compatible with an

existing architecture, design and code constraints

Shorter Time Frames
Development spans 6 months upwards

Maintenance spans hours or days up to 6 months

Available Test Data

Development creates all test data from scratch
 Types of Maintenance
̶So how and why do we spend so much time and effort on
maintenance?
̶Maintenance is much more than fixing bugs
̶Commonly divided into four main categories

̶Corrective Maintenance

̶Adaptive Maintenance

̶Perfective Maintenance

̶Preventive maintenance
Distribution of Maintenance
effort
Corrective Maintenance(1)
Focused on fixing failures
Is a reactive process
failures and their associated faults generally need

to be corrected either immediately or in the near

future
Failures vary in their cost to correct
Coding - usually relatively cheap

Design - more expensive as they may require

 Corrective Maintenance (2)
Fixing a fault has a 20 to 50% chance of introducing another
fault
Reasons for new faults include
the ripple effect, where a change in one area may cause changes in

seemingly unrelated areas

Person who makes the repair is generally not the person who wrote

the code or designed the system

Two types of corrective maintenance

Emergency Repairs - short time frame, often a single program, failure

needs to be repaired as soon as possible

Scheduled Repairs - failure doesn’t need immediate attention, re-
 Adaptive Maintenance
The evolution of the system to meet the needs of the user and
the business
Caused by
internal needs

external competition

external requirements e.g. changes in law

Essentially we are introducing new requirements to the

system
 Therefore we should treat like a new development in our
approach and methods
Perfective Maintenance
Old proverb says “If it isn’t broken, don’t fix it”
Perfective maintenance ignores this ancient piece of
wisdom
Is about improving the quality of a program that already
works
Aim to achieve
reduced costs in using the system

increase maintainability of the system

more closely meet the users’ needs

Perfective Maintenance (2)
Includes all efforts to polish or refine the
quality of the software or the documentation
Important that the potential benefits of the
perfective maintenance outweigh
the costs of the maintenance

and the opportunity costs of improvements

elsewhere or using the resources on new

developments
Preventative Maintenance
Can be seen as radical perfective maintenance or as an
alternative to maintenance
More commonly known as Software Re- engineering
Taking a legacy system and converting its structure or
converting to a new language
Old system starts as a specification for the new system
Common method now is known as wrappers where an entire
system is placed in an OO wrapper and treated as one large
object
Alternatives to
Maintenance
Sometimes, maintenance is not enough on its

own

Partial restructuring integrated with

adaptive maintenance

use for orderly improvement with each system

release
Alternatives to Maintenance (2)
Complete redesign and rewrite
Use when more than 20% of program must be changed

Use when program is being upgraded to a new technology

Don’t use when the design and function of a system are not

known
 Retirement of the system and complete redevelopment
Use when moving to a new technology

use when the costs of maintaining the software and the

hardware exceed the cost of re-development

The Maintenance Process
(2)
Change Management
Uniquely identify, describe and track the status of
all change requests
 Impact Analysis
identifies all systems and system products
affected by a change request
 makes an estimate of the resources needed to
effect the change
 analyses the benefits of the change
 System Release Planning
 to establish the schedule and contents of a system
release
 don’t want each change request released as they
The Maintenance Process
(3)
Change Implementation
Design Changes

Coding

Testing - must perform regression testing

System Release includes

documentation

software

training
Maintenance Problems
Someone else's program.
Developer not available.
Proper documentation doesn't exist.
Not designed for change.
High staff turnover
Maintenance activity not highly regarded.
Budget and effort reallocation

Complete replacement of the system

Maintenance of existing system

1.Quick-fix Model
This is basically an adhoc approach to maintaining software.

It is a fire fighting approach, waiting for the problem to occur and then trying

to fix it as quickly as possible.

2. Iterative Enhancement Model
Analysis

 Characterization of proposed modifications

Redesign and implementation

3. Reuse Oriented Model

The reuse model has four main steps

1.Identification of the parts of the old system that are candidates for reuse.
2. Understanding these system parts.
3. Modification of the old system parts appropriate to the new requirements.
4. Integration of the modified parts into the new system.
 Maintenance Models(4)
4. Boehm’s Model
Boehm proposed a model for the maintenance
process based upon
the economic models and principles.
Boehm represent the maintenance process as a
closed loop cycle
Maintenance Models(5)
5. Taute Maintenance Model
Maintenance Models(6)
6. Belady and Lehman Model

Where
M : Total effort expended
P : Productive effort that involves analysis, design, coding, testing
and evaluation.
K : An empirically determined constant.
c : Complexity measure due to lack of good design and documentation.
d : Degree to which maintenance team i
Lehman’s Laws of
Software Change
Five laws based upon the growth and evolution of a
number of large software systems
1. Law of Continuing Change
A program used in a real-world environment necessarily

must change or become less useful in that environment

2. Law of Increasing Complexity
As an evolving program changes, its structure tends to

become more complex. Extra resources must be devoted to

preserving and simplifying the structure
Lehman’s Laws of
Software Change (2)
3. Law of Large Program Evolution
Program evolution is a self-regulating process.
System attributes such as size, time between
releases and the number of reported errors are
approximately invariant for each system release
4. Law of Organizational Stability
Over a program’s lifetime, its rate of development
is approximately constant and independent of the
resources devoted to system development
5. Law of Conservation of Familiarity
Over the lifetime of a system, the incremental
change in each release is approximately constant
Motivating Maintenance
Staff
Often considered a dead-end in organizations as well as
being boring!
 Critical to the success of the organization
Possible strategies
̅Couple software objectives to organizational goals

̅Couple software maintenance rewards to organizational

performance
̅ Integrate software maintenance personnel into operational

teams
̅Create a discretionary, perfective/preventative maintenance
Conclusion
̶Maintenance is a major cost for software and must be
planned for during the entire life cycle.
̶Design workflow —use information-hiding
techniques
̶Implementation workflow — good coding style
̶Documentation must be complete, correct, and
current.
̶During maintenance, maintainability must not be
Thank You!
Q?