C.

Abdul Hakeem College of Engineering & Technology

Department of MCA
MC4102 - Object Oriented Software Engineering
Unit Wise Important Topics

UNIT I SOFTWARE DEVELOPMENT AND PROCESS MODELS

1) Challenges in software development

Major Challenges in Software Development

 Rapid technology advancement

 Increasing customer demands
 Time limitations
 Limited infrastructure/resources
 Conflicts with software testing teams

Challenges of Software Developers :

Here is the list of some top challenges every Software Product Developer faces –

1. Changing Requirements
2. Providing complete Security to the software applications
3. Some times Misinterpreted requirements gives rise to a problem
4. Many times software developers face problem during System and Application
integration leading to failure of software projects also.

5. Further Maintenance and Upgradation

6. Adapting latest Technology
7. Sometimes when the developers don’t get appropriate Project infrastructure
for development and deployment of project
8. Getting Defects or Errors in the product during its last stage
9. Time limitations
10. When a new developer lacks proper Communication and Coordination with
the other developers of the same development team
11. It feels like a common problem when one developer Works with another
developer’s code
12. In last most of the software developers face this problem if they Don’t get
required support from Project Manger/Leader

2) An Engineering Perspective

What is Software Engineering?

Software engineering is defined as a process of analyzing user requirements and then

designing, building, and testing software application which will satisfy those
requirements.

1
Why Software Engineering? Software Crisis & its Solution:

What was the Software Crisis?

The Solution

Why Software Engineering is Popular?

Challenges of Software Engineering

Attributes for Software Products

Product
Description
Characteristics
The software should evolve to meet the changing demands of the
Maintainability
clients.
Dependability includes various characteristics. Dependable
Dependability software should never cause any physical or economic damage at
the time of system failure.
The software application should overuse system resources like
Efficiency
memory and processor cycle.
The software application should have specific UI and
Usability
documentation.

2
Characteristics of Good Software

Every software must satisfy the following attributes:

 Operational
 Transitional
 Maintenance

3) Object Orientation
Object-oriented refers to a programming language, system or software methodology
that is built on the concepts of logical objects.
Terms that are used universally in object orientation:

 Objects
 Classes
 Object References

In object-oriented programming, objects usually have the following properties:

 Encapsulation
 Inheritance
 Polymorphism

Uses of Object Orientation

Achieving these goals requires:

 Object-oriented programming languages

 Object-oriented tools
 Object-oriented modeling

4) Software Development Process

What is Software Development?

Software development refers to an iterative logical process that aims to create a

programmed software to meet unique business or personal objectives, goals, or
processes. The objective is achieved by a software developer writing computer code.
However, it also involves multiple steps such as research, designing a data and
process flow, writing technical documentation, comprehensively testing, debugging
and pushing it iteratively to live. This process is known as the software development
life cycle (SDLC).

3
Usually, any software development is categorized into two types:

1. Backend Development
2. Frontend Development

What is PDLC (Product Development Lifecycle)

The product development life cycle (PDLC) is the complete process of creating and
bringing a new product into the market. It includes the following 5 steps:

1. Product Conceptualization
2. Product Architecture and Design
3. Product Construction or Development
4. Product Release
5. Product Realization and Future Upgrade

Example

What is SDLC (Software Development Lifecycle)

Software Development Life Cycle is defined as a systematic approach used by the

software industry to design, develop, and test high-quality software. The main goal
behind SDLC is to produce high-quality software that meets or exceeds customer
expectations, reaches completion within times and cost estimates.

SDLC consists of the following activities:

 Planning
 Implementation
 Testing
 Documentation
 Deployment and maintenance
 Maintaining

Software Development Methodologies

Usually, there are 2 types of software development methodologies –

1. Waterfall model
2. Agile model

What is the Waterfall model?

A waterfall model represents a linear and sequential approach to software

development. The following steps are carried out sequentially in a waterfall approach.

 Requirements
 Design
 Code
 Testing

4
  Operations

What is the Agile model?

5) Iterative Development Process

In this Model, you can start with some of the software specifications and develop the
first version of the software. After the first version if there is a need to change the
software, then a new version of the software is created with a new iteration. Every
release of the Iterative Model finishes in an exact and fixed period that is called
iteration.

The various phases of Iterative model are as follows:

1. Requirement gathering & analysis

2. Design

3. Implementation

4. Testing

5. Deployment

6. Review

7. Maintenance

5
When to use the Iterative Model?

Advantage(Pros) of Iterative Model

Disadvantage(Cons) of Iterative Model

6) Process Models

Software Processes

A software process is the set of activities and associated outcome that produce a
software product. Software engineers mostly carry out these activities. These are four
key process activities, which are common to all software processes. These activities
are:

1. Software specifications
2. Software development
3. Software validation
4. Software evolution

The Software Process Model

Some examples of the types of software process models that may be produced are:

1. A workflow model
2. A dataflow or activity model
3. A role/action model

There are several various general models or paradigms of software development:

1. The waterfall approach

2. Evolutionary development
3. Formal transformation
4. System assembly from reusable components

Software Crisis

1. Size
2. Quality
3. Cost
4. Delayed Delivery

Program vs. Software

There are three components of the software as shown in fig:

6
7
7) Life Cycle Models

Software Development life cycle (SDLC) is a spiritual model used in project

management that defines the stages include in an information system development
project, from an initial feasibility study to the maintenance of the completed
application.

Here, are some important phases of SDLC life cycle:

8) Unified Process

Unified process (UP) is an architecture centric, use case driven, iterative and
incremental development process. UP is also referred to as the unified software
development process.

8
9) Iterative and Incremental
As the name indicates, Iterative and incremental development (IID) is a model that
is an incremental model that is developed in multiple cycles of iterations. Project is
started with a comparatively small task or component and increments are made in
each cycle of the iterations until desired product is reached.

There are four phases in IID :

 Inception
 Elaboration
 Construction
 Transition

Advantages of IID

Disadvantages of IID

Where and when to use IID model ?

10) Agile Processes

The meaning of Agile is swift or versatile."Agile process model" refers to a software

development approach based on iterative development. Agile methods break tasks
into smaller iterations, or parts do not directly involve long term planning. The project
scope and requirements are laid down at the beginning of the development process.
Plans regarding the number of iterations, the duration and the scope of each iteration
are clearly defined in advance.

Phases of Agile Model:

Following are the phases in the Agile model are as follows:

9
 1. Requirements gathering
2. Design the requirements
3. Construction/ iteration
4. Testing/ Quality assurance
5. Deployment
6. Feedback

Agile Testing Methods:

 Scrum
 Crystal
 Dynamic Software Development Method(DSDM)
 Feature Driven Development(FDD)
 Lean Software Development
 eXtreme Programming(XP)

When to use the Agile Model?

Advantage(Pros) of Agile Method

Disadvantages(Cons) of Agile Model

Example

UNIT II MODELLING OO SYSTEMS

11) Object Oriented Analysis (OOA / Coad-Yourdon)

Coad and Yourdon's Object-Oriented Analysis

Components of a Class Diagram

 Classes and Objects

 Attributes
 Instance Connections

10
 Services
 Message Connections

 Structures

 Generalization-Specialization Structures

 Whole-Part Structures

 Subjects
 Layers

12) Object Oriented Design (OOD/Booch)

The Booch method helps to design systems using the object paradigm. It covers the
analysis- and design phases of an object-oriented system. The method defines
different models to describe a system and it supports the iterative and incremental
development of systems.

The Booch method includes six types of diagrams such as class diagrams, object
diagrams, state transition diagrams, module diagrams, process diagrams and
interaction diagrams.

11
The Booch method notation

Figure 1. A class diagram notation.

Figure 2. A object diagram notation.

Figure 3. An interaction diagram.

The process is organized around a macro and a micro process.

The macro process identifies the following activities cycle:

 Conceptualization : establish core requirements

 Analysis : develop a model of the desired behavior
 Design : create an architecture
 Evolution: for the implementation
 Maintenance : for evolution after the delivery
The micro process is applied to new classes, structures or behaviors that emerge
during the macro process. It is made of the following cycle:

 Identification of classes and objects

12
 Identification of their semantics
 Identification of their relationships
 Specification of their interfaces and implementation

13) Hierarchical Object Oriented Design (HOOD)

13
14
15
14) Object Modeling Technique (OMT)
Object Modeling Technique (OMT) is real world based modeling approach for
software modeling and designing. It was developed basically as a method to develop
object-oriented systems and to support object-oriented programming. It describes the
static structure of the system.

16
Purpose of Object Modeling Technique
Object Modeling Technique’s Models:
There are three main types of models that has been proposed by OMT:
Object Model:

17
Dynamic Model:

18
Functional Model:

19
Phases of Object Modeling Technique:
OMT has the following phases:
Analysis
System Design
Object Design
Implementation

15) Requirement Elicitation

What Is Requirements Elicitation?
It is all about obtaining information from stakeholders. In other words, once the
business analysis has communicated with stakeholders for understanding their
requirements, it can be described as elicitation. It can also be described as a
requirement gathering.

The activities can be planned, unplanned, or both.

Following tasks are the part of elicitation:

 Prepare for Elicitation
 Conduct Elicitation
 Confirm Elicitation Results

Requirement Elicitation Process

Requirement elicitation process can be depicted using the following diagram:

Requirements Elicitation Techniques

There are several techniques available for elicitation, however, the commonly
used techniques are explained below:

20
#1) Stakeholder Analysis
#2) Brainstorming
#3) Interview
#4) Document Analysis/Review
#5) Focus Group
#6) Interface Analysis
#7) Observation
#8) Prototyping
#9) Joint Application Development (JAD)/ Requirement Workshops
#10) Survey/Questionnaire

16) Use Cases

use case

A use case is a methodology used in system analysis to identify, clarify and organize
system requirements.Every use case contains three essential elements:

 The actor

 The goal

 The system

21
Characteristics of use case
How to write a use case

There are two different types of use cases: business use cases and system use cases.

Other additional elements to consider when writing a use case include:

 Stakeholders, or anybody with an interest or investment in how the system

performs.

 Preconditions, or the elements that must be true before a use case can occur.

 Triggers, or the events that cause the use case to begin.

 Post-conditions, or what the system should have completed by the end of the
steps.

Benefits of use case

Use case vs. user story

The Use Case Approach

The Elements of a Use Case

A Use Case Template

A case template is often created to support construction of the case.

22
Title
Value
Actor
Stakeholders
Triggers
Main Flow
Alternative Flows
Post Conditions
Non-Functional Requirements
A use case can be written in different levels of detail. For example:

Brief use case

Casual use case
Fully dressed use case
17) SRS Document
A software requirements specification (SRS document) describes how a software
system should be developed. Simply put, an SRS provides everyone involved with a
roadmap for that project.

Why is an SRS Document Important?

What Does an SRS Include?

23
The Difference Between Functional and Non-functional Requirements

How to Write a Software Requirement Specification Document

 Create an Outline
 Define the Purpose

 Give an Overview

 Describe Functional and Non-functional Requirements

 Add Supplemental Details

 Get Approval

24
How to Write Software Use Cases in an SRS

What are the characteristics of a great SRS?

18) Identification of Classes and Relationships

What are the Class Diagrams?

Class diagrams are the main building block in object-oriented modeling. They are
used to show the different objects in a system, their attributes, their operations and the
relationships among them.

25
The following figure is an example of a simple class:

Relationships in Class Diagrams

Classes are interrelated to each other in specific ways. In particular, relationships in

class diagrams include different types of logical connections. The following are such
types of logical connections that are possible in UML:

 Association
 Directed Association
 Reflexive Association
 Multiplicity
 Aggregation
 Composition
 Inheritance/Generalization
 Realization

26
19) Identifying State and Behavior
A class includes objects with similar

 properties
 behavior
 relationships to other objects

State
All objects have three essential features:

 state
 behavior
 identity

Behavior and identity

You can model the states of a system by defining the states of the objects that
represent it. But to capture the complexity of real world problems, you also need to
consider how these objects behave.

27
The three most common types of operations that a class can have are

 modifiers
 selectors
 iterators

Two types of operation are needed to create and destroy instances of a class. These
are:

 Constructor
 Destructor

20) Interaction Diagrams (Sequence Diagram & Collaboration Diagrams)

What is Interaction diagram?

INTERACTION DIAGRAM are used in UML to establish communication between

objects. It does not manipulate the data associated with the particular communication
path. Interaction diagrams mostly focus on message passing and how these messages
make up one functionality of a system. Interaction diagrams are designed to display
how the objects will realize the particular requirements of a system. The critical
component in an interaction diagram is lifeline and messages.

Following are the different types of interaction diagrams defined in UML:

 Sequence diagram
 Collaboration diagram
 Timing diagram

28
Purpose of an Interaction Diagram

Important terminology

What is a Sequence Diagram?

A SEQUENCE DIAGRAM simply depicts interaction between objects in a

sequential order. The purpose of a sequence diagram in UML is to visualize the
sequence of a message flow in the system. The sequence diagram shows the
interaction between two lifelines as a time-ordered sequence of events.

Benefits of a Sequence Diagram

Drawbacks of a sequence diagram

What is the Collaboration diagram?

COLLABORATION DIAGRAM depicts the relationships and interactions among

software objects. They are used to understand the object architecture within a system
rather than the flow of a message as in a sequence diagram. They are also known as
“Communication Diagrams.”

Benefits of Collaboration Diagram

29
Drawbacks of a Collaboration Diagram

What is Timing diagram?

TIMING DIAGRAM is a waveform or a graph that is used to describe the state of a

lifeline at any instance of time. It is used to denote the transformation of an object
from one form into another form. Timing diagram does not contain notations as
required in the sequence and collaboration diagram. The flow between the software
program at various instances of time is represented using a waveform.

Benefits of a Timing Diagram

Drawbacks of a Timing Diagram

30
How to draw a Interaction diagram?

21) Unified Modeling Language and Tools.

Unified Modeling Language (UML) is a general purpose modelling language. The

main aim of UML is to define a standard way to visualize the way a system has been
designed. It is quite similar to blueprints used in other fields of engineering.

Diagrams in UML can be broadly classified as:

1. Structural Diagrams – Capture static aspects or structure of a system.

Structural Diagrams include: Component Diagrams, Object Diagrams, Class
Diagrams and Deployment Diagrams.
2. Behavior Diagrams – Capture dynamic aspects or behavior of the system.
Behavior diagrams include: Use Case Diagrams, State Diagrams, Activity
Diagrams and Interaction Diagrams.

Object Oriented Concepts Used in UML

UML Tools

Structural Things

Graphical notations used in structural things are most widely used in UML. These are
considered as the nouns of UML models. Following are the list of structural things.

31
  Classes
 Object
 Interface
 Collaboration
 Use case
 Active classes
 Components
 Nodes

Behavioral Things

These features include interactions and state machines.

Interactions can be of two types −

 Sequential (Represented by sequence diagram)

 Collaborative (Represented by collaboration diagram)

Grouping Things

Organizing the UML models is one of the most important aspects of the design. In
UML, there is only one element available for grouping and that is package.

Annotational Things

In any diagram, explanation of different elements and their functionalities are very
important. Hence, UML has notes notation to support this requirement.

Relationships

Following are the different types of relationships available in UML.

 Dependency
 Association
 Generalization
 Extensibility

32
UNIT III DESIGN PATTERNS

22) Design Principles

Single responsibility
Open-closed
Liskov substitution
Interface segregation
Dependency inversion
23) Design Patterns

In software engineering, a design pattern is a general repeatable solution to a

commonly occurring problem in software design. A design pattern isn't a finished
design that can be transformed directly into code. It is a description or template for
how to solve a problem that can be used in many different situations.

Uses of Design Patterns

Creational design patterns

Abstract Factory

Builder
Factory Method
Object Pool
Prototype
Singleton

Structural design patterns

Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Private Class Data
Proxy

Behavioral design patterns

Chain of responsibility
Command
Interpreter
Iterator
Mediator
Memento
Null Object
Observer

33
 State
Strategy
Template method
Visitor

Criticism

The concept of design patterns has been criticized by some in the field of computer
science.

Targets the wrong problem

Lacks formal foundations
Leads to inefficient solutions
Does not differ significantly from other abstractions
24) GRASP

GRASP (General Responsibility Assignment Software Patterns) is a design pattern in

object-oriented software development used to assign responsibilities for different
modules of code.

These roles are:

 Controller
 Information Expert
 Creator
 High Cohesion
 Low Coupling
 Polymorphism
 Protected Classes

34
25) GoF

What is Gang of Four (GOF)?

In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides
published a book titled Design Patterns - Elements of Reusable Object-Oriented
Software which initiated the concept of Design Pattern in Software development.

These authors are collectively known as Gang of Four (GOF). According to these
authors design patterns are primarily based on the following principles of object
orientated design.

 Program to an interface not an implementation

 Favor object composition over inheritance

Gang of Four Design Patterns

 Creational Design Patterns

 Structural Design Patterns
 Behavior Design Patterns

26) Dynamic and Static Object Modeling

Dynamic Modelling describes those aspect of the system that are concerned with
time and sequencing of the operations. It is used to specify and implement the control
aspect of the system. Dynamic model is represented graphically with the help of state
diagrams.

State diagram relates with events and states. Events represents external functional
activity and states represents values objects.

The static model addresses the static structural view of a problem, which does not
vary with time. In particular, a static model defines the classes in the system, the
attributes of the classes, the relationships between classes, and the operations of each
class.Static modeling refers to the modeling process and the UML class diagram
notation is used to depict the static model.

Table 1. Static and dynamic models

Characteristics Static models Dynamic models
Job run Not required. Required.
Requires automatic data Accepts automatic data sampling or a
sampling. Uses the actual data range:
size of the input data if the
size can be determined.  Automatic data sampling
Sample data Otherwise, the sample size determines the sample size
is set to a default value of dynamically according to the
1000 records on each stage type:
output link from each o For a database source
source stage. stage, the sample size is

35
Table 1. Static and dynamic models
Characteristics Static models Dynamic models
set to 1000 records on
each output link from the
stage.
o For all other source stage
types, the sample size is
set to the minimum
number of input records
among all sources on all
partitions.
 A data range specifies the
number of records to include in
the sample for each data source.

If the size of the sample data exceeds

the actual size of the input data, the
model uses the entire input data set.
Estimates are based on a
Scratch space Estimates are based on linear regression.
worst-case scenario.
Estimates are based on a
Disk space Estimates are based on linear regression.
worst-case scenario.
CPU utilization Not estimated. Estimates are based on linear regression.
Estimates are based on a
Dynamically determined. Best-case
best-case scenario. No
scenario does not apply. Input data is
Number of record is dropped. Input
processed, not propagated. Records can
records data is propagated from the
be dropped. Estimates are based on
source stages to all other
linear regression.
stages in the job.
Solely determined by the
Dynamically determined by the actual
record schema. Estimates
Record size record at run time. Estimates are based
are based on a worst-case
on linear regression.
scenario.
Data is assumed to be
Data Dynamically determined. Estimates are
evenly distributed among
partitioning based on linear regression.
all partitions.

36
UNIT IV SYSTEM TESTING

27) Software Verification Techniques

Verification and Validation is the process of investigating that a software system
satisfies specifications and standards and it fulfills the required purpose.
Barry Boehm described verification and validation as the following:
Verification: Are we building the product right?
Validation: Are we building the right product?
Activities involved in verification:

1. Inspections
2. Reviews
3. Walkthroughs
4. Desk-checking
Activities involved in validation:

1. Black box testing

2. White box testing
3. Unit testing
4. Integration testing

there are two fundamental approaches to verification:

 Dynamic verification, also known as experimentation, dynamic testing or,

simply testing. - This is good for finding faults (software bugs).

Depending on the scope of tests, we can categorize them in three families:

 Test in the small

 Test in the large
 Acceptance test

 Static verification, also known as analysis or, static testing - This is useful for
proving the correctness of a program.

 Code conventions verification

 Bad practices (anti-pattern) detection
 Software metrics calculation

37
  Formal verification
28) Object Oriented Checklist

What is Object Oriented Programming (OOP)?

OOPs Concepts:

1. Encapsulation

2. Abstraction

3. Polymorphism

4. Inheritance

The OO model is beneficial in the following ways −

 It facilitates changes in the system at low cost.

 It promotes the reuse of components.

 It simplifies the problem of integrating components to configure large system.

 It simplifies the design of distributed systems.

Checklist for object oriented programming

29) Functional Testing

What is Functional Testing?

FUNCTIONAL TESTING is a type of software testing that validates the software

system against the functional requirements/specifications.

What do you test in Functional Testing?

It mainly concentrates on -

 Mainline functions
 Basic Usability
 Accessibility
 Error Conditions

38
How to do Functional Testing

Functional Testing Non-Functional Testing

Functional testing is performed using the Non-Functional testing checks

functional specification provided by the the Performance, reliability, scalability
client and verifies the system against the and other non-functional aspects of the
functional requirements. software system.

Functional testing is executed first Non-functional testing should be

performed after functional testing

Manual Testing or automation tools can Using tools will be effective for this
be used for functional testing testing

Business requirements are the inputs to Performance parameters like speed,

functional testing scalability are inputs to non-functional
testing.

39
Functional testing describes what the Nonfunctional testing describes how good
product does the product works

Easy to do Manual Testing Tough to do Manual Testing

Examples of Functional testing are Examples of Non-functional testing are

 Unit Testing  Performance Testing

 Smoke Testing  Load Testing
 Sanity Testing  Volume Testing
 Integration Testing  Stress Testing
 White box testing  Security Testing
 Black Box testing  Installation Testing
 User Acceptance testing  Penetration Testing
 Regression Testing  Compatibility Testing
 Migration Testing

Functional Testing Tools

Here is a list of popular Functional Testing Tools. They are explained as follows:

 Selenium
 QTP
 JUnit
 soapUI
 Watir

30) Structural Testing

Structural testing is a type of software testing which uses the internal design of the
software for testing or in other words the software testing which is performed by the
team which knows the development phase of the software, is known as structural
testing.

40
Types of Structural Testing:
There are 4 types of Structural Testing:

Structural Testing Techniques:

 Statement Coverage

 Branch Coverage

 Path Coverage

 Statement Testing = (Number of Statements Exercised / Total Number of

Statements) x 100 %
 Branch Testing = (Number of decisions outcomes tested / Total Number of
decision Outcomes) x 100 %
 Path Coverage = (Number paths exercised / Total Number of paths in the
program) x 100 %

 Advantages of Structural Testing

 Disadvantages of Structural Testing
Structural Testing Tools
 JBehave
 Cucumber
 Junit
 Cfix

41
31) Class Testing
According to Davis the dependencies occurring in conventional systems are:

 Data dependencies between variables

 Calling dependencies between modules
 Functional dependencies between a module and the variable it computes
 Definitional dependencies between a variable and its types.
But in Object-Oriented systems there are following additional dependencies:

 Class to class dependencies

 Class to method dependencies
 Class to message dependencies
 Class to variable dependencies
 Method to variable dependencies
 Method to message dependencies
 Method to method dependencies
Issues in Testing Classes

32) Mutation Testing

Mutation Testing is a type of software testing in which certain statements of the

source code are changed/mutated to check if the test cases are able to find errors in
source code.

How to execute Mutation Testing?

42
How to Create Mutant Programs?

A mutation is nothing but a single syntactic change that is made to the program
statement. Each mutant program should differ from the original program by one
mutation.

What to change in a Mutant Program?

There are several techniques that could be used to generate mutant programs. Let's
look at them

 Operand replacement operators

 Expression Modification Operators
 Statement modification Operators

Automation of Mutation Testing:

List of tools available -

 Stryker
 PIT Testing

Types of Mutation Testing

In Software Engineering, Mutation testing could be fundamentally categorized into 3

types– statement mutation, decision mutation, and value mutation.

Mutation Score:

The mutation score is defined as the percentage of killed mutants with the total
number of mutants.

 Mutation Score = (Killed Mutants / Total number of Mutants) * 100

Advantages of Mutation Testing

Disadvantages of Mutation Testing

43
 33) Levels of Testing

34) Static and Dynamic Testing Tools

What is Static Testing?

Static Testing is a type of software testing in which software application is tested

without code execution. What is Dynamic Testing?

Under Dynamic Testing, a code is executed. It checks for functional behavior of

software system, memory/cpu usage and overall performance of the system. Hence
the name "Dynamic"

Static Testing Dynamic Testing

Testing was done without executing the program Testing is done by executing the program

This testing does the verification process Dynamic testing does the validation process

Static testing is about prevention of defects Dynamic testing is about finding and fixing the defects

Static testing gives an assessment of code and Dynamic testing gives bugs/bottlenecks in the software
documentation system.

44
Static testing involves a checklist and process to be Dynamic testing involves test cases for execution
followed

This testing can be performed before compilation Dynamic testing is performed after compilation

Static testing covers the structural and statement Dynamic testing techniques are Boundary Value
coverage testing Analysis & Equivalence Partitioning.

Cost of finding defects and fixing is less Cost of finding and fixing defects is high

Return on investment will be high as this process Return on investment will be low as this process
involved at an early stage involves after the development phase

More reviews comments are highly recommended for More defects are highly recommended for good
good quality quality.

Requires loads of meetings Comparatively requires lesser meetings

Since testing is of two types like 1) Static testing 2) Dynamic testing; accordingly the
tools used during these testing are also known as
1) Static testing tools
2) Dynamic testing tools
Static Test Tools:
1) Flow analyzers: They ensure consistency in data flow from input to output.
2) Path tests: They find unused code and code with contradictions.
3) Coverage analyzers: It ensures that all logic paths are tested.
4) Interface analyzers: It examines the effects of passing variables and data between
modules.
Dynamic Test Tools:
1) Test driver: It inputs data into a module-under-test (MUT).
2) Test beds: It simultaneously displays source code along with the program under
execution.
3) Emulators: The response facilities are used to emulate parts of the system not yet
developed.
4) Mutation analyzers: The errors are deliberately ‘fed’ into the code in order to test
fault tolerance of the system.

45
35) Software Maintenance – Categories – Challenges of Software Maintenance
Software maintenance is widely accepted part of SDLC now a days.

It stands for all the modifications and updations done after the delivery of software
product.

There are number of reasons, why modifications are required, some of them are
briefly mentioned below:

 Market Conditions

 Client Requirements

 Host Modifications

 Organization Changes

Types of maintenance

Following are some types of maintenance based on their characteristics:

 Corrective Maintenance

 Adaptive Maintenance

 Perfective Maintenance

 Preventive Maintenance

Cost of Maintenance

46
There are various factors, which trigger maintenance cost go high, such as:

Real-world factors affecting Maintenance Cost

Software-end factors affecting Maintenance Cost

Maintenance Activities

Software Re-engineering

47
Re-Engineering Process

 Decide

 Perform

 Restructure Program

 Re-structure data

 Apply Forward engineering

Component reusability

A component is a part of software program code, which executes an independent

task in the system. It can be a small module or sub-system itself.

Re-use can be done at various levels

 Application level - Where an entire application is used as sub-system of new

software.

 Component level - Where sub-system of an application is used.

 Modules level - Where functional modules are re-used.

Reuse Process

48
36) Maintenance of Object Oriented Software
Object-oriented management is a model for management and for project
management. The objective of object-oriented management is to provide a clear set of
principles set into a framework that enables all participants while minimizing
management overhead.

Concepts

 Aiming for total quality, as fast as possible, at the lowest cost

 Objects and the tree structure
 Agents: managers, experts, clients
 Iterations and the 80-zone efficiency
 Interface

37) Regression Testing

What is Regression Testing?

REGRESSION TESTING is defined as a type of software testing to confirm that a

recent program or code change has not adversely affected existing features.

Need of Regression Testing

How to do Regression Testing

49
Following are the most important tools used for both functional and regression testing
in software engineering:

Selenium

Quick Test Professional (QTP)

Rational Functional Tester (RFT)

Regression Testing and Configuration Management

Difference between Re-Testing and Regression Testing

Challenges in Regression Testing

50
UNIT V SOFTWARE QUALITY AND METRICS

38) Lorenz and Kidd Estimation

Lorenz & Kidd proposed a set of metrics which can be categorized in four categories
that are:
 Internal
 External
 Inheritance
 size
39) Use Case Points Method
A Use-Case is a series of related interactions between a user and a system that
enables the user to achieve a goal.

Use-Cases are a way to capture functional requirements of a system. The user of the
system is referred to as an ‘Actor’. Use-Cases are fundamentally in text form.

Use-Case Points – Definition

Use-Case Points (UCP) is a software estimation technique used to measure the

software size with use cases. The concept of UCP is similar to FPs.

The number of UCPs in a project is based on the following −

 The number and complexity of the use cases in the system.

 The number and complexity of the actors on the system.

 Various non-functional requirements (such as portability, performance,

maintainability) that are not written as use cases.

 The environment in which the project will be developed (such as the language,
the team’s motivation, etc.)

Use-Case Points Counting Process

The Use-Case Points counting process has the following steps −

 Calculate unadjusted UCPs

 Adjust for technical complexity

 Adjust for environmental complexity

 Calculate adjusted UCPs

51
Step 1: Calculate Unadjusted Use-Case Points.

You calculate Unadjusted Use-Case Points first, by the following steps −

 Determine Unadjusted Use-Case Weight

 Determine Unadjusted Actor Weight

 Calculate Unadjusted Use-Case Points

Unadjusted Use-Case Points (UUCP) = UUCW + UAW

Impact of the Factor = Impact Weight × Rated Value

TCF = 0.6 + (0.01 × TFactor)

Impact of the Factor = Impact Weight × Rated Value

Calculate the Environmental Factor (EF) as −

1.4 + (-0.03 × EFactor)

Calculate Adjusted Use-Case Points (UCP) as −

UCP = UUCP × TCF × EF

Advantages and Disadvantages of Use-Case Points

40) Class Point Method

CP = TUCP*TCF

41) Object Oriented Function Point

The Traditional Function Point Counting Procedure (TFPCP) cannot be used to
measure the functionality of an Object Oriented (OO) system.
There is a counting procedure to measure the functionality of an OO system during
the design phase from a designers' perspective.

52
It is adapted from the TFPCP. The main aim of this paper is to use all the available
information during the OO design phase to estimate Object Oriented Design Function
Points (OODFP).
The novel feature of this approach is that it considers all the basic concepts of OO
systems such as inheritance, aggregation, association and polymorphism.

42) Risk Management

Risk management is the process of identifying, assessing and controlling threats to an
organization's capital and earnings.

Importance

Risk management strategies and processes

All risk management plans follow the same steps that combine to make up the overall
risk management process:

 Establish context

 Risk identification

 Risk analysi

 Risk assessment and evaluation

 Risk mitigation

 Risk monitoring

 Communicate and consult

Risk management strategies should also attempt to answer the following questions:

1. What can go wrong? Consider both the workplace as a whole and individual
work.

2. How will it affect the organization? Consider the probability of the event and
whether it will have a large or small impact.

3. What can be done? What steps can be taken to prevent the loss? What can be
done recover if a loss does occur?

53
4. If something happens, how will the organization pay for it?

Risk management approaches

After the company's specific risks are identified and the risk management process has
been implemented, there are several different strategies companies can take in regard
to different types of risk:

 Risk avoidance

 Risk reduction

 Risk sharing

 Risk retaining

Limitations

 A false sense of stability

 The illusion of control

 Failure to see the big picture

 Risk management is immature

Risk management standards

The ISO recommends the following target areas, or principles, should be part of the
overall risk management process:

 The process should create value for the organization.

 It should be an integral part of the overall organizational process.

 It should factor into the company's overall decision-making process.

 It must explicitly address any uncertainty.

 It should be systematic and structured.

 It should be based on the best available information.

54
 It should be tailored to the project.

 It must take into account human factors, including potential errors.

 It should be transparent and all-inclusive.

 It should be adaptable to change.

 It should be continuously monitored and improved upon.

Risk management examples

43) Software Quality Models

Software Quality Models are a standardised way of measuring a software

product. With the increasing trend in software industry, new applications are
planned and developed everyday. Types of Software Quality Models

44) Analyzing the Metric Data

Metrics
Metrics set the parameters for the data your organization will use to measure
performance.
Data
Data is the set of numbers or calculations gathered for a specific metric.
Analytics
Once metrics are produced, it’s time to analyze and find patterns in the data.

Analyzing Software Measurement Data

There are three major items to consider for choosing the analysis technique.

 The nature of data

 The purpose of the experiment

55
  Design considerations

45) Metrics for Measuring Size and Structure

Software metrics is a standard of measure that contains many activities which
involve some degree of measurement.

It can be classified into three categories: product metrics, process metrics, and
project metrics.

 Product metrics

 Process metrics

 Project metrics

Scope of Software Metrics

Software metrics contains many activities which include the following −

 Cost and effort estimation

 Productivity measures and model

 Data collection

 Quantity models and measures

 Reliability models

 Performance and evaluation models

 Structural and complexity metrics

 Capability – maturity assessment

 Management by metrics

 Evaluation of methods and tools

Software is measured to:

 Establish the quality of the current product or process.

 To predict future qualities of the product or process.
 To improve the quality of a product or process.
 To determine the state of the project in relation to budget and schedule.

56
Goal Question Metric (GQM)

The GQM, developed by Dr. Victor Bassili defines a top-down, goal oriented
framework for software metrics.

It approaches software measurement using a three level model; conceptual,

operational, and quantitative.

GQM Steps

Step 1. Develop a set of Goals

Step 2. Develop a set of questions that characterise the goals.

Step 3. Specify the Metrics needed to answer the questions.

Step 4. Develop Mechanisms for data Collection and Analysis

Step 5. Collect Validate and Analyse the Data.

Step 6. Analyse in a Post Mortem Fashion

Step 7. Provide Feedback to Stakeholders

Six Sigma

What is Software Six Sigma?

From the software process aspect, Six Sigma has become a top-down methodology or
strategy to accelerate improvements in the software process and software product
quality. It uses analysis tools and product metrics to evaluate the software process and
software product quality.

DMAIC vs. DMADV

DMAIC is an abbreviation of Define requirements, Measure

performance, Analyse relationships, Improve performance, Control performance.

DMADV is an abbreviation of Define requirements, Measure

performance, Analyse relationships, Design solutions, Verify functionality.

Process mapping

The purpose of process mapping is helping project define the project process,
depict inputs, outputs and units of activity.

57
Metrics in Project Estimation

Some examples of metrics include Size Projections like Source Byte Size, Source
Lines of Code, Function pointers, GUI Features and other examples are Productivity
Projections such as Productivity Metrics.

Cost Estimation

 Effort Estimates
 Expert Judgement
 Estimation by Analogy

Cost Estimation Tools

46) Measuring Software Quality

There is a number of metrics available based on which software quality is measured.
But among them there are few most useful metrics which are most essential in
software quality measurement. They are –

1. Code Quality
2. Reliability
3. Performance
4. Usability
5. Correctness
6. Maintainability
7. Integrity
8. Security

When Do We Measure Software Quality?

How Do Developers Maintain the Software Code Quality?

How Does the QA Team Measure Software Quality?

47) Object Oriented Metrics

Object oriented metrics are used to measure properties of object
oriented designs. Metrics are a means for attaining more accurate estimations of
project milestones, and developing a software system that contains minimal faults.

58
McCabe Cyclomatic Complexity (CC)
Weighted Method per Class (WMC)
Depth of Inheritance Tree (DIT)
Number of Children (NOC)
Coupling between Objects (CBO)
Lack of Cohesion in Methods (LCOM)
Method Hiding Factor (MHF)
Attribute Hiding Factor (AHF)
Method Inheritance Factor (MIF)
Attribute Inheritance Factor (AIF)

The impact of these metrics on different components of Object Oriented system is

summarized below:

Class

Attribute

Method

Coupling and Cohesion

59