SOFTWARE ENGINEERING

Simple Concepts - Maximum Benefits

 ❖ Software Process Models

❖ Estimation and Scheduling of Software Projects

❖ Software Requirements

❖ Software Design
SYLLABUS
❖ Software Quality

7 SUB DIVISIONS ❖ Software Testing

❖ Software Configuration Management

 Software Engineering

➢ Definition

➢ Size factors

➢ Quality and productivity factors

➢ Managerial issue
UNIT - I Planning a Software Project

➢ Defining the problem

➢ Developing a solution strategy

➢ Planning the development process

➢ Planning an organization structure

➢ Other planning activities.

 DEFINITIONS

PROGRAM AND PROGRAMMING

★ Program is a set of instruction which is written in any language which computer can understand.

★ Program is set of sequential logical instructions

★ Task to write the program is known as Programming

❖ PROCESS
➢ A process is a sequence of steps performed for a given purpose.
➢ While developing (industrial strength) software, the purpose is to develop software to
satisfy the needs of some users or clients.

❖ PROJECT
➢ A software project is one instance of this problem, and the development process is
what is used to achieve this purpose.
 SOFTWARE
❖ Software is a set of items or objects that form a configuration that includes
1. Programs
2. Documents
3. Data
❖ Software consists of
(1) Instructions (computer programs) that when executed provided desired function and
performance

(2) Data structures that enable the programs to adequately manipulate information

(3) Documents that describe the operation and use of the programs.
 SOFTWARE DEFINITIONS
★ Software is the dynamic behavior of programs on real computers and auxiliary equipment.

★ A software product is a model of the real world, and the real world is constantly changing.

★ Software is a digital form of knowledge. (“Software Engineering,” 6ed. Sommerville,

Addison-Wesley, 2000)

★ Computer programs and associated documentation such as requirements, design models and
user manuals.

★ Software products may be developed for a particular customer or may be developed for a
general market.
 SOFTWARE PRODUCTS

★ Generic - developed to be sold to a range of different customers e.g. PC software such as

Excel or Word.
★ Bespoke (custom) - developed for a single customer according to their specification.
★ New software can be created by developing new programs, configuring generic software
systems or reusing existing software
 CHRONOLOGICAL EVOLUTION OF SOFTWARE

1. 1950-1965 –Early Years 3. 1974-1986-Third Era

General Purpose Hardware Distributed Systems
Batch Orientation Embedded Systems
Limited Distribution Low cost HW
Custom Software Consumer Impact
2. 1968-1973- Second Era 4. 1987-2000-Fourth Era
Multi User Powerful Desktop
Real Time Object Oriented Technology
Data Base Expert Systems
Product Software Artificial Neural Network
Concept of sw Maintenance Parallel Computing
Network Computers
 SOFTWARE ENGINEERING

It is an establishment and use of sound engineering principles in order to obtain economically

software that is reliable and works efficiently on real machines.
-Fritz

It is the application of a Systematic, Disciplined, Quantifiable approach to the Development

operation and Maintenance of software.

-IEEE
 SOFTWARE SIZE FACTORS

Estimation of the size of software is an essential part of Software Project Management.

It helps the project manager to further predict the effort and time which will be needed to
build the project. Various measures are used in project size estimation
 SOFTWARE QUALITY AND PRODUCTIVITY FACTORS

Software quality and programmer productivity can be improved by improving the processes used to
develop and maintain software products.
 MANAGERIAL ISSUES

❖ Managerial activities are as important as the technical activities for the success of a software
product.

❖ Managers control the resources and the environment in which technical activities occur.

❖ Managers also have the responsibility for ensuring that software products are delivered on time and
within cost estimates and that products exhibit the functional and quality attributes desired by the
customer.

❖ Other management responsibilities include developing business plans, recruiting the customers,
developing marketing strategies and recruiting and training employees
 MANAGERIAL ISSUES(Cont.) – Management Problems

❖ Planning for software engineering projects.

❖ Procedures and techniques for the selection of project managers are poor.

❖ The accountability of many software engineering projects is poor leaving some question as to who is
responsible for various project functions.

❖ The ability to accurately estimate the resources required to accomplish a software development project is poor.

❖ Success criterion for software development projects are frequently inappropriate. This results in software
products that are unreliable difficult to use and difficult to maintain.

❖ Decision rules to aid in selecting the proper organizational structure are not available.

❖ Decision rules to aid in selecting the correct management techniques for . software engineering projects are not
available.

❖ Procedures methods and techniques for designing a project control system that will enable project managers to
successful control their project are not readily available.

❖ Procedures, techniques, strategies and aids that will provide visibility of progress to the project manager are not
available.

❖ Standards and techniques for measuring the quality of performance and the quality of production expected from
programmers and data processing analysts are not available.
 MANAGERIAL ISSUES(Cont.)_ Solving the Problems

❖ Educate and train top management project managers and software developers.

❖ Enforce the use of standards, procedures and documentation.

❖ Analyze data from prior software projects to determine effective methods.

❖ Define objectives in terms of quality desired.

❖ Define quality in terms of deliverable.

❖ Establish success priority criteria.

❖ Allow for contingencies.

❖ Develop truthful, accurate cost and schedule estimates that are accepted by management and
customer and manage to them.

❖ Select project managers based on ability to manage software projects rather than on technical
ability or availability.

❖ Make specific work assignments to software developers and apply job performance standards
 PROJECT PLANNING PROCESS

★ Objectives and scope of the project

★ Techniques used to perform project planning
★ Effort (in time) of individuals involved in project
★ Project schedule and milestones
★ Resources required for the project
★ Risks associated with the project.
 SOFTWARE ENGINEERING PROCESS
★ Concept of the Software Engineering has evolved in 1986 by BOHEM to reduce the effect
of his software crisis because software engineering defined as scientific and systematic
approach to develop , operate and maintain software project to meet a given specific object
it beautifully envisages the concept of life cycle of any software project through following
five phase:-
● Requirement analysis
● Design
● Coding
● Testing
● Maintenance
 SOFTWARE DEVELOPMENT LIFE CYCLE MODELS
❖ Software-development life-cycle is used to facilitate the development of a large software
product in a systematic, well-defined, and cost-effective way.
❖ An information system goes through a series of phases from conception to implementation.
This process is called the Software-Development Life-Cycle.
❖ Various reasons for using a life-cycle model include:
– Helps to understand the entire process
– Enforces a structured approach to development
– Enables planning of resources in advance
– Enables subsequent controls of them
– Aids management to track progress of the system
SOFTWARE DEVELOPMENT LIFE CYCLE MODELS
 SOFTAWRE ENGINEERING LAYERS

● Four layers of Software Engineering

 SOFTWARE ENGINEERING PROCESS FRAMEWORK

● It establishes foundation for a complete software process by identifying small number of

framework activities.
● The framework activities are applicable to all projects
● It includes set of umbrella activities that are applicable throughout software process.
SOFTWARE PROCESS
FRAMEWORK ACTIVITIES
MODELING - ANALYSIS
MODELING - DESIGN
LIST OF UMBERLA ACTIVITIES
PROCESS FLOW - 1 & 2
PROCESS FLOW - 3 & 4
 PROCESS MODELS

1. Prescriptive Models 4. Specialized Process Models

4.1 Component Based Model
1. Water Fall Model
4.2 Formal Method Model
2. V Model 4.3 ASOD(Aspect Oriented Software
2. Incremental Process Models Development Model)
1. Iterative Enhancement 5. Agile Model
2. RAD 5.1 Extream Programming
3. Evolutionary Process Models 5.2 Adaptive Software Development
1. Prototyping Process Model 5.3 SCRUM
2. Spiral Process Model 5.4 CRYSTAL
3. Concurrent Process Model 5.5 FDD(Feature Driven Development)
5.6 DSDM(Dynamic System Development
Method)
 Software Development Organizational Structure

❖ Software package development organization is structured:

1. Project format
2. Functional format.
1.Project format:
A group of engineers is appointed to the project at the beginning of the project and that
they stay with the project until the completion of the project.
 Software Development Organizational Structure

2. Functional format.
❖ The event workers are divided supported the useful cluster to that they belong
❖ Totally different groups of programmers perform different phases of a project.
 ❑ Software Cost Estimation:

❖ Software

❖ Cost factors

❖ Software cost estimation techniques

❖ specification techniques
UNIT - II ❖ level estimation

❖ Estimating software maintenance costs

❑ The software requirements specification

❖ formal specification techniques

❖ languages and processors for requirements

specification
 Software Project

A Software Project is the complete procedure of software development from requirement gathering to

testing and maintenance, carried out according to the execution methodologies, in a specified period

of time to achieve intended software product.

 SOFTWARE MANAGEMENT ACTIVITIES

❖ Software project management comprises of a number of activities, which contains planning of

project, deciding scope of software product, estimation of cost in various terms, scheduling of

tasks and events, and resource management.

❖ Project management activities may include:

1. Project Planning

2. Scope Management

3. Project Estimation
 PROJECT ESTIMATION

❖ Software size Estimation

❖ Effort Estimation

❖ Time Estimation

❖ Cost Estimation
 SOFTWARE SIZE ESTIMATION

★ Software size may be estimated either in terms of KLOC (Kilo Line of Code) or by
calculating number of function points in the software.
★ Lines of code(LOC) depend upon coding practices and Function points vary according to the
user or software requirement
 TIME ESTIMATION

➢ Once size and efforts are estimated, the time required to produce the software can be estimated.
➢ Efforts required is segregated into sub categories as per the requirement specifications and
interdependency of various components of software.
➢ Software tasks are divided divided into smaller tasks, activities or events by Work Breakthrough
Structure (WBS).
➢ The tasks tasks are scheduled on day-to-day basis or in calendar months.
➢ The sum of time required to complete all tasks in hours or days is the total time invested to
complete complete the project.
 COST ESTIMATION

1. Size of software

2. Software quality

3. Hardware

4. Additional software or tools, licenses etc.

5. Skilled skills with task-specific skills

6. Travel involved

7. Communication

8. Training and support

 PROJECT COST ESTIMATION

Project estimation such as size, effort, time and cost

i). Decomposition Technique
There are two main models –
1. Line of Code Estimation is done on behalf of number of line of codes in the software
product.

2. Function Points Estimation is done on behalf of number of function points in the

software product.
 PROJECT COST ESTIMATION

EMPIRICAL ESTIMATION TECHNIQUE

❖ This on technique uses empirically derived formulae to make estimation.
❖ These formulae are based on LOC or FPs.

PUTNAM MODEL
✓ This model is made by Lawrence H. Putnam, which is based on Norden’s frequency distribution
distribution (Rayleigh curve).
✓ Putnam model maps time and efforts required with software size.
MANAGING SOFTWARE PROJECT
MANAGING SOFTWARE PROJECT
MANAGING SOFTWARE PROJECT
MANAGING SOFTWARE PROJECT
SOFTWARE MEASUREMENT
SOFTWARE MEASUREMENT
FUNCTION POINT METRICS
FUNCTION POINT METRICS
FUNCTION POINT METRICS
 Estimating Software Maintenance Cost

❖ Software maintenance typically requires 40 to 60 percent, and in some cases as much as 90

percent, of the total lifecycle effort devoted to a software product.

❖ The major concerns about maintenance during the planning phase of a software projects are

estimating the number of maintenance programmers that will be needed and specifying the

facilities required for maintenance.

❖ A widely used rule of thumb for the distribution of maintenance activities is

60% -Enhancement

20% -Adaptation

20% -Corrections
 Estimating Software Maintenance Cost

In survey 487 business data processing installations, Lientz and Swanson determined that typical level

of effort devoted to software maintenance was around

FOR EXAMPLE:

If a maintenance programmer can maintain 32KDSI, then two a maintenance programmers are

required to main 64 KDSI:

 Estimating Software Maintenance Cost

❑ Boehm suggests that maintenance effort can be activity ratio , which is the number of source

instruction to be added and modified in any given time period divided by the total number of

instructions:

❑ Number of programmer –months required for maintenance in the corresponding time peri

❑ In enhancement is provided by an effort adjustment factor EAF, which recognizes that the effort

multipliers for maintenance may be different from the effort multipliers used for development:
Maintenance Effort Distribution
 Maintenance Effort Distribution

Heavy emphasis on reliability and the use of modern programming practices during development may

reduce the amount of effort required for maintenance, while low emphasis on reliability and modern

practices during development may increase the difficulty of maintenance.

Software ➔ Requirements engineering establishes a solid base for design
and construction. Without it, the resulting software has a high
Requirement
probability of not meeting customer’s needs.
Specification
➔ SRS

➔ Purpose of SRS

➔ Requirement analysis

◆ SRS -> SRD

➔ What SRD Provides?

➔ SRD Characteristics

➔ Techniques for gathering

requirements

3
Software
Requirement ➔ Complete description of behaviour of system

Specification ➔ Includes set of use cases

➔ Includes both functional and non- functional
➔ SRS requirements
➔ Purpose of SRS ➔ Prepared after a detailed communication between
➔ Requirement analysis customer and Project Team

◆ SRS -> SRD

➔ What SRD Provides?

➔ SRD Characteristics

➔ Techniques for gathering

requirements

4
Software
Requirement ➔ Basis of agreement between customer and software

Specification team
➔ Basis for software design
➔ SRS ➔ Reduce development effort
➔ Purpose of SRS ➔ Basis for estimating costs and schedules
➔ Requirement analysis ➔ Baseline for verification and validation

◆ SRS -> SRD ➔ Basis for enhancement

➔ What SRD Provides?

➔ SRD Characteristics

➔ Techniques for gathering

requirements

5
Software
Requirement ➔ After successful negotiation with customer, the SRS

Specification will be converted to SRD

➔ SRS

➔ Purpose of SRS

➔ Requirement analysis

◆ SRS -> SRD

➔ What SRD Provides?

➔ SRD Characteristics

➔ Techniques for gathering

requirements

6
Software
Requirement ➔ Agreement between customer and software team

Specification ➔ Costing and scheduling

➔ Verification and Validation
➔ SRS ➔ All forms of maintenance
➔ Purpose of SRS

➔ Requirement analysis

◆ SRS -> SRD

➔ What SRD Provides?

➔ SRD Characteristics

➔ Techniques for gathering

requirements

7
Software
Requirement ➔ U

Specification ➔ C

➔ SRS ➔ C

➔ Purpose of SRS ➔ C
➔ Requirement analysis
➔ M
◆ SRS -> SRD
➔ V
➔ What SRD Provides?
➔ T
➔ SRD Characteristics

➔ Techniques for gathering

requirements

8
Software
Requirement ➔ One to one interview

Specification ➔ Group interview

➔ SRS ➔ Prototyping

➔ Purpose of SRS ➔ Request for proposals

➔ Requirement analysis
➔ Questionnaires
◆ SRS -> SRD
➔ Use cases
➔ What SRD Provides?
➔ Brainstorming
➔ SRD Characteristics

➔ Techniques for gathering

requirements

9
Software
Requirement
Engineering Tasks
➔ Inception

➔ Elicitation

➔ Elaboration

➔ Negotiation

➔ Specification

➔ Validation

➔ Requirement Management

16
SOFTWARE ENGINEERING PROCESS
Software Engineering Tasks
Software Engineering Tasks
System Requirement Specification
System Requirement Specification
System Requirement Specification
System Requirement Specification
 LANGUAGES AND PROCESSORS FOR REQUIREMENTS SPECIFICATION

❑ A number of special purpose languages and processors have been developed to permit concise

statement and automated analysis of requirements specification for software.

❑ Our purpose is to provide a brief introduction to requirements specification languages and

processors.
 PSL/PSA

❑ The Problem statement language(PSL) was developed by professor Daniel teich row at the
university on Michigan
❑ The problem statement analyzer is the PSL processor
❑ PSL and PSA system is sometimes referred to as components of the ISDOS project
❑ PSL/PSA system is sometimes referred to as the ISDOS system
➢ System input/output flow
➢ System structure
➢ Data structure
➢ Data derivation
➢ System size and volume
➢ System dynamics
➢ System properties
➢ Project management
PSL System input/output flow
❖ The system I/o flow aspect deals with the interaction between a system and its environment.
System Structure
❖ System structure is concerned with the hierarchies among objects in a system.
Data Structure
❖ Data structure aspect includes all the relationships that exist among data used and/or manipulated
by a system as seen by the users of the system.
Data derivation
❖ The data derivation aspect of the system description specifies which data object are involved in
particular processes in the system.
System size and volume
❖ The system size and volume aspect is concerned with the size of the system and those factors the
volume of processing required.
System dynamic
❖ Aspect of a system description presents the manner in which the system” behaves” over time.
❖ Project management requires that project related information.
 PSA (PROBLEM STATEMENT ANALYZER)

❑ PSA is an automated analyzer for processing requirements stated in PSL.

❑ PSA system can provide reports in four categories

Data base modification reports

Reference reports

Summary reports

Analysis reports
 RSL / REVS

❖ The requirements statement language(RSL) was developed by the TRW defense and space Systems

group to permit concise .

❖ The Requirements engineering validation system(REVS)processes and analyzes RSL statements.

❖ The fundamental characteristic of RSL is the flow oriented approach used to describe real-time

systems.

❖ The requirements engineering and validation system (REVS) operates on RSL statements.

REVS CONSISTS OF THREE MAJOR COMPONENTS

A translator for RSL

A centralized data base the Abstract System Semantic Model(ASSM).

A set of automated tools for processing information in ASSM.

 STRUCTURED ANALYSIS AND DESIGN TECHNIQUE (SADT)

❑ SADT was developed by D.T Ross and colleagues at softtech, inc.

❑ The SADT language is called the language of Structured Analysis(SA).

❑ DATA DIAGRAM specify data object in the nodes and activities on the arcs.

❑ ACTIVITY DIAGRAM the inputs and output are data flows and the mechanisms are processors

control is data that is used, but not modified.

DATA DIAGRAM COMPONENTS
 ❑ SOFTWARE DESIGN:

❖ Fundamental Design concepts

❖ Modules and modularizing Criteria

❖ Design Notations
UNIT - III
❖ Design Techniques

❖ Detailed Design Consideration

❖ Real time and distributed system design

❖ Test plan

❖ Milestones, walk through and inspection.

 ➔ Meaning:
Software Design ◆ In this phase, the designer plans how a software system
should be developed in order to make it Functional,
➔ Meaning Reliable,Understandable,Modifiable and Maintainable.
➔ Types of Design ◆ Design phase usually follows Top Down Approach
➔ Design Principles
➔ Coupling and Cohesion ➔ Purpose of Design Phase:
◆ Meaning
● Provide solution to problem stated in SRS.
◆ Types of Coupling
◆ Types of Cohesion

4
 ➔ More Details:
Software Design ◆ Items defined during design phase
● Module structure
➔ Meaning
➔ Types of Design ● Control relationship among modules
➔ Design Principles ● Interface among modules
➔ Coupling and Cohesion ● Data structures involved in modules
◆ Meaning
● Algorithm for individual modules
◆ Types of Coupling
◆ Types of Cohesion

5
 ➔ What a Module consists of?
Software Design ◆ Several functions
◆ Associated data structures
➔ Meaning
➔ Types of Design
➔ Design Principles
➔ Coupling and Cohesion
◆ Meaning
◆ Types of Coupling
◆ Types of Cohesion

6
 ➔ Types of Design:
Software Design ◆ Conceptual -

➔ Meaning ◆ Technical -
➔ Types of Design
➔ Design Principles
➔ Coupling and Cohesion
◆ Meaning
◆ Types of Coupling
◆ Types of Cohesion

7
 1. Design Principles:
Software Design a. 3 Principles:
i. Abstraction
➔ Meaning
➔ Types of Design ii. Encapsulation
➔ Design Principles iii. Information Hiding
➔ Coupling and Cohesion
◆ Meaning
◆ Types of Coupling
◆ Types of Cohesion

8
 ➔ Coupling and Cohesion:
Software Design ◆ Module Coupling:
● Coupling is the measure of degree of
➔ Meaning
➔ Types of Design interdependence between modules.
➔ Design Principles
➔ Coupling and Cohesion
◆ Meaning
◆ Types of Coupling
◆ Types of Cohesion

9
 ➔ Coupling and Cohesion:
Software Design ◆ Module Cohesion:
● Coupling is the measure of degree of
➔ Meaning
➔ Types of Design interdependence within a module.
➔ Design Principles
➔ Coupling and Cohesion
◆ Meaning
◆ Types of Coupling
◆ Types of Cohesion

10
 ➔ Coupling and Cohesion:
Software Design ◆ Characteristics of GOOD design:

➔ Meaning ● Component independence/Functional

➔ Types of Design Independence
➔ Design Principles ○ Low Coupling
➔ Coupling and Cohesion ○ High Cohesion
◆ Meaning
● Should implement all functionality correctly
◆ Types of Coupling
● Should be easily understandable
◆ Types of Cohesion
● Should be efficient
● Easy to change, Maintainable
● Fundamental concept of good design is
modularity

11
 ➔ Coupling and Cohesion:
Software Design ◆ Important Note:
● Abstraction Concept
➔ Meaning
➔ Types of Design ● High coupling and low cohesion -
➔ Design Principles Encapsulation
➔ Coupling and Cohesion ● Cohesion - Information Hiding
◆ Meaning
◆ Types of Coupling
◆ Types of Cohesion

12
 ➔ Types of Coupling:
Software Design
➔ Meaning
➔ Types of Design LOW
➔ Design Principles
➔ Coupling and Cohesion
◆ Meaning
◆ Types of Coupling
◆ Types of Cohesion

HIGH

14
 ➔ Types of Coupling:
Software Design ➔ 1. Content Coupling:
◆ One component references the other
➔ Meaning
➔ Types of Design ◆ Very High level of coupling
➔ Design Principles ◆ Ex: Component directly modifies the another
➔ Coupling and Cohesion component’s data
◆ Meaning
◆ Types of Coupling
◆ Types of Cohesion

15
 ➔ Types of Coupling:
Software Design ➔ 2. Common Coupling:
◆ Two components share the common data
➔ Meaning
➔ Types of Design ● Global data structures
➔ Design Principles ● Common block
➔ Coupling and Cohesion ◆ Ex: one component gets data from multiple
◆ Meaning
sources
◆ Types of Coupling
◆ Types of Cohesion

16
 ➔ Types of Coupling:
Software Design ➔ 3.Control Coupling:
◆ Components passes control parameters to
➔ Meaning
➔ Types of Design coupled components.
➔ Design Principles ◆ Ex: A flag set in one module is checked in
➔ Coupling and Cohesion another module.
◆ Meaning
◆ Types of Coupling
◆ Types of Cohesion

17
 ➔ Types of Coupling:
Software Design ➔ 4. Stamp Coupling:
◆ Components passes data structures to another
➔ Meaning
➔ Types of Design component, that does not have access to the
➔ Design Principles entire data structure
➔ Coupling and Cohesion ◆ It always require second component
◆ Meaning
◆ Operation performed by first component and
◆ Types of Coupling
second component may be different.
◆ Types of Cohesion
◆ Ex: Composite data item like array or structures

18
 ➔ Types of Coupling:
Software Design ➔ 5.Data Coupling:
◆ If there are homogeneous data item passed
➔ Meaning
➔ Types of Design through parameters.
➔ Design Principles ◆ Ex: a integer, a float or a character
➔ Coupling and Cohesion
◆ Meaning
◆ Types of Coupling
◆ Types of Cohesion

19
 ➔ Types of Cohesion:
Software Design
➔ Meaning
➔ Types of Design
➔ Design Principles
➔ Coupling and Cohesion
◆ Meaning
◆ Types of Coupling
◆ Types of Cohesion

21
 ➔ Types of Cohesion:
Software Design ➔ 1. Coincidental Cohesion:
◆ Parts of the component are only related by their
➔ Meaning
➔ Types of Design location in source code.
➔ Design Principles ◆ Elements are scattered.
➔ Coupling and Cohesion ◆ Ex: Module contains random collection of
◆ Meaning
functions.
◆ Types of Coupling
◆ Types of Cohesion

22
 ➔ Types of Cohesion:
Software Design ➔ 2. Logical Cohesion:
◆ Elements of the components are related logically
➔ Meaning
➔ Types of Design but not functionally.
➔ Design Principles ◆ Operations related, Function different
➔ Coupling and Cohesion ◆ Ex: Set of print functions for different purpose
◆ Meaning
◆ Types of Coupling
◆ Types of Cohesion

23
 ➔ Types of Cohesion:
Software Design ➔ 3. Temporal Cohesion:
◆ Elements of the components are related by time.
➔ Meaning
➔ Types of Design ◆ All functions are executed in same time span.
➔ Design Principles ◆ Ex: Initialization of variable
➔ Coupling and Cohesion
◆ Meaning
◆ Types of Coupling
◆ Types of Cohesion

24
 ➔ Types of Cohesion:
Software Design ➔ 4. Procedural Cohesion:
◆ Elements of the components ensures particular
➔ Meaning
➔ Types of Design order of execution.
➔ Design Principles ◆ Ex: Kruskal’s Algorithm
➔ Coupling and Cohesion
◆ Meaning
◆ Types of Coupling
◆ Types of Cohesion

25
 ➔ Types of Cohesion:
Software Design ➔ 5.Communicational Cohesion:
◆ Elements of the components performs series of
➔ Meaning
➔ Types of Design actions by a sequence of steps to be followed by
➔ Design Principles the product and all actions are performed in a
➔ Coupling and Cohesion common data structure.
◆ Meaning
◆ Ex: The set of functions defined on an array or
◆ Types of Coupling
stack.
◆ Types of Cohesion

26
 ➔ Types of Cohesion:
Software Design ➔ 6. Sequential Cohesion:
◆ Output of one component is the input to the
➔ Meaning
➔ Types of Design another.
➔ Design Principles ◆ Occur naturally in function programming
➔ Coupling and Cohesion ◆ Ex:
◆ Meaning
◆ Types of Coupling
◆ Types of Cohesion

27
 ➔ Types of Cohesion:
Software Design ➔ 7.Functional Cohesion:
◆ Every essential element to a single computation
➔ Meaning
➔ Types of Design is contained in the component.
➔ Design Principles ◆ Ex:
➔ Coupling and Cohesion
◆ Meaning
◆ Types of Coupling
◆ Types of Cohesion

28
 DESIGN NOTATIONS

❖ Good notation can clarify the interrelationships and interaction of interest.

❖ Three level of design specifications:

1. External design specification

2. Architectural design specification

3. Detailed design specification

 NOTATIONS

Notation used to specify the external characteristic , architectural structure and processing details of a

software system include:

@ Dataflow diagram

@ Structure charts

@ HIPO diagrams

@ Procedure specification

@ Pseudo code

@ Structured flow charts

 DATAFLOW DIAGRAM

➢ Dataflow diagrams are directed graphs in which the nodes specify processing activities and the arcs
specify the data items transmitted between processing nodes.
➢ Dataflow diagram can be expressed using informal notation can be used to processing nodes , data
sources , data sinks and data stores.
➢ Dataflow diagrams are excellent communicating with customer during requirements and analysis.
➢ There are also used for representation of external and top level internal design specifications
 STRUCTURED CHARTS

➢ Structure chats are used to architectural design to document hierarchical structure , parameters and
interconnection in a system .
➢ It differs from a flowchart in two ways:
## Structured chart has know decisions boxes.
## Sequential ordering of tasks
 HIPO DIAGRAMS

➢ HIPO diagram(Hierarchy-process-input-output) were developed at IBM as design representation

schemes for top- down software developed and external documentation aids for products.
➢ HIPO diagram contains a visual table of contents, a set of overview diagram and set detail
diagrams , it contains of a tree structured .
 PROCEDURE TEMPLATE

➢ The format of a procedure interface specification of architectural design , only information in level
1 need to supplied . The information on levels 2,3, and 4 can be included in successive steps.
➢ It provides initial architectural design , specification of side effects , exception handling ,
processing algorithms and data representation.
 PSEUDO CODE NOTATION

➢ Pseudo code notation can be used in both the architectural and detailed design phases .
➢ The designer describes system characteristics using short , concise , that are structured by
keywords such as If-Then- Else , While-Do and End.
➢ Pseudo code can replace flowcharts and reduce the amount of external documentations required to
describe system
 STRUCTURED FLOWCHARTS

➢ Flowcharts means are specifying and documenting algorithmic detailed in a software system.
➢ Flowchart interoperate rectangular boxes for actions , diamond shaped boxes for decisions ,
directed arcs for interconnections for boxes.
➢ Single entry , single exit allows hierarchical nesting of structured flowchart to design in top-down
fashion.
 DECISION TABLES

➢ Decision tables can be used to specify complex decision logic in a high level software
specification.
➢ There are useful for specifying algorithmic logic during detailed design.
➢ Several preprocessor packages are available to translate decision tables into COBOL.
 DESIGNING TECHNIQUES

➢ The designing process involves in developing the conceptual view of the system.
➢ The Software Design Techniques that takes place are:
Stepwise Refinement
Levels Of Abstraction
Structured Design
Integrated Top-Down Development
Jackson Structured Programming
 STEPWISE REFINEMENT

➢ Stepwise refinement is a top–down technique for decomposing a system from high level
specification into more elementary levels.
➢ It is also known as “ Stepwise program Development” and “Successive Refinement”.
➢ The activities that takes place are:
1. Decomposing design decisions to elementary levels
2. Isolating design aspects that are not truly interdependent.
❖ Postponing decisions concerning representation details as long as possible.
❖ Carefully demonstrating that each successive step in the refinement process is a faithful expansion
of previous steps.
❖ The procedure for computing the first N prime numbers and writing them in file F is complete.
❖ It is complete because each pseudocode statement has been refined into executable source code.
❖ The efficiency of the program can be vastly improved in several ways.
❖ For example,
it is not necessary to check X for divisibility by every number K between S and X-l.
STEPWISE REFINEMENT
 LEVELS OF ABSTRACTION

➢ Levels of abstraction was originally described by Dijkstra as a bottom-up design technique in

which an operating system was designed as a layering of hierarchical levels starting at level 0 .
➢ Internal functions are hidden from other levels, that can only be invoked by functions on the same
level.
➢ Each level of abstraction performs a set of services for the functions on the next higher level of
abstraction.
➢ Thus a file manipulation system might be layered as a set of routines to manipulate fields.
➢ Higher level functions can invoke functions on lowest levels, but lower-level functions cannot
invoke make use of higher-level functions.
➢ Operating system are listed in Level 0 : Processor allocation clock interrupt handling
Level 1 : Memory segment controller
Level 2 : Console message interpreter
Level 3 : I/O buffering
Level 4 : User programs
Level 5 : operator
 STRUCTURED DESIGN

➢ Structured design was developed by Constantine as a top-down technique for architectural design
of software systems.
➢ The basic approach is structured design is systematic conversion of data-flow diagrams into
structure charts.
➢ Design heuristics such as coupling and cohesion are used to guide the design process.
➢ The first step in structured design is review and refinement of the data flow diagram(s) developed
during requirements definition and external design.
STRUCTURED DESIGN
INTEGRATED TOP – DOWN DEVELOPMENT
JACKSON STRUCTURED PROGRAMMING
JACKSON STRUCTURED PROGRAMMING
CMM (Capability ➔ Meaning:
Maturity Model) ◆ CMM is developed by Software Engineering
Institute(SEI)
➔ Meaning
◆ Well known benchmark for determining the
➔ Levels
◆ Level 1 quality of the process in the organisation
◆ Level 2
◆ Level 3 ◆ Provides guidelines for maturity of those software
◆ Level 4 products
◆ Level 5
◆ It has 5 levels
◆ Except level-1, all other level activities are
explained by KPA[Key Process Areas]

31
CMM (Capability ➔ Level 1: Initial:
Maturity Model)
◆ Undefined
➔ Meaning ◆ Chaotic
➔ Levels ◆ No process at place
◆ Level 1
◆ Level 2
➔ NO KPAs
◆ Level 3
◆ Level 4
◆ Level 5

32
CMM (Capability ➔ Level 2: Repeatable:
Maturity Model)
◆ Basic process management in place
➔ Meaning ◆ Prior experience in same kind of project is used
➔ Levels
◆ Level 1 ➔ KPAs:
◆ Level 2
◆ Project planning
◆ Level 3
◆ Requirement management
◆ Level 4
◆ Level 5 ◆ Configuration management
◆ Sub contract management
◆ SQA

33
CMM (Capability ➔ Level 3: Defined:
Maturity Model)
◆ Additional process management activities are
➔ Meaning documented
➔ Levels ◆ Specifies set of integrated project specific
◆ Level 1 software engineering and management processes
◆ Level 2
◆ Level 3
➔ KPAs:
◆ Level 4
◆ Level 5 ◆ Organisation process definition
◆ Organisation process focus
◆ Peer reviews
◆ Intergroup coordination
◆ Training programs

34
CMM (Capability ➔ Level 4: Managed:
Maturity Model)
◆ Standards are built for organisation.
➔ Meaning ◆ Specifies set quantitative goals for specific
➔ Levels software engineering and management processes
◆ Level 1
◆ Level 2
➔ KPAs:
◆ Level 3
◆ Software Qulaity Management
◆ Level 4
◆ Level 5 ◆ Quantitative Management

35
CMM (Capability ➔ Level 5: Optimized:
Maturity Model)
◆ Leveraging on knowledge and innovative ideas
➔ Meaning ◆ Continuous process improvement Using feedback
➔ Levels ◆ Prevention of occurrence of defect
◆ Level 1
◆ Level 2
◆ Level 3
➔ KPAs:
◆ Level 4
◆ Level 5 ◆ Process Change Management
◆ Technology Change Management
◆ Defect prevention

36
 ❑ Implementation issues

❖ Structured Coding techniques

❖ Coding style
UNIT - IV ❖ Standards and guidelines

❖ Documentation guidelines

❖ Type checking

❖ Scooping rules

❖ Concurrency mechanisms.
 REAL TIME AND DISTRIBUTED SYSTEM DESIGN

1. Systems which monitor and control their environment.

2. Inevitably associated with hardware devices

Sensors:

Collect data from the system environment;

Actuators:

Change (in some way) the system’s environment;

3. Time is critical. Real-time systems MUST respond within specified times.

 REAL TIME AND DISTRIBUTED SYSTEM DESIGN

• A real-time system is a software system where the correct functioning of the system depends on

the results produced by the system and the time at which these results are produced.

• A soft real-time system is a system whose operation is degraded if results are not produced

according to the specified timing requirements.

• A hard real-time system is a system whose operation is incorrect if results are not produced

according to the timing specification.

 STIMULUS/RESPONSE SYSTEMS

• Given a stimulus, the system must produce a response within a specified time.

• Periodic stimuli.

Stimuli which occur at predictable time intervals

• For example, a temperature sensor may be polled 10 times per second.

• Aperiodic stimuli.

Stimuli which occur at unpredictable times

• For example, a system power failure may trigger an interrupt which must be processed by the

system.
A REAL-TIME SYSTEM MODEL
 SENSOR/ACTUATOR PROCESSES

Sensor control processes

Collect information from sensors. May buffer information collected in response to a sensor
stimulus.
Data processor
Carries out processing of collected information and computes the system response.
Actuator control processes
Generates control signals for the actuators.
 REAL-TIME PROGRAMMING

• Hard-real time systems may have to programmed in assembly language to ensure that deadlines

are met.

• Languages such as C allow efficient programs to be written but do not have constructs to

support concurrency or shared resource management.

 MILESTONES, WALK THROUGHS AND INSPECTIONS

➢ Development of project intermediate work products the opportunity to establish milestones and to
conduct inspections and reviews.
➢ These activities in turn expose errors, provide increased project communication, keep the project
on schedule and permit verification that the design satisfies the requirements.
➢ The two major milestones during design are
1. The Preliminary Design Review (PDR)
2. The Critical Design Review (CDR)
➢ The PDR is typically held near the end of architectural design and prior to detailed design CDR
occurs at the end of detailed and prior to implementation.
 TYPES OF REVIEW

1. WALKTHROUGH
➢ It is not a formal process/review
➢ It is led by the authors
➢ Author guide the participants through the document according to his or her thought process to
achieve a common understanding and to gather feedback.
➢ Useful for the people if they are not from the software discipline, who are not used to or cannot
easily understand software development process.
➢ Is especially useful for higher level documents like requirement specification, etc.

GOAL OF WALKTHROUGH
❑ To present the documents both within and outside the software discipline in order to gather the
information regarding the topic under documentation.
❑ To explain or do the knowledge transfer and evaluate the contents of the document
❑ To achieve a common understanding and to gather feedback.
❑ To examine and discuss the validity of the proposed solutions.
 TYPES OF REVIEW

2. Technical Review:
❖ It is less formal review
❖ It is led by the trained moderator but can also be led by a technical expert
❖ It is often performed as a peer review without management participation
❖ Defects are found by the experts (such as architects, designers, key users) who focus on the content
of the document.
❖ In practice, technical reviews vary from quite informal to very formal
The goals of the technical review are:
❖ To ensure that an early stage the technical concepts are used correctly
❖ To access the value of technical concepts and alternatives in the product
❖ To have consistency in the use and representation of technical concepts
❖ To inform participants about the technical content of the document
 TYPES OF REVIEW

3. INSPECTION
❑ It is the most formal review type
❑ It is led by the trained moderators
❑ During inspection the documents are prepared and checked thoroughly by the reviewers before the
meeting
❑ It involves peers to examine the product
❑ A separate preparation is carried out during which the product is examined and the defects are found
❑ The defects found are documented in a logging list or issue log
❑ A formal follow-up is carried out by the moderator applying exit criteria
The goals of inspection are:
❑ It helps the author to improve the quality of the document under inspection
❑ It removes defects efficiently and as early as possible
❑ It improve product quality
❑ It create common understanding by exchanging information
❑ It learn from defects found and prevent the occurrence of similar defects
 SOFTWARE TESTING
VERIFICATION AND VALIDATION
• Verification and Validation is the process of investigating that a software system satisfies
specifications and standards and it fulfills the required purpose.
Verification: "Are we building the product right?"
Validation: "Are we building the right product?"
- Barry Boehm
Verification:
❑ Verification is the process of checking that a software achieves its goal without any bugs. It is the
process to ensure whether the product that is developed is right or not.
❑ It verifies whether the developed product fulfills the requirements that we have.
❑ Verification is Static Testing.
Activities involved in verification:
1. Inspections
2. Reviews
3. Walkthroughs
4. Desk-checking
 SOFTWARE TESTING
Validation:
❑ Validation is the process of checking whether the software product is up to the mark or in other
words product has high level requirements.
❑ It is the process of checking the validation of product i.e. it checks what we are developing is the
right product.
❑ it is validation of actual and expected product.
❑ Validation is the Dynamic Testing.
❑ Activities involved in validation:
1. Black box testing
2. White box testing
3. Unit testing
4. Integration testing
VERIFICATION VS VALIDATION
BLACK BOX TESTING VS WHITE BOX TESTING
 SOFTWARE IMPLEMENTATION

Its includes programming methods, documentation and challenges in software implementation.

STRUCTURED PROGRAMMING

❖ It encourages encourages the developer to use subroutines and loops instead of using simple jumps

in the code, thereby thereby bringing clarity in the code and improving its efficiency Structured

programming also helps programmer to reduce coding time and organize code properly.

❖ Structured programming states how the program shall be coded.

❖ Structured programming uses three three main concepts:

1. Top-down analysis

2. Modular Programming

3. Structured Coding
 STRUCTURED PROGRAMMING MAIN CONCEPTS
1. Top-down analysis
❖ A software is always made to perform some rational work. This rational work is known as problem in
the software parlance. Thus it is very important that we understand how to solve the problem.
❖ Under top-down analysis, the problem is broken down into small pieces where each one has some
significance. Each problem is individually solved and steps are clearly stated about how to solve the
problem.
2. Modular Programming
❖ While programming, the code is broken down into smaller group of instructions. These groups are
known as modules, subprograms or subroutines.
❖ Modular programming based on the understanding of top-down analysis.
❖ It discourages jumps using ‘goto’ statements in the program, which often makes the program flow
non-traceable. Jumps are prohibited and modular format is encouraged in structured programming.
3. Structured Coding
❖ In reference with top-down analysis, structured coding sub-divides the modules into further smaller units
of code in the order of their execution.
❖ Structured programming uses control structure, which controls the flow of the program, whereas
structured coding uses control structure to organize its instructions in definable patterns.
 FUNCTONAL PROGRAMMING
Functional programming provides means of computation as mathematical functions, which produces results
irrespective of program state. This makes it possible to predict the behavior of the program.
Functional programming uses the following concepts:
First class and High-order functions:
These functions have capability to accept another function as argument or they return other
functions as results.
 CODING

❑ Good software development organizations normally require their programmers to adhere to some
well-defined and standard style of coding called coding standards.
❑ Most software development organizations formulate their own coding standards that suit them
most, and require their engineers to follow these standards rigorously.
❑ The purpose of requiring all engineers of an organization to adhere to a standard style of coding is
the following:
• A coding standard gives a uniform appearance to the codes written by different engineers.
• It enhances code understanding.
• It encourages good programming practices.
 CODING STANDARDS AND GUIDELINES
❖ A coding standard lists several rules to be followed during coding, such as the way variables are to
be named, the way the code is to be laid out, error return conventions, etc.
❖ Good software development organizations usually develop their own coding standards and
guidelines depending on what best suits their organization and the type of products they develop.
THE FOLLOWING ARE SOME REPRESENTATIVE CODING STANDARDS.
Rules for limiting the use of global:
These rules list what types of data can be declared global and what cannot.
Contents of the headers preceding codes for different modules:
❑ The information contained in the headers of different modules should be standard for an
organization.
❑ The exact format in which the header information is organized in the header can also be specified.
❑ The following are some standard header data:
• Name of the module. • Date on which the module was created.
• Author’s name. • Modification history.
• Synopsis of the module. • Global variables accessed/modified by the module.
•Different functions supported, along with their input/output parameters.
 CODING STANDARDS

Naming conventions for global variables, local variables, and constant identifiers:

❑ A possible naming convention can be that global variable names always start with a capital letter,

local variable names are made of small letters, and constant names are always capital letters.

Error return conventions and exception handling mechanisms:

❑ The way error conditions are reported by different functions in a program are handled should be

standard within an organization.

❑ For example, different functions while encountering an error condition should either return a 0 or 1

consistently.
 CODING GUIDELINES

Do not use a coding style that is too clever or too difficult to understand:
❖ Code should be easy to understand. Many inexperienced engineers actually take pride in writing
cryptic and incomprehensible code.
❖ Clever coding can obscure meaning of the code and hamper understanding. It also makes
maintenance difficult.
Avoid obscure side effects:
❖ The side effects of a function call include modification of parameters passed by reference,
modification of global variables, and I/O operations.
❖ An obscure side effect is one that is not obvious from a casual examination of the code. Obscure
side effects make it difficult to understand a piece of code.
❖ For example, if a global variable is changed obscurely in a called module or some file I/O is
performed which is difficult to infer from the function’s name and header information, it
becomes difficult for anybody trying to understand the code.
 CODING GUIDELINES

Do not use an identifier for multiple purposes:

❑ Programmers often use the same identifier to denote several temporary entities.
❑ For example, some programmers use a temporary loop variable for computing and a storing the
final result. The rationale that is usually given by these programmers for such multiple uses of
variables is memory efficiency, e.g. three variables use up three memory locations, whereas the
same variable used in three different ways uses just one memory location.
❑ However, there are several things wrong with this approach and hence should be avoided. Some of
the problems caused by use of variables for multiple purposes as follows:
➢ Each variable should be given a descriptive name indicating its purpose. This is not possible if an
identifier is used for multiple purposes. Use of a variable for multiple purposes can lead to
confusion and make it difficult for somebody trying to read and understand the code.
➢ Use of variables for multiple purposes usually makes future enhancements more difficult.
 CODING GUIDELINES

The code should be well-documented:

➢ As a rule of thumb, there must be at least one comment line on the average for every three-source

line.

The length of any function should not exceed 10 source lines:

➢ A function that is very lengthy is usually very difficult to understand as it probably carries out

many different functions. For the same reason, lengthy functions are likely to have

disproportionately larger number of bugs.

Do not use goto statements:

➢ Use of goto statements makes a program unstructured and makes it very difficult to understand.
 CODING REVIEW

➢ Code review for a model is carried out after the module is successfully compiled and the all the

syntax errors have been eliminated.

➢ Code reviews are extremely cost-effective strategies for reduction in coding errors and to produce

high quality code.

➢ Normally, two types of reviews are carried out on the code of a module.

➢ These two types code review techniques are

Inspection

Code walk through.

 CODE WALK THROUGHS

❑ Code walk through is an informal code analysis technique

❑ In this technique, after a module has been coded, successfully compiled and all syntax errors

eliminated.

SOME OF THESE GUIDELINES ARE THE FOLLOWING.

❑ The team performing code walk through should not be either too big or too small. Ideally, it should

consist of between three to seven members.

❑ Discussion should focus on discovery of errors and not on how to fix the discovered errors.

❑ In order to foster cooperation and to avoid the feeling among engineers that they are being

evaluated in the code walk through meeting, managers should not attend the walk through

meetings.
 CODE INSPECTION

❑ In contrast to code walk through, the aim of code inspection is to discover some common types of

errors caused due to oversight and improper programming.

❑ Following is a list of some classical programming errors which can be checkedduring code

inspection:
•Use of uninitialized variables.
• Jumps into loops.
• Nonterminating loops.
• Incompatible assignments.
• Array indices out of bounds.
• Mismatches between actual and formal parameter in procedure calls.
• Use of incorrect logical operators or incorrect precedence among operators.
• Improper modification of loop variables.
• Comparison of equally of floating point variables, etc.
 SOFTWARE DOCUMENTATION

❑ When various kinds of software products are developed then not only the executable files and the
source code are developed but also various kinds of documents such as users’ manual, software
requirements specification (SRS) documents, design documents, test documents, installation
manual, etc are also developed as part of any software engineering process. All these documents
are a vital part of good software development practice.
❑ Good documents are very useful and server the following purposes:
• Good documents enhance understandability and maintainability of a software product. They
reduce the effort and time required for maintenance.
• Use documents help the users in effectively using the system.
• Good documents help in effectively handling the manpower turnover problem. Even when
an engineer leaves the organization, and a new engineer comes in, he can build up the required
knowledge easily.
• Production of good documents helps the manager in effectively tracking the progress of the
project. The project manager knows that measurable progress is achieved if a piece of work is done
and the required documents have been produced and reviewed.
 SOFTWARE DOCUMENTATION

❑ Different types of software documents can broadly be classified into the following:
1. Internal documentation
2. External documentation
 SOFTWARE DOCUMENTATION

1. Internal documentation
❑ Internal documentation is the code comprehension features provided as part of the source code
itself. Internal documentation is provided through appropriate module headers and comments
embedded in the source code. Internal documentation is also provided through the useful variable
names, module and function headers, code indentation, code structuring, use of enumerated types
and constant identifiers, use of user-defined data types, etc. Careful experiments suggest that out of
all types of internal documentation meaningful variable names is most useful in understanding the
code. This is of course in contrast to the common expectation that code commenting would be the
most useful. The research finding is obviously true when comments are written without thought.
For example, the following style of code commenting does not in any way help in understanding
the code.
a = 10; /* a made 10 */
❑ But even when code is carefully commented, meaningful variable names still are more helpful in
understanding a piece of code. Good software development organizations usually ensure good
internal documentation by appropriately formulating their coding standards and coding guidelines.
 SOFTWARE DOCUMENTATION

2. External documentation
External documentation is provided through various types of supporting documents such as users’
manual, software requirements specification document, design document, test documents, etc. A
systematic software development style ensures that all these documents are produced in an orderly
fashion.
 IMPLEMENTATION ISSUES

Focus here is not on programming, although this is obviously important, but on other implementation

issues that are often not covered in programming texts:

Reuse

Most modern software is constructed by reusing existing components or systems. When you

are developing software, you should make as much use as possible of existing code.

Configuration management

During the development process, you have to keep track of the many different versions of

each software component in a configuration management system.

Host-target development

Production software does not usually execute on the same computer as the software

development environment. Rather, you develop it on one computer (the host system) and execute it on

a separate computer (the target system).

 IMPLEMENTATION ISSUES

Focus here is not on programming, although this is obviously important, but on other implementation

issues that are often not covered in programming texts:

Reuse

Most modern software is constructed by reusing existing components or systems. When you

are developing software, you should make as much use as possible of existing code.

Configuration management

During the development process, you have to keep track of the many different versions of

each software component in a configuration management system.

Host-target development

Production software does not usually execute on the same computer as the software

development environment. Rather, you develop it on one computer (the host system) and execute it on

a separate computer (the target system).

 REUSE

❖ From the 1960s to the 1990s, most new software was developed from scratch, by writing all

code in a high- level programming language.

❖ The only significant reuse or software was the reuse of functions and objects in programming

language libraries.

❖ Costs and schedule pressure mean that this approach became increasingly unviable, especially

for commercial and Internet-based systems.

❖ An approach to development based around the reuse of existing software emerged and is now

generally used for business and scientific software.

 REUSE LEVEL
❖ The abstraction level
At this level, you don’t reuse software directly but use knowledge of successful abstractions
in the design of your software.
❖ The object level
At this level, you directly reuse objects from a library rather than writing the code yourself.
❖ The component level
Components are collections of objects and object classes that you reuse in application systems.
❖ The system level
At this level, you reuse entire application systems.
 REUSE COSTS

❖ The costs of the time spent in looking for software to reuse and assessing whether or not it

meets your needs.

❖ Where applicable, the costs of buying the reusable software. For large off-the-shelf systems,

these costs can be very high.

❖ The costs of adapting and configuring the reusable software components or systems to reflect

the requirements of the system that you are developing.

❖ The costs of integrating reusable software elements with each other (if you are using software

from different sources) and with the new code that you have developed.
 REUSE COSTS

❖ The costs of the time spent in looking for software to reuse and assessing whether or not it

meets your needs.

❖ Where applicable, the costs of buying the reusable software. For large off-the-shelf systems,

these costs can be very high.

❖ The costs of adapting and configuring the reusable software components or systems to reflect

the requirements of the system that you are developing.

❖ The costs of integrating reusable software elements with each other (if you are using software

from different sources) and with the new code that you have developed.
 CONFIGURATION MANAGEMENT

❖ Configuration management is the name given to the general process of managing a changing
software system.
❖ The aim of configuration management is to support the system integration process so that all
developers can access the project code and documents in a controlled way, find out what changes
have been made, and compile and link components to create a system.

CONFIGURATION MANAGEMENT ACTIVITIES

❖ Version management, where support is provided to keep track of the different versions of
software components. Version management systems include facilities to coordinate development
by several programmers.
❖ System integration, where support is provided to help developers define what versions of
components are used to create each version of a system. This description is then used to build a
system automatically by compiling and linking the required components.
❖ Problem tracking, where support is provided to allow users to report bugs and other problems,
and to allow all developers to see who is working on these problems and when they are fixed.
CONFIGURATION MANAGEMENT TOOL INTERACTION
 HOST-TARGET DEVELOPMENT

Most software is developed on one computer (the host), but runs on a separate machine (the target).
More generally, we can talk about a development platform and an execution platform.
i) A platform is more than just hardware.
ii) It includes the installed operating system plus other supporting software such as a
database management system or, for development platforms, an interactive development
environment.
Development platform usually has different installed software than execution platform; these
platforms may have different architectures.
 ❑ QUALITY ASSURANCE
❑ walk through and inspection
❑ Static analysis
❑ symbolic exception
❑ TESTING

UNIT - V ❑ Unit testing and Debugging

❑ System testing
❑ Formal verification
❑ SOFTWARE MAINTENANCE
❑ Enhancing maintainability during development
❑ Managerial aspects of software maintenance
❑ Configuration management
❑ source code metrics
❑ other maintenance tools and techniques.
 ➔ Meaning:
Software Testing ◆ Testing is the process of executing the program with
intention to find errors.
➔ Meaning
➔ Difference between testing and ◆ Complete or exhaustive testing is not possible.
debugging
➔ Verification and Validation
➔ Types of testing
◆ Unit testing
◆ Integration testing
◆ System testing/Verification
● Alpha test
● Beta test
◆ Acceptance test/Validation
◆ Regression test
◆ Performance test
● Load test
● Stress test

5
 ➔ Difference between testing and debugging:
Software Testing ➔ Testing and debugging are different processes which occurs
at same time,
➔ Meaning ◆ Where testing -
➔ Difference between testing and ◆ Where debugging -
debugging
➔ Verification and Validation
➔ Types of testing
◆ Unit testing
◆ Integration testing
◆ System testing/Verification
● Alpha test
● Beta test
◆ Acceptance test/Validation
◆ Regression test
◆ Performance test
● Load test
● Stress test

6
 ➔ Verification and Validation:
Software Testing ➔ Revision:

➔ Meaning
➔ Difference between testing and
debugging
➔ Verification and Validation
➔ Types of testing
◆ Unit testing
◆ Integration testing
◆ System testing/Verification
● Alpha test
● Beta test
◆ Acceptance test/Validation
◆ Regression test
◆ Performance test
● Load test
● Stress test

7
 ➔ Types of testing
Software Testing ◆ Unit testing:
● Tests the functionality within the module.
➔ Meaning
➔ Difference between testing and
debugging
➔ Verification and Validation
➔ Types of testing
◆ Unit testing
◆ Integration testing
◆ System testing/Verification
● Alpha test
● Beta test
◆ Acceptance test/Validation
◆ Regression test
◆ Performance test
● Load test
● Stress test

8
 ➔ Types of testing
Software Testing ◆ Integration testing:
● Tests are focussing more on interaction
➔ Meaning
between the modules
➔ Difference between testing and
debugging
➔ Verification and Validation
➔ Types of testing
◆ Unit testing
◆ Integration testing
◆ System testing/Verification
● Alpha test
● Beta test
◆ Acceptance test/Validation
◆ Regression test
◆ Performance test
● Load test
● Stress test

9
 ➔ Types of testing:
Software Testing ◆ System testing/ Verification testing:
● Tests the software as a part of the bigger
➔ Meaning
system for which it is created.
➔ Difference between testing and
debugging
○ Alpha test
➔ Verification and Validation ○ Beta test
➔ Types of testing ◆ Alpha test:
◆ Unit testing ● Conducted by customer @ Developer’s
◆ Integration testing site.
◆ System testing/Verification
◆ Beta test:
● Alpha test
● Beta test ● Conducted by customer @ Customer’s
◆ Acceptance test/Validation site.
◆ Regression test
◆ Performance test
● Load test
● Stress test

10
 ➔ Types of testing:
Software Testing ◆ Acceptance test/Validation test:
● Testing is conducted by customer to
➔ Meaning
validate all requirements.
➔ Difference between testing and
debugging
➔ Verification and Validation
➔ Types of testing
◆ Unit testing
◆ Integration testing
◆ System testing/Verification
● Alpha test
● Beta test
◆ Acceptance test/Validation
◆ Regression test
◆ Performance test
● Load test
● Stress test

11
 ➔ Types of testing:
Software Testing ◆ Regression test:
● Ensuring that in the process of modifying
➔ Meaning
the existing system, the original
➔ Difference between testing and
debugging
functionality of the system was not
➔ Verification and Validation disturbed.
➔ Types of testing
◆ Unit testing
◆ Integration testing
◆ System testing/Verification
● Alpha test
● Beta test
◆ Acceptance test/Validation
◆ Regression test
◆ Performance test
● Load test
● Stress test

12
 ➔ Types of testing:
Software Testing ◆ Performance test:
● It encompasses a series of tests that are
➔ Meaning
designed to assess system response time
➔ Difference between testing and
debugging
and reliability.
➔ Verification and Validation ○ Load testing
➔ Types of testing ○ Stress testing
◆ Unit testing
◆ Integration testing
◆ System testing/Verification
● Alpha test
● Beta test
◆ Acceptance test/Validation
◆ Regression test
◆ Performance test
● Load test
● Stress test

13
 ➔ Types of testing:
Software Testing
◆ Performance test:
➔ Meaning ○ Load testing
➔ Difference between testing and
○ Stress testing
debugging
➔ Verification and Validation ◆ Load testing:
➔ Types of testing
◆ Unit testing
● Testing takes place at variety of load
◆ Integration testing levels in various combinations
◆ System testing/Verification
● Alpha test ◆ Stress testing:
● Beta test ● Loading is increased to the breaking point
◆ Acceptance test/Validation
◆ Regression test to determine how much capacity the
◆ Performance test software can handle.
● Load test
● Stress test

14
 ➔ Types of testing:
Software Testing
◆ Performance test:
➔ Meaning ○ Load testing
➔ Difference between testing and
○ Stress testing
debugging
➔ Verification and Validation ◆ Load testing:
➔ Types of testing
◆ Unit testing
● Testing takes place at variety of load
◆ Integration testing levels in various combinations
◆ System testing/Verification
● Alpha test ◆ Stress testing:
● Beta test ● Loading is increased to the breaking point
◆ Acceptance test/Validation
◆ Regression test to determine how much capacity the
◆ Performance test software can handle.
● Load test
● Stress test

15
 ➔ Types of testing:
Software Testing
◆ Functional testing or BB testing:

➔ Part -2 ● It involves only the output of certain input values

➔ Functional testing or BB testing ● Test data driven from specification
◆ Boundary value analysis ● No knowledge of code is necessary
◆ Equivalence class
partitioning
◆ Decision table based testing
➔ Structural testing or WB or GB
◆ Flow graph approach
◆ Graph matrix
◆ Loop testing

16
Software Testing ➔ Functional testing or BB testing:
● Boundary value analysis

➔ Part -2 ● The idea is to use input variables values at their

➔ Functional testing or BB testing minimum,normal and maximum values.
◆ Boundary value analysis
◆ Equivalence class
partitioning
◆ Decision table based testing
➔ Structural testing or WB or GB
◆ Flow graph approach
◆ Graph matrix
◆ Loop testing

17
Software Testing ➔ Functional testing or BB testing:
● Equivalence class partitioning
● Input domain if a program is partitioned into a
➔ Part -2
➔ Functional testing or BB testing finite number of equivalence classes.
◆ Boundary value analysis ● Test the representative value of each class
◆ Equivalence class
partitioning
◆ Decision table based testing
➔ Structural testing or WB or GB
◆ Flow graph approach
◆ Graph matrix
◆ Loop testing

18
Software Testing ➔ Functional testing or BB testing:
● Decision table based testing
● Widely accepted graphical tool for
➔ Part -2
➔ Functional testing or BB testing representing process specifications
◆ Boundary value analysis ● It is useful for describing situations in
◆ Equivalence class which number of combination of actions
partitioning taken under varying set of conditions
◆ Decision table based testing
● Used to analyse complex logical
➔ Structural testing or WB or GB
◆ Flow graph approach relationship
◆ Graph matrix
◆ Loop testing

19
Software Testing ➔ Structural testing or WB or GB:
◆ A complementary approach to functional
➔ Part -2 testing.
➔ Functional testing or BB testing
◆ Examine the internal structure of the program.
◆ Boundary value analysis
◆ Equivalence class ◆ Basic types:
partitioning
◆ Decision table based testing
● Static white box testing:
➔ Structural testing or WB or GB ○ Test the program without run it
◆ Flow graph approach
◆ Graph matrix ● Dynamic White box testing:
◆ Loop testing ○ Test the program by run it

20
Software Testing ➔ Structural testing or WB or GB:
◆ Flow graph approach
◆ The simple notation used for representing the
➔ Part -2
➔ Functional testing or BB testing control flow of the program
◆ Boundary value analysis
◆ Equivalence class
partitioning
◆ Decision table based testing
➔ Structural testing or WB or GB
◆ Flow graph approach
◆ Graph matrix
◆ Loop testing

21
Software Testing ➔ Structural testing or WB or GB:
◆ Graph matrix
● It is a two dimensional matrix that helps in
➔ Part -2
➔ Functional testing or BB testing determining the basic set
◆ Boundary value analysis
◆ Equivalence class
partitioning
◆ Decision table based testing
➔ Structural testing or WB or GB
◆ Flow graph approach
◆ Graph matrix
◆ Loop testing

22
Software Testing ➔ Structural testing or WB or GB:
◆ Loop testing
● Simple loops, Nested loops, concatenated
➔ Part -2
➔ Functional testing or BB testing
loops and unstructured loops
◆ Boundary value analysis
◆ Equivalence class
partitioning
◆ Decision table based testing
➔ Structural testing or WB or GB
◆ Flow graph approach
◆ Graph matrix
◆ Loop testing

23
Software Testing ➔ Integration Testing:
● Tests are focussing more on interaction
➔ Part -3
between the modules
➔ Integration testing ➔ Types:
◆ Top Down ◆ Top Down
◆ Bottom Up ◆ Bottom Up
◆ Sandwich ◆ Sandwich
◆ Bigbang ◆ Bigbang

24
Software Testing ➔ Integration Testing:
➔ TOP Down:
◆ Top level modules are developed and tested
➔ Part -3
➔ Integration testing first
◆ Top Down ◆ Dummy bottom level modules are required
◆ Bottom Up called “STUB”.
◆ Sandwich
◆ Bigbang

25
Software Testing ➔ Integration Testing:
➔ Bottom Up:
◆ Bottom level modules are developed and tested
➔ Part -3
➔ Integration testing first
◆ Top Down ◆ Dummy top level modules are required called
◆ Bottom Up “DRIVERS”.
◆ Sandwich
◆ Bigbang

26
Software Testing ➔ Integration Testing:
➔ Sandwich:
◆ Combines both top down and bottom up, such
➔ Part -3
➔ Integration testing that a layer is identified in between.
◆ Top Down
◆ Bottom Up
◆ Sandwich
◆ Bigbang

27
Software Testing ➔ Integration Testing:
➔ Big Bang:
◆ Test all modules independently
➔ Part -3
➔ Integration testing ◆ Then, integrate the module and perform test
◆ Top Down ◆ Finally, the integrated software is tested as a
◆ Bottom Up whole.
◆ Sandwich
◆ Bigbang

28
 ➔ Terminologies:
Terminologies ◆ Error/Mistake:
➔ Error/Mistake ● An incorrect human action produces incorrect
➔ Bug/Defect/Fault
➔ Failure result
➔ Robustness
➔ Reliability
➔ Re-engineering
➔ Cleanroom software engineering
➔ Refactoring
➔ Software Architecture
➔ Correctness
➔ Accuracy
➔ Completeness
➔ Release
➔ Version
➔ Variant
➔ Software Reuse
12
 ➔ Terminologies:
Terminologies ◆ Bug/Defect/Fault:
➔ Error/Mistake ● Deviation between the expected behaviour and
➔ Bug/Defect/Fault
➔ Failure actual behaviour identified while testing.
➔ Robustness
➔ Reliability
➔ Re-engineering
➔ Cleanroom software engineering
➔ Refactoring
➔ Software Architecture
➔ Correctness
➔ Accuracy
➔ Completeness
➔ Release
➔ Version
➔ Variant
➔ Software Reuse
13
 ➔ Terminologies:
Terminologies ◆ Failure:
➔ Error/Mistake ● Deviation between the expected behaviour and
➔ Bug/Defect/Fault
➔ Failure actual behaviour identified by customer.
➔ Robustness
➔ Reliability
➔ Re-engineering
➔ Cleanroom software engineering
➔ Refactoring
➔ Software Architecture
➔ Correctness
➔ Accuracy
➔ Completeness
➔ Release
➔ Version
➔ Variant
➔ Software Reuse
14
 ➔ Terminologies:
Terminologies ◆ Robustness:
➔ Error/Mistake ● The extent to which software tolerates
➔ Bug/Defect/Fault
➔ Failure unexpected problems.
➔ Robustness
➔ Reliability
➔ Re-engineering
➔ Cleanroom software engineering
➔ Refactoring
➔ Software Architecture
➔ Correctness
➔ Accuracy
➔ Completeness
➔ Release
➔ Version
➔ Variant
➔ Software Reuse
15
 ➔ Terminologies:
Terminologies ◆ Reliability:
➔ Error/Mistake ● The extent to which software program intended
➔ Bug/Defect/Fault
➔ Failure to function without failures.
➔ Robustness
➔ Reliability
➔ Re-engineering
➔ Cleanroom software engineering
➔ Refactoring
➔ Software Architecture
➔ Correctness
➔ Accuracy
➔ Completeness
➔ Release
➔ Version
➔ Variant
➔ Software Reuse
16
 ➔ Terminologies:
Terminologies ◆ Reengineering:
➔ Error/Mistake ● It is restructuring or rewriting part or all of the
➔ Bug/Defect/Fault
➔ Failure system, NOT single functionality.
➔ Robustness ●
➔ Reliability
➔ Re-engineering
➔ Cleanroom software engineering
➔ Refactoring
➔ Software Architecture
➔ Correctness
➔ Accuracy
➔ Completeness
➔ Release
➔ Version
➔ Variant
➔ Software Reuse
17
 ➔ Terminologies:
Terminologies ◆ CleanRoom Software Engineering:
➔ Error/Mistake ● Do it right at first time
➔ Bug/Defect/Fault
➔ Failure ● This process emphasises mathematical
➔ Robustness verification of correctness before program
➔ Reliability
➔ Re-engineering construction commences.
➔ Cleanroom software engineering
➔ Refactoring ➔ Advantages:
➔ Software Architecture ◆ Extremely low failure rates
➔ Correctness
➔ Accuracy ➔ Why important:
➔ Completeness ◆ Mistakes creates rework
➔ Release ◆ Rework takes time and increases cost
➔ Version
➔ Variant
➔ Software Reuse
18
 ➔ Terminologies:
Terminologies ◆ CleanRoom Software Engineering: 2
➔ Error/Mistake
➔ Bug/Defect/Fault Steps in CRSE:
➔ Failure 1. Analysis and design are created using box
➔ Robustness representation
➔ Reliability 2. Box - Specific level of abstraction
➔ Re-engineering 3. Correctness verification is applied once box is
➔ Cleanroom software engineering created
➔ Refactoring 4. Statistical usage testing done
➔ Software Architecture 5. Error records are verified
➔ Correctness
➔ Accuracy
➔ Completeness
➔ Release
➔ Version
➔ Variant
➔ Software Reuse
19
 ➔ Terminologies:
Terminologies ◆ Refactoring:
➔ Error/Mistake ● It is the process of changing the software system
➔ Bug/Defect/Fault
➔ Failure in such a way that, it doesn’t alter the external
➔ Robustness behaviour of code but improves the internal
➔ Reliability
➔ Re-engineering structure.
➔ Cleanroom software engineering
➔ Refactoring
➔ Software Architecture
➔ Correctness
➔ Accuracy
➔ Completeness
➔ Release
➔ Version
➔ Variant
➔ Software Reuse
20
 ➔ Terminologies:
Terminologies ◆ Software Architecture:
➔ Error/Mistake ● It is the structure or structures of system which
➔ Bug/Defect/Fault
➔ Failure comprises of software elements, the extremely
➔ Robustness visible properties of the elements and
➔ Reliability
➔ Re-engineering relationship among them.
➔ Cleanroom software engineering
➔ Refactoring
➔ Software Architecture
➔ Correctness
➔ Accuracy
➔ Completeness
➔ Release
➔ Version
➔ Variant
➔ Software Reuse
21
 ➔ Terminologies:
Terminologies ◆ Correctness:
➔ Error/Mistake ● The extent to which software meets expectations
➔ Bug/Defect/Fault
➔ Failure
➔ Robustness
➔ Reliability
➔ Re-engineering
➔ Cleanroom software engineering
➔ Refactoring
➔ Software Architecture
➔ Correctness
➔ Accuracy
➔ Completeness
➔ Release
➔ Version
➔ Variant
➔ Software Reuse
22
 ➔ Terminologies:
Terminologies ◆ Accuracy:
➔ Error/Mistake ● Meeting specification with precision.
➔ Bug/Defect/Fault
➔ Failure
➔ Robustness
➔ Reliability
➔ Re-engineering
➔ Cleanroom software engineering
➔ Refactoring
➔ Software Architecture
➔ Correctness
➔ Accuracy
➔ Completeness
➔ Release
➔ Version
➔ Variant
➔ Software Reuse
23
 ➔ Terminologies:
Terminologies ◆ Completeness:
➔ Error/Mistake ● The extent to which software have specified
➔ Bug/Defect/Fault
➔ Failure functions
➔ Robustness
➔ Reliability
➔ Re-engineering
➔ Cleanroom software engineering
➔ Refactoring
➔ Software Architecture
➔ Correctness
➔ Accuracy
➔ Completeness
➔ Release
➔ Version
➔ Variant
➔ Software Reuse
24
 ➔ Terminologies:
Terminologies ◆ Release:
➔ Error/Mistake ● An instant of the system delivered to the
➔ Bug/Defect/Fault
➔ Failure customer.
➔ Robustness
➔ Reliability
➔ Re-engineering
➔ Cleanroom software engineering
➔ Refactoring
➔ Software Architecture
➔ Correctness
➔ Accuracy
➔ Completeness
➔ Release
➔ Version
➔ Variant
➔ Software Reuse
25
 ➔ Terminologies:
Terminologies ◆ Version:
➔ Error/Mistake ● An instant of the system that differs in someway
➔ Bug/Defect/Fault
➔ Failure from other instances.
➔ Robustness
➔ Reliability
➔ Re-engineering
➔ Cleanroom software engineering
➔ Refactoring
➔ Software Architecture
➔ Correctness
➔ Accuracy
➔ Completeness
➔ Release
➔ Version
➔ Variant
➔ Software Reuse
26
 ➔ Terminologies:
Terminologies ◆ Variant:
➔ Error/Mistake ● An instant of the system which is functionally
➔ Bug/Defect/Fault
➔ Failure identical with other instances but designed for
➔ Robustness different hardware and software.
➔ Reliability
➔ Re-engineering
➔ Cleanroom software engineering
➔ Refactoring
➔ Software Architecture
➔ Correctness
➔ Accuracy
➔ Completeness
➔ Release
➔ Version
➔ Variant
➔ Software Reuse
27
 ➔ Terminologies:
Terminologies ◆ Software Reuse:
➔ Error/Mistake ● The process of using existing software artifacts
➔ Bug/Defect/Fault
➔ Failure and knowledge to build new software.
➔ Robustness
➔ Reliability
➔ Re-engineering
➔ Cleanroom software engineering
➔ Refactoring
➔ Software Architecture
➔ Correctness
➔ Accuracy
➔ Completeness
➔ Release
➔ Version
➔ Variant
➔ Software Reuse
28
 ➔ Maintenance:
Maintenance ◆ Definition:
➔ Definition ● Any work done to change the software after it is
➔ Types
in operation is called maintenance.
◆ ADAPTIVE
◆ PERFECTIVE
◆ CORRECTIVE
◆ PREVENTIVE

29
 ➔ Maintenance:
Maintenance ◆ Adaptive Maintenance:
➔ Definition ● Environment change for ever changing
➔ Types
environment.
◆ ADAPTIVE
◆ PERFECTIVE
◆ CORRECTIVE
◆ PREVENTIVE

30
 ➔ Maintenance:
Maintenance ◆ Perfective Maintenance:
➔ Definition ● Feature request
➔ Types
● Improving processing efficiency or performance
◆ ADAPTIVE
◆ PERFECTIVE improving.
◆ CORRECTIVE
◆ PREVENTIVE

31
 ➔ Maintenance:
Maintenance ◆ Corrective Maintenance:
➔ Definition ● Bug report
➔ Types
● Modifications due to defect.
◆ ADAPTIVE
◆ PERFECTIVE
◆ CORRECTIVE
◆ PREVENTIVE

32
 ➔ Maintenance:
Maintenance ◆ Preventive Maintenance:
➔ Definition ● Take measure to prevent the above said
➔ Types
maintenance activities.
◆ ADAPTIVE
◆ PERFECTIVE
◆ CORRECTIVE
◆ PREVENTIVE

33