SOFTWARE

ENGINEERING
MINOR DEGREE
 PROCESS METRICS
 Process Metrics are the measures of the development process that creates a body of software
 example of a process metric is the length of time that the process of software creation tasks
 ISO- 9000 certification, or “Quality Management Standards “- International Standard Organization (ISO).
 Process metrics are often collected as part of a model of software development- Boehm’s COCOMO (Constructive Cost
Model) make cost estimations for software projects.
 Types of Process Metrics
 Static Process Metrics: Static Process Metrics are directly related to the defined process. Ex:- the number of types of
roles, types of artifacts, etc.
 Dynamic Process Metrics: Dynamic Process Metrics are simply related to the properties of process performance. Ex:-
how many activities are performed, how many artifacts are created, etc.
 Process Evolution Metrics: Process Evolution Metrics are related to the process of making changes over a period of
time. Ex:- how many iterations are there within the process.
 PROCESS DOMAINS
 People, Process, and Business Environment are the three project domains.(PMP)
 These PMP domains are crucial for effective project management as they provide a comprehensive framework to address
project managers’ diverse challenges and responsibilities.
 People -The People domain of PMP emphasizes the human side of project management.
 It involves understanding and managing interpersonal relationships, leadership, team dynamics, and stakeholder
engagement.
 effective communication, motivation, and conflict resolution within the project team create a positive and productive work
environment, which results in improved team morale.
 Process- Process management is at the core of project execution.
 It covers the technical aspects of project management, such as project planning, execution, monitoring, controlling,
and closing.
 Business Environment- This domain focuses on the broader organizational context in which projects operate.
 It involves understanding the strategic alignment of projects with corporate goals, considering regulatory and legal
factors, and managing external influences such as market conditions and industry trends.
 SOFTWARE MEASUREMENT
 Measurement is a manifestation of the size, quantity, amount, or dimension of a particular attribute of a product or process.
 The software measurement process is defined and governed by ISO Standard.
 Need for Software Measurement:
 Create the quality of the current product or process.
 Anticipate future qualities of the product or process.
 Enhance the quality of a product or process.
 Regulate the state of the project concerning budget and schedule.
 Enable data-driven decision-making in project planning and control.
 Identify bottlenecks and areas for improvement to drive process improvement activities.
 Ensure that industry standards and regulations are followed.
 Give software products and processes a quantitative basis for evaluation.
 Enable the ongoing improvement of software development practices.
 SOFTWARE MEASUREMENT
 Software Measurement Principles:
 Formulation: The derivation of software measures and metrics appropriate for the representation of the software that is being
considered.
 Collection: The mechanism used to accumulate data required to derive the formulated metrics.
 Analysis: The computation of metrics and the application of mathematical tools.
 Interpretation: The evaluation of metrics results in insight into the quality of the representation.
 Feedback: Recommendation derived from the interpretation of product metrics transmitted to the software team.
 Classification of Software Measurement:
 Direct Measurement: In direct measurement, the product, process, or thing is measured directly using a standard scale.
 Indirect Measurement: In indirect measurement, the quantity or quality to be measured is measured using related parameters
i.e. by use of reference.
 SOFTWARE MEASUREMENT
 Software Metrics:
 A metric is a measurement of the level at which any impute belongs to a system product or process.
 Software metrics is a quantifiable or countable assessment of the attributes of a software product. There are 4 functions related
to software metrics:
 Planning, Organizing, Controlling, Improving
 Characteristics of software Metrics:
 Quantitative: Metrics must possess quantitative nature. It means metrics can be expressed in numerical values.
 Understandable: Metric computation should be easily understood, and the method of computing metrics should be clearly
defined.
 Applicability: Metrics should be applicable in the initial phases of the development of the software.
 Repeatable: When measured repeatedly, the metric values should be the same and consistent in nature.
 Economical: The computation of metrics should be economical.
 Language Independent: Metrics should not depend on any programming language.
 METRICS FOR SOFTWARE QUALITY
 Software Quality Metrics
 Classification of Software Metrics:
 Product Metrics: Product metrics are used to evaluate the state of the product, tracing risks and undercover prospective problem
areas.
 The ability of the team to control quality is evaluated.
 Examples include lines of code, cyclomatic complexity, code coverage, defect density, and code maintainability index.
 Process Metrics: Process metrics pay particular attention to enhancing the long-term process of the team or organization.
 These metrics are used to optimize the development process and maintenance activities of software.
 Examples include effort variance, schedule variance, defect injection rate, and lead time.
 Project Metrics: The project metrics describes the characteristic and execution of a project.
 Examples include effort estimation accuracy, schedule deviation, cost variance, and productivity.
 Usually measures-

 Number of software developer

 Staffing patterns over the life cycle of software
 Cost and schedule
 INTEGRATING METRICS WITH
PROCESS
 Arguments for Software Metrics
 important to measure the process of software engineering and the product (software) that it produces.
 There is no real way of determining whether improving. And if not improving means lost the result

 Establishing a Baseline
 By establishing a metrics baseline, benefits can be obtained at the process, project, and product (technical) levels.
 The metrics base- line consists of data collected from past software development projects and can be simple or as complex
as a comprehensive data- base containing dozens of project measures and the metrics derived from them.
 baseline data must have the following attributes:
 (1) data must be reasonably accurate -can metrics about past projects are to be avoided
 (2) data should be collected for as many projects as possible
 (3) measures must be consistent

 Metrics Collection, Computation, and Evaluation

 ITEGRATING METRICS WITH PROCESS
 Advantages of Software Review
 Defects can be identified earlier stage of development (especially in formal review).
 Earlier inspection also reduces the maintenance cost of software.
 It can be used to train technical authors.
 It can be used to remove process inadequacies that encourage defects.
 Types of Software Reviews
 Software Peer Review
 Peer review is the process of assessing the technical content and quality of the product and it is usually conducted by the author of the
work product along with some other developers.

 Peer review is performed in order to examine or resolve the defects in the software, whose quality is also checked by other members of the
team.
 peer Review has following types- Code Review, Pair Programming, Walkthrough, Technical Review, Inspection
 Software Management Review
 Software Management Review evaluates the work status. In this section decisions regarding downstream activities are taken.
 Software Audit Review
 Software Audit Review is a type of external review in which one or more critics, who are not a part of the development team, organize an
independent inspection of the software product and its processes to assess their compliance with stated specifications and standards. This
is done by managerial level people.
 SOFTWARE QUALITY -CONCEPTS
 Software Quality shows how good and reliable a product is
 It performs all functions as laid out in the SRS document
Portability
Usability
Reusability
Correctness
Maintainability
Reliability
Efficiency
 SOFTWARE REVIEWS
 Software Review is a systematic inspection of software by one or more individuals who work together to find and resolve errors
and defects in the software during the early stages of the Software Development Life Cycle (SDLC).
 Objectives of Software Review
 To improve the productivity of the development team.
 To make the testing process time and cost-effective.
 To make the final software with fewer defects.
 To eliminate the inadequacies
 Process of Software Review
 Entry Evaluation: By confirming documentation, fulfilling entry requirements and assessing stakeholder and team
preparation, you can determine the software’s availability.
 Management Preparation: To get ready for the review process, assign roles, gather resources and provide brief
management.
 Review Planning: Establish the review’s goals and scope, invite relevant parties and set a time for the meeting.
 Preparation: Distribute appropriate resources, give reviewers time to get familiar and promote issue identification to help
them prepare.
 Examination and Exit Evaluation: Reviewers should collaborate to examine the results, record concerns, and encourage
candid communication in meetings. It assess the results, make remedial plans based on flaws that have been reported and
 FORMAL TECHNICAL REVIEWS
 Formal Technical Review (FTR) is a software quality control activity performed by software engineers.
 Finding flaws, making sure standards are followed, and improving the product or document under review’s overall quality are
the main objectives of a fault tolerance review (FTR).
 Objectives of formal technical review (FTR)
 Detect Identification: Identify defects in technical objects by finding and fixing mistakes, inconsistencies, and deviations.
 Quality Assurance: To ensure high-quality deliverables, and confirm compliance with project specifications and standards.
 Risk Mitigation: To stop risks from getting worse, proactively identify and manage possible threats.
 Knowledge Sharing: Encourage team members to work together and build a common knowledge base.
 Consistency and Compliance: Verify that all procedures, coding standards, and policies are followed.
 Learning and Training: Give team members the chance to improve their abilities through learning opportunities.

ELEMENTS OF SOFTWARE QUALITY ASSURANCE
Software Quality Assurance (SQA)
 Set of activities for ensuring quality in software engineering processes.
 Ongoing process within the SDLC that routinely checks the developed software to ensure it meets the
desired quality measures.
 Software quality assurances focus on
 Standards- IEEE, ISO
 Reviews ( Uncover errors) and audits (Followed guidelines or not)
 Testing - testing is properly and efficient conducted(to find errors)
 Error/defect collection and analysis
 Change management
 Education - to improve its software engineering practices
 Vendor management - vendors–shrink–wrapped packages (e.g., Microsoft Office)
 Security management – protect data
 Safety - assessing the impact of software failure to reduce risk.
 Risk management - risk management activities are properly conducted
  FORMAL APPROACHES TO SQA
 Software Quality Assurance (SQA) Encompasses
 A quality management approach.
 Effective software engineering technology (methods and tools).
 Some formal technical reviews are applied throughout the software process.
 A multi-tiered testing strategy.
 Controlling software documentation and the changes made to it.
 Procedure to ensure compliance with software development standards (when applicable).
 Measurement and reporting mechanisms.

Quality management system models under which the software system is created is normally based:
CMMI, Six Sigma, ISO 9000
Software Quality Assurance (SQA) Activities
 The software engineers who do technical work.
 SQA group that has responsibility for quality assurance planning, oversight, record keeping, analysis, and reporting.
SQA group is to identify documents and to track deviations from the process and verify that corrections have been made.
 The SQA group reviews selected work products; identifies, documents, and tracks deviations.
 Verifies that corrections have been made.
 Periodically reports the results of its work to the project manager.
Requirement
SQA TASKS
quality - correctness, completeness, and consistency of the requirements
model
Design quality - to ensure that it exhibits high quality and that the design itself conforms
to requirements
Code quality
Quality control effectiveness- apply limited resources in a way that has the highest likelihood of achieving
a high–quality result

SOFTWARE
RELIABILITY
Software Reliability means Operational reliability-Ability of a system or component to perform its required
functions under static conditions for a specific period .
Probability that a software system fulfills its assigned task in a given environment for a predefined number of
input cases
Essential connect of software quality- Composed with various factors.
hard to achieve because the complexity of software turn to be high
International
ISO 9000 QUALITY STANDARDS
standards organization (ISO) is a standard which serves as a for contract between independent parties.
It specifies guidelines for development of quality system.
Quality system of an organization means the various activities related to its products or services.

Features of ISO 9001 Requirements

  SQA PLAN
 Software Quality Assurance Plan revolves around making sure that the product or service teaches the market trouble and bug-
free.
 The purpose of an SAQ plan is three-fold.
 Establishing the QA responsibilities of the team in question
 Listing areas of concern that need to be reviewed, audited and looked at
 Identifies the SQA work products
 SQA activities
 Creating the plan
 Checkpoint lists
 Executing formal technical reviews
 Multi-testing strategy
 Process adherence
 Control changes
 Measuring Change Impact
 SQA Audits
 Record and report keeping
 Relationship management
 STRATAGIC APPROACH
Testing is a set of activities that can be planned in advance and conducted systematically. Testing strategy Should have the
following characteristics:
usage of Formal Technical reviews (FTR)
Begins at component level and covers entire system
Different techniques at different points
 conducted by developer and test group
should include debugging

Software testing is one element of verification and validation

 STRATAGIC ISSUES
Specify product requirements in a quantifiable manner long before testing commences
State testing objectives explicitly
Understand the users of the software and develop a profile for each user category.
 Develop a testing plan that emphasizes “rapid cycle testing.
 Build “robust” software that is designed to test itself.
 Use effective technical reviews as a filter prior to testing.
 Conduct technical reviews to assess the test strategy and test cases themselves
 Develop a continuous improvement approach for the testing process.
 TEST STRATAGIES FOR CONVENTIONAL SOFTWARE
1. Unit Testing
2. Integration Testing
3. Validation Testing
4. System Testing
 TEST STRATAGIES FOR OO SOFTWARE
1. Unit Testing in the OO Context
 An encapsulated class is usually the focus of unit testing.
 Class testing for OO software
2.Integration Testing in the OO Context
Different strategies for integration testing of OO systems.
 Thread-based testing
 use-based testing
 Cluster testing
3.Cluster testing
VALIDATION TESTING
 SYSTEM TESTING
 System Testing Process: System Testing is performed in the following steps:
 Test Environment Setup: Create testing environment for the better quality testing.
 Create Test Case: Generate test case for the testing process.
 Create Test Data: Generate the data that is to be tested.
 Execute Test Case: After the generation of the test case and the test data, test cases are executed.
 Defect Reporting: Defects in the system are detected.
 Regression Testing: It is carried out to test the side effects of the testing process.
 Log Defects: Defects are fixed in this step.
 Retest: If the test is not successful then again test is performed.
ART OF DEBUGGING
 BLACK BOX TESTING
 1) Graph based testing method:
Object

Link

 2) Equivalence partitioning: This divides the input domain of a program into classes
of data from which test Cases can be derived
Example

Input consists of 1 to 10
Then classes are n<1,1<=n<=10, n>10
 3)Boundary Value analysis
Select input from equivalence classes such that the input lies at the edge of the
equivalence classes.
Example
If 0.0<=x<=1.0
Then test cases are (0.0,1.0) for valid input and (-0.1 and 1.1) for invalid input
 BLACK BOX TESTING
 4)Orthogonal array Testing
 This method is applied to problems in which input domain is relatively small but too large for exhaustive testing
 Example
 Three inputs A, B, C each having three values will require 27 test cases. Orthogonal testing will reduce the number of
test case to 9
 WHITE BOX TESTING
 Basic Path Testing- Proposed by Tom McCabe. Defines a basic set of execution paths based on logical complexity of
a procedural design.
 1. Draw the flow graph from flow chart of the program
 2.Calculate the cyclomatic complexity of the resultant flow graph
 3.Prepare test cases that will force execution of each path
 WHITE BOX TESTING
 2. Control Structure testing- This broadens testing coverage and improves quality of testing.
It uses the following methods:
 a)Condition testing.
 b) Data flow Testing
3. Loop Testing
This focuses on the validity of loop constructs. Four categories can be defined
1. Simple Loops
2. Nested loops
3. Concatenated Loops
4. Unstructured Loops
Testing of simple loops
N is the maximum number of allowable passes through the loop
1.Skip the loop entirely
2.Only one pass through the loop
3.Two passes through the loop
4.m passes through the loop where m>N
5.N-1, N,N+1 passes the loop