Software Engineering Lecture 08 for Emaan Institute

1. Software Engineering
(3+0)
SYED MUHAMMAD RAFI
LECTURER, DEPARTMENT OF COMPUTER SCIENCE
FACULTY OF COMPUTER SCIENCE,
EMAAN INSTITUTE OF MANAGEMENT SCIENCES

2. INTRODUCTION TO
SOFTWARE ENGINEERING
Lecture # 08
SQE, Testing, PM, RM and Maintenance:
Software Engineering: A Practitioner’s Approach
by Roger S. Pressman
Software Engineering
By Ian Sommerville
System Analysis & Design
by Shelly Cashman

3. Topics to be covered
1. An overview of software quality
assurance.
2. Goals, attributes, approaches, types.
3. ISO standard of testing.
4. SQA plan.
5. Testing Strategies
6. Project Management
7. Risk Management
8. Maintenance and Reengineering

4. An overview of Software Quality
Assurance:
 Quality assurance (QA) is the definition of processes and
standards that should lead to high-quality products.
 Quality assurance simply means the definition of
procedures, processes, and standards that are aimed
at ensuring that software quality is achieved.
 It includes all configuration management, verification, and
validation activities that are applied after a product has
been handed over by a development team.
 The QA team in most companies is responsible for
managing the release testing process.
 Quality Assurance is a set of methods and activities
designed to ensure that the developed software
corresponds to all the specifications, e.g., SRS, FRS, and
BRS where as Software Testing is a way of exploring the
system to check how it operates and find the possible

5. Verification vs. Validation
Verification Validation
The process of evaluating products
of a development phase to find out
whether they meet the specified
requirements.
The process of evaluating software
at the end of the development
process to determine whether
software meets the customer
expectations and requirements.
It means “Are we building the
system right?”
It means “Are we building the right
system?”
Following activities are involved in
Verification: Reviews, Meetings
and Inspections.
Following activities are involved in
Validation: Testing like black box
testing, white box testing, gray
box testing etc.
Carried out by QA team. Carried out by Testing team.
Execution of code not comes
under Verification.
Execution of code comes under
Validation.

6. Goals of Testing:
1. Requirements quality. SQA must ensure that the
software team has properly reviewed the requirements
model to achieve a high level of quality.
2. Design quality. Every element of the design model
should be assessed by the software team to ensure that
it exhibits high quality and the design itself conforms to
requirements.
3. Code quality. Source code and related work must
conform to local coding standards and exhibit
characteristics that will facilitate maintainability.
4. Quality control effectiveness. A software team should
apply limited resources in a way that has the highest
likelihood of achieving a high-quality result.

7. Attributes
 Attributes are the indicators for the
existence of quality for each of the goals of
SQA. Goal Attribute
Requirement quality Ambiguity, Completeness,
Understandability, Volatility,
Traceability, Model clarity.
Design quality Architectural integrity,
Component completeness,
Interface complexity, Patterns.
Code quality Complexity, Maintainability,
Understandability
QC effectiveness Reusability, Documentation,
Resource allocation,
Completion rate, Review
effectiveness, Testing
effectiveness.

8. Strategic approach to testing
The following characteristics are the part of strategic approach
to testing:
 To perform effective testing, you should conduct effective
technical reviews. By doing this, many errors will be
eliminated before testing commences.
 Testing begins at the component level and works “outward”
toward the integration of the entire computer-based system.
 Different testing techniques are appropriate for different
software engineering approaches and at different points in
time.
 Testing is conducted by the developer of the software and (for
large projects) an independent test group.
 Testing and debugging are different activities, but debugging
must be accommodated in any testing strategy.

9. Types of Testing
 There are numerous types of testing, the
two main classes of testing are given
below:
A. Technique wise Testing.
B. Level Wise Testing.
 The three main types of Technique
wise testing are:
1. Black box testing.
2. White box testing.
3. Grey box testing.

10. Black box testing:
Here the user is not aware of the
internal implementation of the testing
software. It is common for black box
testers to find bugs that were not traced
during program execution.

11. White box Testing
In white box testing the tester is aware
of the algorithm of the test software and
is able to structure the test cases
accordingly.

12. Grey box Testing
In grey box testing methodology, the
tester has access to internal data
structures and algorithms for purposes
of designing test cases, the testing as
such is done similar to black box
testing.

13. White box vs. Black box
testing
Black Box Testing White Box Testing
It is a way of software testing in
which the internal structure or the
program or the code is hidden and
nothing is known about it.
It is a way of testing the software in
which the tester has knowledge
about the internal structure r the
code or the program of the
software.
It is mostly done by software
testers.
It is mostly done by software
developers.
No knowledge of implementation is
needed.
Knowledge of implementation is
required.
It can be referred as outer or
external software testing.
It is the inner or the internal
software testing.
It is functional test of the software. It is structural test of the software.

14. Levels wise testing types fall under the
Technique wise testing.
1. Unit Level Testing: refers to the testing carried out on small
software units. This is a type of white box testing generally
performed by the code developers.
2. Module level testing: refers to the testing carried out on a
module. This is a type of black box testing generally
performed by the test engineers.
3. Integration level Testing: During the process of
development, lot many modules are developed along with
their respective interfaces, which are used for integrating
these modules. While integration the developers check &
ensure the perfect working of all such interfaces. This falls
under the category of white box testing.
4. System level Testing: Whatever testing performed on the
application after its deployment in its actual environment is
termed as system level testing. This falls under the
category of black box testing. The testing engineers
generally perform system level testing.

15. ISO Standard of Testing
The following outline defines the basic elements of the ISO
9001:2000 standard.
1. Establish the elements of a quality management
system.
 Develop, implement, and improve the system.
2. Document the quality system.
 Describe the process, produce an operational manual, record
keeping.
3. Support quality control and assurance.
Promote the importance of quality, focus on customer
satisfaction.
4. Establish review mechanisms for the quality
management system.
 Identify review methods and feedback mechanisms.
5. Identify quality resources including personnel,
training, and infrastructure elements.
 Establish control mechanisms for planning, customer
requirements, technical activities (e.g., analysis, design,
testing)

16. SQA Plan
 The SQA Plan provides a road map
for establishing software quality
assurance.
 Developed by the SQA group (or by
the software team if an SQA group
does not exist).
 The plan serves as a template for
SQA activities that are started for each
software project.

17. The standard for SQA plan
A standard for SQA plans has been published by
the IEEE. The standard recommends a structure
that identifies:
1. The purpose and scope of the plan.
2. A description of all software engineering work products
(e.g., models, documents, source code) that fall within the
scope of SQA.
3. All applicable standards and practices that are applied
during the software process.
4. SQA actions and tasks (including reviews and audits) and
their placement throughout the software process.
5. The tools and methods that support SQA actions and tasks.
6. Software configuration management procedures.
7. Methods for assembling, safeguarding, and maintaining all
SQA-related records.
8. Organizational roles and responsibilities relative to product
quality

18. TESTING STRATEGIES

19. Validation Testing
 Validation testing begins at the end of
integration testing.
 This focuses on user-visible actions
and user-recognizable output from the
system.
 Validation succeeds when software
functions in a manner that can be
reasonably expected by the customer.

20. Types
1. Alpha Testing.
2. Beta Testing.
Alpha Testing:
The alpha test is conducted at the developer’s site by a
representative group of end users. The software is used in an
environment controlled by the developer recording errors and
usage problems.
Beta Testing:
The beta test is conducted at one or more end-user sites. Unlike
alpha testing, the developer generally is not present. Therefore, the
beta test is a “live” application of the software in an environment
that cannot be controlled by the developer. The customer records
all problems (real or imagined) that are encountered during beta
testing and reports these to the developer at regular intervals.

21. Approach
The testing works in the way defined
below:
1. Software validation is achieved through a series of tests that
demonstrate conformity with requirements.
2. A test plan outlines the classes of tests to be conducted.
3. A test procedure defines specific test cases that are designed to
ensure that all functional, performance, behavioral, usability and
other requirements are satisfied, the content is accurate and
documentation is correct.

22. System Testing
 System testing is actually a series of different tests
whose primary purpose is to fully exercise the
computer-based system.
 Whatever testing performed on the application after
its deployment in its actual environment is termed
as system level testing.

23. Types
I. Recovery Testing.
Recovery testing is a system test that forces the software
to fail in a variety of ways and verifies that recovery is
properly performed.
II. Security Testing.
Security testing attempts to verify that protection
mechanisms built into a system well and protecting it from
unauthorized accessing. During security testing, the tester
plays the role of the individual who desires to attack the
system and tries to break the wall of defense.
III. Stress Testing.
Stress testing executes a system in a manner that
demands resources in abnormal quantity, frequency, or

24. IV. Performance Testing.
Performance testing is designed to test the run-time performance of
software within the context of an integrated system. Performance
testing occurs throughout all steps in the testing process, even at the
unit level
v. Deployment Testing.
Deployment testing exercises the software in each environment in
which it is to operate. It examines all installation procedures and
specialized installation software (e.g., “installers”) that will be used
by customers, and all documentation that will be used to introduce
the software to end users.

25. Approach
A classic system-testing works in this way:
1. Design error-handling paths that test all
information coming from other elements
of the system.
2. Conduct a series of tests that simulate
bad data or errors at the software
interface.
3. Record the results of tests to use as
“evidence” if finger pointing does occur.
Participate in planning and design of
system tests to ensure that software is

26. Project Management

27. 1. Project Management
Spectrum
“The application of knowledge, skills,
tools and techniques
to project activities in order to meet
or exceed stakeholder needs
and expectations from a project.”

28. A balanced PM
Time Cost
Scope

29.  Project managers plan, monitor, and control the
work of a team of software engineers.
 Building computer software is a complex
undertaking, that’s why software projects need to
be managed.
 PM is all about understanding the four P’s—
people, product, process, and project.
 A project plan is produced as management
activities commence. The plan defines the
process and tasks to be conducted, the people
who will do the work, and the mechanisms for
assessing risks, controlling change, and
evaluating quality.
 The goal of PM is to build a high-quality product
on time and within budget, a project manager
does PM right when he encourages software
people to work together as an effective team,

30. 2. The Four Ps of Project
Management
 People
 Product
 Process
 Project

31. 2.1People
 The most important ingredient for a
successful project is having smart
people.
 The success of the software
development organization is very, very
much associated with the ability to recruit
good people.
 The people involved in any software
project are:
1. The Stakeholders.
2. Team Leaders
3. The Software Team
4. Agile Teams

32. 2.1.1Stakeholders
 There are 5 types of stakeholders:
◦ Senior managers.
◦ Project (Technical) managers.
◦ Practitioners.
◦ Customers.
◦ End users.

33. 2.1.2Team Leaders
 The successful team leaders are the
ones having the below qualities:
1. Power to motivate the technical team.
2. Ability to organize the process into a final
product.
3. Ability to make people innovative.
4. Problem solving skills.
5. Managerial Confidence.
6. Ability to achieve the goal in a risky situation.
7. Influencer and team builder.

34. 2.1.3 The software team
 The “best” team structure depends on the
management style of the organization. There are
the seven project factors that should be
considered when planning the structure of
software engineering teams:
1. Difficulty of the problem to be solved
2. “Size” of the resultant program(s) in lines of
code or function points.
3. Time that the team will stay together.
4. Degree to which the problem can be
modularized.
5. Required quality and reliability of the system to
be built.
6. Rigidity of the delivery date.
7. Degree of communication required for the
project.

35. 2.1.4 Agile Teams
 Agile software development has been
suggested as an antidote to many of
the problems that have plagued
software project work. An agile team
must:
◦ Be self organizing.
◦ Choose their own approach (process,
methods, tools).
◦ Conduct daily team meetings to
coordinate and synchronize the work
accomplished for the day.

36. 2.2 Product
Must examine the product and the
problem at the very beginning of the
project. The scope of the product must
be established and bounded.
1. Software Scope.
2. Problem Decomposition

37. 2.2.1 Software scope
 The first software project management
activity is the determination of
software scope. Scope is based on
three things:
◦ The context of software product.
◦ Information regarding input and output of
product.
◦ Function and performance of the product.

38. 2.2.2 Problem Decomposition
 Problem decomposition, sometimes
called partitioning, is an activity that
sits at the core of software
requirements analysis.
 Decomposition is applied in two major
areas:
1. The functionality and content
(information) that must be delivered.
2. The process that will be used to
deliver it.

39. Process
 The problem is to select the process
model that is appropriate for the software
to be engineered by your project team.
 The team must decide which process
model is most appropriate for
1. The customers who have requested the
product and the people who will do the
work.
2. The characteristics of the product itself.
3. The project environment in which the
software team works.

40.  After the selection of software process two
activities are performed:
1. Melding the Product and the Process.
2. Process Decomposition.
Melding the Product and the Process:
Project planning begins with the melding of the
product and the process. Each function
to be engineered by your team must pass
through the set of framework activities that
have been defined for your software
organization.
Process Decomposition:
Process decomposition commences after the
melding of process framework activities with
the product when the project manager asks,
“How do we accomplish this framework
activity?”

41. The Project
 In order to manage a successful software project, one have to
understand what can go wrong so that problems can be
avoided.
 A five-part commonsense approach to software projects:
1. Start on the right foot: This is accomplished by working hard (very
hard) to understand the problem that is to be solved and then
setting realistic objectives and expectations for everyone who will
be involved in the project.
2. Maintain momentum: To maintain momentum, the project
manager must give motivations to keep revenue of workers to an
absolute minimum, the team should emphasize quality in every task
it performs, and senior management should do everything possible
to stay out of the team’s way.
3. Track progress: For a software project, progress is tracked as
work products) are produced and approved (using technical
reviews) as part of a quality assurance activity.

42.  Make smart decisions: In essence, the decisions of
the project manager and the software team should be
to “keep it simple.” Decide to use existing software
components or patterns, decide to avoid custom
interfaces when standard approaches are available,
decide to identify and then avoid obvious risks, and
decide to allocate more time than you think is needed
to complex or risky tasks.
 Conduct a postmortem analysis: Establish a
consistent mechanism for extracting lessons learned
for each project. Evaluate the planned and actual
schedules, collect and analyze software project
metrics, get feedback from team members and
customers, and record findings in written form.

43. Risk Management

44. 1. Software Risks
 Risk always involves two
characteristics:
◦ Uncertainty: The risk may or may not
happen; that is, there are no 100 percent
probable risk.
◦ Loss: If the risk becomes a reality,
unwanted consequences or losses will
occur.
 When risks are analyzed, it is important
to quantify the level of uncertainty and
the degree of loss associated with each
risk. To accomplish this, different
categories of risks are considered.

45. 1.1Categories
1. Project risks: Threaten the project plan. i.e if project risks
become real, it is likely that the project schedule will slip
and that costs will increase.
2. Technical risks: Threaten the quality and timeliness of the
software to be produced. If a technical risk becomes a
reality, implementation may become difficult or impossible.
3. Business risks: Threaten the viability of the software to be
built and often jeopardize the project or the product.
4. Known risks: That can be uncovered after careful
evaluation of the project plan, the business and technical
environment in which the project is being developed and
other reliable information sources (e.g., unrealistic delivery
date, lack of documented requirements, software scope OR
poor development environment).

46. 5. Predictable risks: Extrapolated from past
project experience (e.g., staff turnover,
poor communication with the customer)
6. Unpredictable risks: They can and do
occur, but they are extremely difficult to
identify in advance.

47. Maintenance and
Reengineering

48. Software Maintenance
 Software Maintenance is the process
of modifying a software product after
it has been delivered to the customer.
The main purpose of software
maintenance is to modify and
update software application after
delivery to correct faults and to
improve performance.

49. Software Maintenance
 It begins almost immediately after the software is
released to end users.
 Within weeks, one class of users indicates that the
software must be changed so that it can
accommodate the special needs of their
environment.
 Within months, another corporate group who
wanted nothing to do with the software when it was
released now recognizes that it may provide them
with unexpected benefit. They’ll need a few
enhancements to make it work in their world.
 Software Maintenance requires more effort and
high cost.
 It is not unusual for a software organization to
expend as much as 60 to 70 percent of all

50. Software Re-engineering
When we need to update the software
to keep it to the current market, without
impacting its functionality, it is called
software re-engineering. It is a thorough
process where the design of software is
changed and programs are re-written.

51. Software Supportability
The capability of supporting a software system over
its whole product life. This implies satisfying any
necessary needs or requirements, but also the
provision of equipment, support infrastructure,
additional software, facilities, manpower, or any other
resource required to maintain the software
operational and capable of satisfying its function.

52. Business process re-
engineering
Business process re-
engineering is the search for,
and the implementation of,
radical change in business
process to achieve
breakthrough results.

53. Business Process
A business process is “a set of logically related tasks
performed to achieve a defined business outcome”
 Within the business process, people, equipment,
material resources, and business procedures are
combined to produce a specified result.
 Examples of business processes include designing
a new product, purchasing services and supplies,
hiring a new employee, and paying suppliers.
 Every business process has a defined customer a
person or group that receives the outcome (e.g., an
idea, a report, a design, a service, a product).
 Each business system (also called business
function) is composed of one or more business
processes, and each business process is defined
by a set of sub processes.

54. A BPR Model
The model for business process
reengineering defines six activities:
1. Business definition.
2. Process identification.
3. Process evaluation.
4. Process specification and design.
5. Prototyping.
6. Refinement and instantiation.

55. Business definition
Business goals are identified within the context of four key
drivers: cost reduction, time reduction, quality improvement, and
personnel development and empowerment. Goals may be
defined at the business level or for a specific component of the
business.

56. Process identification.
Processes that are critical to achieving the goals defined in the
business definition are identified. They may then be ranked by
importance, by need for change, or in any other way that is
appropriate for the reengineering activity.

57. Process evaluation.
The existing process is thoroughly analyzed and measured.
Process tasks are identified; the costs and time consumed by
process tasks are noted; and quality/performance problems are
isolated.

58. Process specification and
design.
Based on information obtained during the first three BPR
activities, use cases are prepared for each process that is to be
redesigned.

59. Prototyping
A redesigned business process must be prototyped before it is
fully integrated into the business. This activity “tests” the
process so that refinements can be made.

60. Refinement and instantiation
Based on feedback from the prototype, the business
process is refined and then instantiated within a
business system.

61. End of Lecture