CSE3005-Software Engineering

 Unit -3 : DESIGN CONCEPTS AND TESTING

 26-July-2021
Unit III - DESIGN CONCEPTS AND TESTING

 The Design Concepts

 - The Design Model
 - Architectural Design
 - User Interface Design:
 InterfaceAnalysis
 - Interface Design Steps

 Requirements Modeling - Software Testing Fundamentals – Black

 Box Testing - White Box Testing - Unit Testing - Integration
 Testing -validation testing –system testing –Art of debugging –
 Project management
The Design Concepts

 What is it?
 Design is what almost every engineer wants to do.
 It is the place where creativity rules—where stakeholder requirements, business needs,
and technical considerations all come together in the formulation of a product or system.

 Who does it?

 Software engineers conduct each of the design tasks.

 Why is it important?
 Design allows you to model the system or product that is to be built.
 This model can be assessed for quality and improved before code is generated, tests
are conducted, and end users become involved in large numbers.
 Design is the place where software quality is established.
The Design Concepts

 What is the work product?

 A design model that encompasses architectural, interface, component-level, and
deployment representations is the primary work product that is produced during
software design.
The Design Concepts

 Requirements model into the design model

 Software design sits at the technical kernel of software engineering and is applied
regardless of the software process model that is used.
 Beginning once software requirements have been analyzed and modeled, software
design is the last software engineering action within the modeling activity and sets
the stage for construction (code generation and testing).
The Design Concepts

 A set of fundamental software design concepts has evolved over the history of
software engineering.
 Although the degree of interest in these concepts has varied over the years,
each has stood the test of time.
 Each provides the software designer with a foundation from which more
sophisticated design methods can be applied.
 Abstraction  Refinement

 Architecture  Aspects

 Patterns  Refactoring

 Separation of Concerns  Object Oriented Design Concepts

 Modularity  Design Classes

 Information Hiding  Dependency Inversion

The Design Concepts

 Abstraction
 Hide irrelevant data
 A solution is stated in large terms using the language of the problem environment at
the highest level abstraction.

 The lower level of abstraction provides a more detail description of the solution.

 A sequence of instruction that contain a specific and limited function refers in a

procedural abstraction. (Example: Door Opening)

 A collection of data that describes a data object is a data abstraction.

 Architecture
 Software architecture alludes to

“the overall structure of the software and the

ways in which that structure provides conceptual integrity for a system”

 The architecture is the structure of program modules where they interact with each other in a
specialized way.

 The components use the structure of data.

 The aim of the software design is to obtain an architectural framework of a system.

 The more detailed design activities are conducted from the framework.
 Architecture (Cont.)
 A set of properties of Architecture
 Structural Properties
 “the components of a system (e.g., modules, objects, filters) and the manner in which those components
are packaged and interact with one another.

 Extra-functional properties
 address “how the design architecture achieves requirements for performance, capacity, reliability,
security, adaptability, and other system characteristics.

 Families of related systems

 “draw upon repeatable patterns that are commonly encountered in the design of families of similar
systems.”
 Architectural (Cont.)
 Architectural Models
 the architectural design can be represented using one or more of a number of different models
 Structural models
 represent architecture as an organized collection of program components.
 Framework models
 increase the level of design abstraction by attempting to identify repeatable architectural design
frameworks (patterns) that are encountered in similar types of applications.
 Dynamic models
 Address the behavioral aspects of the program architecture, indicating how the structure or system
configuration may change as a function of external events.
 Process models
 focus on the design of the business or technical process that the system must accommodate.
 functional models
 can be used to represent the functional hierarchy of a system
 Architectural (Cont.)
 Architectural Description Language (ADL)
 Patterns
 A design pattern describes a design structure and that structure solves a particular design
problem in a specified content.
 Intent of Patterns
 Whether the design is applicable to the current work
 Whether the pattern can be reused (hence, saving design time),
 Whether the pattern can serve as a guide for developing a similar, but functionally or structurally
different pattern.
 Separation of Concerns
 Objective : that any complex problem can be more easily handled if it is subdivided into pieces
that can each be solved and/or optimized independently.
 A concern is a feature or behavior that is specified as part of the requirements model for the
software.
 Separating concerns into smaller and therefore more manageable pieces, a problem takes less
effort and time to solve.
 Divide – and – conquer
 Modularity
 A software is separately divided into name and addressable components. Sometime they are
called as modules which integrate to satisfy the problem requirements.

 Modularity is the single attribute of a software that permits a program to be managed easily.

 Monolithic software (i.e., a large program composed of a single module) cannot be easily grasped
by a software engineer.
 Control paths, span of reference, number of variables,
 Information Hiding
 “How do I decompose a software solution to obtain the best set of modules?
 The principle of information hiding suggest that modules be “characterized by design decisions
that (each) hides from all others.
 Hiding implies that effective modularity can be achieved by defining a set of independent
modules that communicate with one another only that information necessary to achieve
software function.

 Functional Independence
 The functional independence is the concept of separation and related to the concept
of modularity, abstraction and information hiding.

 The functional independence is accessed using two criteria i.e Cohesion and coupling.

 Cohesion is an indication of the relative functional strength of a module.

 A cohesive module performs a single task and it requires a small interaction
with the other components in other parts of the program.

 Coupling is an indication of the relative interdependence among modules

 Refinement
 Refinement is a top-down design approach.

 It is a process of elaboration.

 A program is established for refining levels of procedural details.

 elaborate on the original statement, providing more and more detail as each
successive refinement (elaboration) occurs.

 A hierarchy is established by decomposing a statement of  function in a stepwise

manner till the programming language statement are reached.
 Aspects
 As requirements analysis occurs, a set of “concerns” is uncovered. These concerns
“include requirements, use cases, features, data structures, quality of-service issues,
variants, intellectual property boundaries, collaborations, patterns and contracts”.
 Refactoring
 It is a reorganization technique which simplifies the design of components without changing its
function behavior.
 Refactoring is the process of changing the software system in a way that it does not change the
external behavior of the code still improves its internal structure.
 When software is refactored,
 The existing design is examined for redundancy, unused design elements, inefficient or unnecessary
algorithms, poorly constructed or inappropriate data structures, or any other design failure that can be c
 orrected to yield a better design.
 Object-Oriented Design Concepts
 OO design concepts such as classes and objects, inheritance, messages, and polymorphism,
among others.
 Design Classes
 The model of software is defined as a set of design classes.
 Every class describes the elements of problem domain and that focus on features of
the problem which are user visible.
 Will be define
 Design classes
 User Interface Classes
 Persistent Classes
 System Classes
 Dependency Inversion
 Design for Test
The Design Model
Requirements Engineering

 Why is it important?
 Designing and building an elegant computer program
 Designing and building computer software is challenging, creative, and just plain fun.
 It solves the wrong problem serves
 That’s why it’s important to understand what the customer wants before you begin to design and build
a computer-based system
 What are the steps?
 Inception (a task that defines the scope and nature of the problem to be solved).
 Elicitation (a task that helps stakeholders define what is required)
 Elaboration (where basic requirements are refined and modified).
 Negotiation (what are the priorities, what is essential, when is it required?)
 Specification (the problem is specified in some manner and then
 Reviewed or validated (to ensure that your understanding of the problem and the stakeholders’
understanding of the problem happen together)
 Management (Requirement management).
Requirements Engineering (Inception)

 Inception (start)
 a task that defines the scope and nature of the problem to be solved
 RE asks a set of questions to establish
 a basic understanding of the problem
 The people who want a solution
 The nature of the solution that is desired,
 the effectiveness of preliminary communication and collaboration between the other stakeholders and
the software team.

 Question set 1:
 Theses questions focus on the customers, other stakeholders, the overall goals, and the benefits
 Who is behind the request for this work?
 Who will use the solution?
 What will be the economic benefit of a successful solution?
 Is there another source for the solution that you need?
Requirements Engineering (Inception)

 Question set 2:
 To gain a better understanding of the problems and allow the customer to voice his/her
perceptions about a solution
 How would you characterize "good" output that would be generated by a successful solution?
 What problem(s) will this solution address?
 Can you show me (or describe) the business environment in which the solution will be used?
 Will special performance issues or constraints affect the way the solution is approached?
 Question set 3:
 Effectiveness of the communication activity itself
 Are you the right person to answer these questions? Are your answers "official"?
 Are my questions relevant to the problem that you have?
 Am I asking too many questions?
 Can anyone else provide additional information?
 Should I be asking you anything else?
Requirements Engineering (Inception)

 Based on these questions, the RE gets the knowledge

 Identify the stakeholders
 Recognize multiple viewpoints
 Work towards collaboration
 Break the ice and initiate the communication
Requirements Engineering (Elicitation)

 Elicitation
 Gathers requirements form stakeholders and establish business goals
 what the objectives for the system or product are
 what is to be accomplished
 how the system or product fits into the needs of the business,
 finally, how the system or product is to be used on a day-to-day basis.

 Elicitation is to establish business goals but it is difficult

 Problem of scope (The boundary of the system is ill-defined)
 Problem of Understanding ( The customers/users are not completely sure of what is needed)
 Problem of volatility or instability (requirements change over)

 To help overcame these problem, requirement engineers ,must approach the requirement
gathering activity in an organized manner
Requirements Engineering (Elicitation)

 Process guidelines
 Conduct meetings between both customers and software engineers
 Rules for preparation and participation are established
 Agenda is suggested
 a "facilitator" (can be a customer, a developer, or an outsider) controls the meeting
 a "definition mechanism" (can be work sheets, flipcharts, or wall stickers or an electronic
bulletin board, chat room or virtual forum) is used
 The goal is
 To identify the problem
 propose elements of the solution
 negotiate different approaches, and specify a preliminary set of solution requirements
Requirements Engineering (Elaboration)

 Elaboration

 The information obtained from the customer during inception and elicitation is expanded and
refined during elaboration.

 Expand requirement into analysis model

 It identifies information, function and behavioral requirements.

 Elaboration is driven by the creation and refinement of user scenarios that describe how the end
user (and other actors) will interact with the system
Requirements Engineering (Negotiation)

 Negotiation
 Agree on a deliverable system that is realistic (Reasonable) for developers and customers.
 SW team & other project stakeholders negotiate the priority, availability, and cost of each
requirement
 The process are
 Identify the key stakeholders
 These are the people who will be involved in the negotiation

 – Determine each of the stakeholders “win conditions”

 Negotiate
 Important key points
 Recognize that it is not competition
 Map out a strategy
 Listen actively and focus on other party interests
 Don’t let it get persona
 Be creative and ready to commit
Requirements Engineering (Specification)

 Specification
 Final work product produced by requirement engineer
 Specification means different things to different people. It can be any one(or more)of the
following:
 A written document
 A set of models
 A formal mathematical
 A collection of user scenarios (use-cases)
 A prototype
 Requirements and specification both are equal
 Requirement : understanding between customer and supplier
 Specification – what the software must do
 SRS contains : costs, delivery date, acceptance procedures, etc.
Requirements Engineering (Validation)

 Validation
 a review mechanism that looks for errors in content or interpretation areas where clarification
may be required.
 Conflicting or unrealistic (unachievable) requirements
 Consistent
 Missing information
 Requirements validation examines the specification to ensure that all software requirements
have been stated unambiguously; that inconsistencies, omissions, and errors have been
detected and corrected;
 Validation vs verification
Requirements Engineering (Management)

 Requirement Management
 Requirements for computer-based systems change, and the desire to change requirements
persists throughout the life of the system.
 Requirements management is a set of activities that help the project team identify, control, and
track requirements and changes to requirements at any time as the project proceeds.
Establishing the Groundwork

 It’s a starting of (SR- inception) The steps required to establish the groundwork for An
understanding of software requirements.

 Requirements engineering is simply a matter of conducting meaningful conversations with

colleagues who are well-known members of the team.

 Problem is they are located in different areas (requirement engineers or customers or end users).
 It lead to
 Limited time interaction

 Limited technical knowledge to understand the requirements

Establishing the Groundwork

 To resolve these issues groundwork has been established in the following manner:
 Identifying Stakeholders

 Recognizing Multiple Viewpoints

 Working towards Collaboration

 Asking the First Questions

 Nonfunctional Requirements

 Traceability
Establishing the Groundwork

 Identifying Stakeholders
 Sommer ville and Sawyer [Som97] define a stakeholder as “anyone who benefits in a direct or
indirect way from the system which is being developed.”
 Example:
 Business operations managers and Product managers
 Marketing people and Internal and external customers
 End users and Consultants
 Product engineers and Software engineers
 Support and maintenance engineers, and others

 Each stakeholder has a different view of the system, achieves different benefits, and is open to
different risks if the development effort should fail.
Establishing the Groundwork

 Recognizing Multiple Viewpoints

 Because many different stakeholders exist, the requirements of the system will be explored from many different
points of view.
 Example:
 Product functionalities and features
 Easy and sell
 Budget
 Familiar features and easy to use

 Each of these communities will contribute information to the requirements engineering process. As information
from multiple viewpoints is collected, emerging requirements may be inconsistent or may conflict with one
another.

 You should categorize all stakeholder information (including inconsistent and conflicting requirements) in a way
that will allow decision makers to choose an internally consistent set of requirements for the system.

 Note: The goal of effective requirements engineering is to eliminate or

at least reduce these problems.
Establishing the Groundwork

 Working toward Collaboration

 If five stakeholders are involved (collaboration) in a software project, you may have five (or
more) different opinions about.
 the proper set of requirements
 Customers (and other stakeholders) must collaborate among themselves (avoiding petty
turf battles) and with software engineering practitioners if a successful system is to result.

 How is this collaboration accomplished?

 The job of a requirements engineer is to identify areas of commonality and areas of conflict
or inconsistency

Note: Collaboration does not necessarily mean that requirements are defined by committee.
Establishing the Groundwork

 Asking the First Questions

 RE asks a set of context-free questions to establish
 a basic understanding of the problem
 The people who want a solution
 The nature of the solution that is desired,
 the effectiveness of preliminary communication and collaboration between the other stakeholders and
the software team.
 Question set 1:
 Theses questions focus on the customers, other stakeholders, the overall goals, and the benefits
 Who is behind the request for this work?
 Who will use the solution?
 What will be the economic benefit of a successful solution?
 Is there another source for the solution that you need?
Establishing the Groundwork

 Question set 2:
 To gain a better understanding of the problems and allow the customer to voice his or her
perceptions about a solution
 How would you characterize "good" output that would be generated by a successful solution?
 What problem(s) will this solution address?
 Can you show me (or describe) the business environment in which the solution will be used?
 Will special performance issues or constraints affect the way the solution is approached?
 Question set 3:
 Effectiveness of the communication activity itself
 Are you the right person to answer these questions? Are your answers "official"?
 Are my questions relevant to the problem that you have?
 Am I asking too many questions?
 Can anyone else provide additional information?
 Should I be asking you anything else?
Establishing the Groundwork

 Based on these questions, the RE gets the knowledge

 Identify the stakeholders
 Recognize multiple viewpoints
 Work towards collaboration
 Break the ice and initiate the communication
Establishing the Groundwork

 Nonfunctional Requirements
 Related to emerged properties or constraints
 Emerged properties are
 Reliability
 Response time
 Storage, etc.
 Constrains are
 I/O device capability
 Data representation
 Standards
 A security attributes A general constraint, etc.
 Non-functional requirements are more critical than functional requirements
 If these are all not met, the system is useless
Establishing the Groundwork

 Traceability
 That refers to documented links between software engineering work products.
 A traceability matrix allows a requirements engineer to represent the relationship between
requirements and other software engineering work products
 Create traceability matrix, to create
 Business Requirements.
 Software Requirements Specification Document (SRS)
 Project Requirement Documents (PRD)
 Use Case Document.
 Defect Verification Document.
 User Stories
Unit II - Requirements Engineering

 REQUIREMENTS ENGINEERING
19/July/2021
 Requirements Engineering
 Establishing the Groundwork
 Eliciting Requirements 20/July/2021
 Building the Requirements Model
 Requirements analysis
 METRICS IN THE PROCESS AND PROJECT DOMAINS 21/July/2021
 Domains – Software Measurements - Metrics for Software Quality -
 Software Project Estimation - Decomposition Techniques Empirical Estimation Models -
The Make/Buy Decision.
Eliciting Requirement

 Eliciting Requirement
 Requirements elicitation (also called requirements gathering)

 Combines, elements of problem solving, elaboration, negotiation, and specification.

 To encourage a collaborative and team-oriented approach to

 Requirements gathering

 Stakeholders work together to identify the problem

 Propose elements of the solution

 Negotiate different approaches, and

 Specify a preliminary set of solution requirements

Eliciting Requirement

 Activities involved in Eliciting Requirements

 Collaborative Requirements Gathering

 Quality Function Deployment

 Usage Scenarios

 Elicitation work Products

 Agile Requirements Elicitation

 Service Oriented Methods

Eliciting Requirement

 Collaborative Requirements Gathering (CRG)

 Support of many Different approaches the CRG have been developed.

 With slight differences, the variations with support of following basic guidelines

 Meetings (either real or virtual) are conducted and attended by both software engineers and other stakeholders.

 Rules for preparation and participation are established.

 An agenda is suggested that is formal enough to cover all important points but informal enough to encourage the free
flow of ideas.

 A “facilitator” (can be a customer, a developer, or an outsider) controls the meeting.

 A “definition mechanism” (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room, or
virtual forum) is used.
Eliciting Requirement

 The CRG Goal is

 to identify the problems,
 propose elements of solution,
 negotiate different approaches,
 and specify the preliminary set of solution requirements.

 Finding Solution for

 Can we build the system?
 Will this development process allow us to beat our competitors to market?
 Do adequate resources exist to build and maintain the proposed system?
 Will the system performance meet the needs of our customers?
Eliciting Requirement

 Quality Function Deployment

 Quality function deployment (QFD) is a quality management technique
 Translates the needs of the customer into technical requirements for software.
 concentrates on maximizing customer satisfaction from the software engineering process
 3 - Context of QFD is
 normal requirements
 Expected requirements
 Exciting requirements
 QFD uses
 customer interviews and observation,
 Surveys
 examination of historical data (e.g., problem reports) as raw data for the requirements gathering activity.
 These information are converted into Customer Voice Table
Eliciting Requirement

 Customer voice table helps to review the Quality of Product with customers and other
stakeholders
 For extraction and to attempt to derive exciting requirements
 variety of diagrams, matrices, and evaluation methods
Eliciting Requirement

 Usage Scenarios or Use Cases

 An overall vision of system functions and
features are identified

 How to involve these functions and features

in different class of end users

 It helps to identify a thread of usage for the

system to be constructed.

 It called as use cases, it gives the overall

picture about system will be used
Eliciting Requirement

 Elicitation Work Products

 work products produced as a consequence of requirements elicitation will vary depending on
the size of the system or product to be built.
 work products include
 A statement of need and feasibility
 A bounded statement of scope for the system or product
 A list of customers, users, and other stakeholders who participated in requirements elicitation
 A description of the system’s technical environment
 A list of requirements (preferably organized by function) and the domain constraints that applies to
each,
 A set of usage scenarios that provide insight into the use of the system or product
under different operating conditions
 Any prototypes developed to better define requirements
 Each of these work products is reviewed by all people who have participated in requirements
elicitation.
 Agile Requirements Elicitation
 The user stories developed by different stakeholders
 Each user story describes a simple system requirement written from the user’s perspective

 User stories can be written on small note cards,

 it easy for developers to select and manage a subset of requirements to implement for the next product
increment

 Agile approach to requirements elicitation is attractive for many software teams,

 critics argue that a consideration of overall business goals t=and nonfunctional requirements is often
lacking
Eliciting Requirement

 Service-Oriented Methods
 Service-oriented development views a system as an aggregation of services
 A service can be “as simple as providing a single function. e.g. request and response based
mechanism
 service-oriented development focuses on the definition of services to be rendered by an
application
 Example : Visit Hotel
 A doorperson greets guests
 A valet parks their cars
 The desk clerk checks the guests in
 A bellhop manages the bags.
 The concierge assists guest with local arrangements
 Each contact or touchpoint between a guest and a hotel employee is designed to enhance the
hotel visit and represents a service offered.
Eliciting Requirement

 Goal of Service Oriented Method

 Most service design methods emphasize understanding the customer, thinking creatively, and
building solutions quickly
 To achieve this
 Ethnographic studies
 Innovation Work shops
 Early low-fidelity prototypes
Building the Requirements Model

 Building the Analysis Model

 The intent is to provide a description of the required informational, functional, and
behavioral domains for a computer-based system

 The model changes dynamically

 as you learn more about the system to be built, and
 other stakeholders understand more about what they really require.
 the analysis model is a snapshot of requirements at any given time.
 The analysis model evolved with certain elements
 It helps stabilization
Building the Requirements Model

 Elements of Analysis Model

 Scenario-based elements.
 Class-based elements.
 Behavioral elements.
Building the Requirements Model

 Scenario-based elements.
 The system is described from the user’s point of view using a scenario-based approach
 It is a first part of requirement model that is developed
 It serves as input for the creation of other modeling elements
Building the Requirements Model

 Class-based elements
 Each usage scenario implies a set of objects that are manipulated as an
actor interacts with the system
 These objects are categorized into classes
 A collection of things that have similar attributes and common behaviors.
 Attributes (e.g., name, type…)
 Operations (e.g., Identify, enable…)
 Also contains,
 Details about Collaboration with one another
 Relations and interaction between classes
Building the Requirements Model

 Behavioural elements
 The state diagram is one method for representing the behavior of a system by depicting its states
and the events that cause the system to change state.
 A state is any observable mode of behavior
 In addition,
 the state diagram indicates what actions (e.g., process activation) are taken as a consequence of a
particular event.
Building the Requirements Model

 Tools for Requirement model

 IBM Rational Rose
 Azure DevOps
 Cognition Cockpit
Unit II - Requirements Engineering

 REQUIREMENTS ENGINEERING
19/July/2021
 Requirements Engineering
 Establishing the Groundwork
 Eliciting Requirements 20/July/2021
 Building the Requirements Model
 Requirements analysis
 METRICS IN THE PROCESS AND PROJECT DOMAINS 21/July/2021
 Software Measurements
 Metrics for Software Quality
 Software Project Estimation
 Decomposition Techniques Empirical Estimation Models
 The Make/Buy Decision.
Metrics in Process and Project Domain

 What is it?
 Software process and project metrics are quantitative measures that enable you to gain
insight into the efficacy of the software process and the projects that are conducted using
the process as a framework.

 Basic quality and productivity data are collected. These data are then analyzed,
compared against past averages, and assessed to determine whether quality and
productivity improvements have occurred.

 Metrics are also used to pinpoint problem areas so that remedies can be developed and
the software process can be improved.

 Who Does it?

 Software metrics are analysed and assessed by software managers. Measures are often
collected by software engineers.
Metrics in Process and Project Domain

 Why do we Measure?
 To Characterize
 To Evaluate
 To Predict
 To Improve
Metrics in Process and Project Domain

 Measure vs Metrics vs Indicators

 A measure provides a quantitative indication of the extent, amount, dimension,
capacity, or size of some attribute of a product or process.

 A Metrics is a quantitative measure of the degree to which a system, component,

or process possesses a given attribute.

 An indicator is a metric or combination of metrics that provide insight into the

software process, a software project, or the product itself.
 An indicator provides insight that enables the project manager or software
engineers to adjust the process, the project, or the process to make things better.
Metrics in Process and Project Domain

 Process Metrics
 Process metrics are collected across all projects and over long periods of time.

 Their intent is to provide a set of process indicators that lead to long-term and
Continuous basis software process improvement.

 Process indicators
 Enable a software engineering organization to gain insight into the efficacy of an
existing process (I.e., the paradigm, software engineering tasks, work products, and
milestones).

 They enable managers and practitioners to assess what works and what doesn’t.
Metrics in Process and Project Domain

 Process Metrics & Software Process Improvement

 The metrics helps to improve any software process
 Specific attributes are considered
 Provide regular feedback to the individuals and team who collect measures and metrics.

 Process metrics strategy

 Develop set of meaningful metrics based on attributes
 Use the metrics to provide indicators that will lead to a strategy for improvement.
Metrics in Process and Project Domain

 Important Key point

“Is only one of a number of controlling factors in improving software quality and organizational
performance”
 Process connecting three factors
 People
 Technology
 Product
 In addition
 Development environment (integrated software tools)
 Business Conditions (deadlines, business rules)
 Customers Characteristics (ease of communication and collaboration)
Metrics in Process and Project Domain

 A software metrics procedure

 Use common sense an organizational sensitivity when interpreting metrics data

 Provide regular feedback to the individuals and teams who collect measures and metrics

 Don’t use metrics to appraise individuals

 Work with practitioners and teams to set clear goals and metrics that will be used to achieve them

 Never use metrics to threaten individuals or teams

 Metrics data that indicate a problem area should not be considered “negative.” These data are merely an
indicator for process improvement.

 Don’t obsess on a single metric to the exclusion of other important metrics

Metrics in Process and Project Domain

 Rigorous approach: statistical software process improvement (SSPI):

 All errors and defects are categorized by origin

 The cost to correct each error and defect is recorded

 The number of errors and defects in each category is counted and ranked in descending order

 The overall cost of errors and defects in each category is computed

 Resultant data are analyzed to uncover the categories that result in the highest cost to the
organization

 Plans are developed to modify the process with the intent of eliminating (or reducing the frequency
of) the class of errors and defects that is most costly
Metrics in Process and Project Domain

 Project Metrics
 Project metrics are used by a project manager and a software team to adapt project work flow
and technical activities.

 Measurement can be used throughout a software project to assist in estimation, quality control,
productivity assessment, and project control.

 Intent of project metrics

 to minimize the development schedule by making the adjustments necessary to avoid delays and
mitigate potential problems
 to assess product quality on an ongoing basis and, when necessary, modify the technical
approach to improve quality
Metrics in Process and Project Domain

 Another model of project metrics suggests that every project should measure
 Inputs – measures of the resources required to do the work

 Outputs – measures of the deliverables or work products created during the software
engineering process

 Results – measures that indicate the effectiveness of the deliverables

Metrics in Process and Project Domain

 Project Indicators enable a software project manager to

 Assess the status of an ongoing project,

 Track potential risks,

 Uncover problem areas before they go “critical,”

 Adjust work flow or tasks, and

 Evaluate the project team’s ability to control quality of software work products
Software Measurements

 Measurements categories
 Direct Measure
 Direct measures of the Software Engineering Process include lines of code (LOC)
produced, execution speed, memory size, and defects reported over some set
period of time.
 Easy to collect, as long as

 Indirect Measure
 Indirect measures of the product include functionality, quality, complexity,
efficiency, reliability, maintainability, and many other “–abilities”
 Difficult to collect
Software Measurements

 Size-Oriented Metrics
 Function-Oriented Metrics
 Reconciling LOC and FP Metrics
 Object-Oriented Metrics
 Use Case-Oriented Metrics
 WebApp Project Metrics
Software Measurements

 Size-oriented software metrics are derived by normalizing quality and/or

productivity measures by considering the size of the software that has been produced.

 Example Line of Code (LOC)

 Effort & cost : analysis, design, code and test (SE activities)
Software Measurements

 Lines of Code as a normalization value

 A set of simple size-oriented metrics can be developed for each project:

 Errors per KLOC (thousand lines of code)
 Defects per KLOC
 $ per KLOC
 Pages of documentation per KLOC

 In addition,
 Errors per person-month
 KLOC per person-month
 $ per page of documentation
Software Measurements

 While counting lines of code, simplest standard is:

 Don’t count blank lines
 Don’t count comments
 Count everything else
 The size-oriented measure is not a universally accepted method.

 Simple set of size measure that can be developed

 Size = Kilo Lines of Code (KLOC)
 Effort = Person / month
 Productivity = KLOC / person-month
 Quality = Number of faults / KLOC
 Cost = $ / KLOC
 Documentation = Pages of documentation / KL
Software Measurements

 Function-Oriented Metrics
 Function-oriented software metrics use a measure of the functionality delivered
by the application as a normalization value.

 These methods are actually independent of the programming language that is

being used in software applications and based on calculating the Function Point
(FP).

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

(direct) measures of software's information domain and assessments of software
complexity.
Software Measurements

 Function Point Calculation

Software Measurements

 The Fi (i = 1 to 14) are "complexity adjustment values" based on responses to the

following questions :
1. Does the system require reliable backup and recovery?
2. Are data communications required?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational environment?
6. Does the system require on-line data entry?
7. Does the on-line data entry require the input transaction to be built over multiple
screens or operations?
8. Are the master files updated on-line?
9. Are the inputs, outputs, files, or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different organizations?
14. Is the application designed to facilitate change and ease of use by the user?
Software Measurements

 After calculating the function point, various other measures can be calculated as shown
below :

 Productivity = FP / person-month
 Quality = Number of faults / FP
 Cost = $ / FP
 Documentation = Pages of documentation / FP
Software Measurements

 Object-Oriented Metrics
 Conventional software project metrics (LOC or FP) can be used to estimate object-
oriented software projects

 These metrics are not appropriate in the case of incremental software development as
they do not provide adequate details for effort and schedule estimation.
Software Measurements

 Thus, for object-oriented projects, different sets of metrics have been proposed. 
 Number of scenario scripts
 Number of key classes
 Number of support classes
 Average number of support classes per key class
 Number of subsystems
Software Measurements

 Number of scenario scripts

 A scenario script (analogous to a use case) is a detailed sequence of steps that
describes the interaction between the user and the application.
 Each script is organized into triplets of the form.

{initiator, action, participant}

Software Measurements

 Number of key classes

 Key classes are the “highly independent components” that are defined early in
object-oriented analysis

 Because key classes are central to the problem domain, the number of such classes
is an indication of the amount of effort required to develop the software and also an
indication of the potential amount of reuse to be applied during system development.
Software Measurements

 Number of support classes

 Support classes are required to implement the system but are not immediately related to
the problem domain

 Examples might be user interface (UI) classes, database access and manipulation classes,
and computation classes

 support classes can be developed for each of the key classes.

 Support classes are defined iteratively throughout an evolutionary process

 The number of support classes is an indication of the amount of effort required to develop
the software and also an indication of the potential amount of reuse to be applied during
system development
Software Measurements

 Average number of support classes per key class

 Key classes are defined early in the software project while support classes are defined
throughout the project.

 The estimation process is simplified if the average number of support classes per key
class is already known.
Software Measurements

 Number of subsystems
 A collection of classes that supports a function visible to the user is known as a
subsystem

 Identifying subsystems makes it easier to prepare a reasonable schedule in which

work on subsystems is divided among project members.
Software Measurements

 Use Case-Oriented Metrics

 Describe (indirectly) user-visible functions and features in language independent
manner
 Number of use case is directly proportional to LOC size of application and number of
test cases needed
 However use cases do not come in standard sizes and use as a normalization measure
is suspect
 Use case points have been suggested as a mechanism for estimating effort
Software Measurements

 WebApp Project Metrics

 Number of static Web pages (Nsp)
 Number of dynamic Web pages (Ndp)
 Customization index: C = Nsp/ (Ndp+ Nsp)
 Number of internal page links
 Number of persistent data objects
 Number of external systems interfaced
 Number of static content objects
 Number of dynamic content objects
 Number of executable functions
Unit II - Requirements Engineering

 REQUIREMENTS ENGINEERING
19/July/2021
 Requirements Engineering
 Establishing the Groundwork
 Eliciting Requirements 20/July/2021
 Building the Requirements Model
 Requirements analysis
 METRICS IN THE PROCESS AND PROJECT DOMAINS 21/July/2021
 Software Measurements
 Metrics for Software Quality 22/July/2021
 Software Project Estimation
 Decomposition Techniques
 Empirical Estimation Models
 The Make/Buy Decision.
Metrics for Software Quality

 Software is a complex entity. Therefore, errors are to be expected as work products are developed.
Process metrics are intended to improve the software process so that errors are uncovered in the
most effective manner

 The quality of a system, application, or product is only as good as

 the requirements that describe the problem

 the design that models the solution

 the code that leads to an executable program

 the tests that exercise the software to uncover errors

Metrics for Software Quality

 METRICS FOR SOFTWARE QUALITY

 You can use measurement

 to assess the quality of the requirements and design models

 the source code : Line of Code

 the test cases that have been created as the software is engineered.

 To accomplish this real-time assessment, you apply product metrics to evaluate the quality of
software engineering work products in objective, rather than subjective ways.
Metrics for Software Quality

 METRICS FOR SOFTWARE QUALITY (Cont.)

 Project manager evaluate quality as the project processes.

 Project manager collecting private metrics from every individual software engineers and
combine to provide the project-level results.
 Also many quality measurements are observed but the primary measurement is error
and defect.
 Example
 work product errors per function point
 errors uncovered per review hour
 Errors uncovered per testing hour
 Error data can also be used to compute the defect removal efficiency (DRE)
Metrics for Software Quality

 Measuring Quality
 Among many measures, few measures of software quality is listed here:
 Correctness :
 Maintainability
 Integrity
 Usability
 Anything else?
 Code quality
 Performance
 Security
 Reliability
Metrics for Software Quality

 Measuring Quality (Cont.)

 Correctness
 Correctness is the degree to which the software performs its required function.

 Defects (lack of correctness) are those problems reported by a user of the program after the
program has been released for general use.

 In quality assessment purpose, defects are counted over a standard period of time, typically
one year.

 The most common measure for correctness is defects per KLOC

 where a defect is defined as a verified lack of conformance to requirements.

Metrics for Software Quality

 Measuring Quality (Cont.)

 Maintainability
 Maintainability is the ease with
 which a program can be corrected if an error is encountered
 adapted if its environment changes, or
 enhanced if the customer desires a change in requirements.
 There is no way to measure maintainability directly;
 Therefore, we must use indirect measures.
 A simple time-oriented metric is mean-time-to-change (MTTC), the time it takes to
 Analyze the change request,
 Design an appropriate modification,
 Implement the change,
 Test it, and
 Distribute the change to all users.
Metrics for Software Quality

 Measuring Quality (Cont.)

 Integrity
 This attribute measures a system’s ability to withstand attacks (both accidental and
intentional) to its security.

 To measure integrity, two additional attributes must be defined: threat and security.

 Threat: is the probability (which can be estimated or derived from empirical evidence) that an
attack of a specific type will occur within a given time.

 Security: is the probability (which can be estimated or derived from empirical evidence) that
the attack of a specific type will be repelled

 Integrity =
Metrics for Software Quality

 Measuring Quality (Cont.)

 Usability:
 Usability is an attempt to quantify ease of use and can be measured in terms of the
characteristics
 Place the user in control.
 Reduce the user’s memory load
 Make the interface consistent
Metrics for Software Quality

 Defect Removal Efficiency (DRE)

 A quality metric that provides benefit at both the project and process level is defect removal
efficiency (DRE)
 DRE is a measure of the filtering ability of quality assurance and control actions as they are
applied throughout all process framework activities.
 DRE is defined in the following manner for project level:

 Where E, No. of errors found before delivery

D, No of errors found after delivery
 DRE for Process Level:

 Where,
errors are not discovered in action
Software Project Estimation

 Software Project Estimation

 Software cost and effort estimation is not a science
 Due to some technical and technical variables affects the ultimate cost of software and development
efforts:
 Human resource
 Technical (design, code, and test)
 Environmental
 Political
 series of systematic steps that provide estimates with acceptable risk
 Delay estimation until late in the project
 Base estimates on similar projects that have already been completed.
 Use relatively simple decomposition techniques to generate project cost and effort estimates.
 Use one or more empirical models for software cost and effort estimation
 Software Project Estimation (Cont.)