Software Engineering

Dr. Syed Ali Raza

Assistant Professor
Department of Computer
Science
GC University Lahore
Course Outline
 Software and Software Engineering Process: A Generic
View
 Process Models
 Prescriptive Process Models
 Iterative Models
 Agile Development
 Software Engineering Practice
 Practice: A Generic View System Engineering
 Requirements Engineering Analysis
 Design Engineering
 Architectural Design
 Component-Level Design
 Software Testing Strategies
 Product Metrics for Software
A Word about Sessionals
Four Assignments
 Process Models
 Functional and Non Functional Requirements
 Use Case Diagrams
 Data Flow Diagrams
2 Quizes
Course Book
Course Objectives
The main objectives of this course are to:
 To learn the difference between development
and engineering
 To enhance the basics of Software engineering
methods and practices.
 To learn the techniques for developing
software systems.
 To understand the object oriented approach of
software engineering
 To understand software testing approaches.
Software Engineering
Lecture 1
Introduction to SE
Why Software Engineering
Why Software Engineering

Delivered, but never

successfully used
45%

Used as delivered
2%
Usable w. rework
Paid for, but
3% not delivered
30%
Used w. extensive rework,
but later abandoned
20%

Take
Takeaalook
lookat
atthe
theStandish
StandishReport
Report(The
(The“Chaos”
“Chaos”
Chapter 1- Introduction
What is Software?
Software is:
 (1) instructions (computer programs) that
when executed provide desired features,
function, and performance;
 (2) data structures that enable the programs to
adequately manipulate information and
 (3) documentation that describes the operation
and use of the programs.
What is Software?
Software is developed or engineered, it is
not manufactured in the classical sense.
Software doesn't "wear out."
Although the industry is moving toward
component-based construction, most
software continues to be custom-built.
Wear vs. Deterioration
increased failure
rate due to side effects
Failure
rate

change
actual curve

idealized curve

Time
Software Applications
system software
application software
engineering/scientific software
embedded software
product-line software
WebApps (Web applications)
AI software
Software—New Categories
 Open world computing—pervasive, distributed computing
 Ubiquitous computing—wireless networks
 Netsourcing—the Web as a computing engine
 Open source—”free” source code open to the computing
community (a blessing, but also a potential curse!)
 Also … (see Chapter 31)
 Data mining
 Grid computing
 Cognitive machines
 Software for nanotechnologies
Legacy Software
Why must it change
 software must be adapted to meet the needs of
new computing environments or technology.
 software must be enhanced to implement new
business requirements.
 software must be extended to make it
interoperable with other more modern systems
or databases.
 software must be re-architected to make it
viable within a network environment.
Software Engineering
Some realities:
 a concerted effort should be made to
understand the problem before a software
solution is developed
 design becomes a pivotal activity
 software should exhibit high quality
 software should be maintainable
The seminal definition:
 [Software engineering is] the establishment
and use of sound engineering principles in
order to obtain economically software that is
reliable and works efficiently on real machines.
Software Engineering
The IEEE definition:
 Software Engineering: (1) The application of a
systematic, disciplined, quantifiable approach
to the development, operation, and
maintenance of software; that is, the
application of engineering to software. (2) The
study of approaches as in (1).
A Layered Technology

tools

methods

process model

a “quality” focus

Software Engineering
Software Engineering: Layered
Approach
 Analysis: Understand the nature of the problem and
break the problem into pieces
 Synthesis: Put the pieces together into a large
structure

For problem solving we use

 Techniques (methods):
 Formal procedures for producing results using some
well-defined notation
 Methodologies:
 Collection of techniques applied across software
development and unified by a philosophical approach
 Tools:
 Instrument or automated systems to accomplish a
technique
A Process Framework
Process framework
 Framework activities
work tasks
work products
milestones &
deliverables
QA checkpoints
 Umbrella Activities
Framework Activities
Communication
Planning
Modeling
 Analysis of requirements
 Design
Construction
 Code generation
 Testing
Deployment
Umbrella Activities
 A Generic Process Model
• A generic process framework
for software engineering
defines five framework
activities
• Communication
• Planning
• Modeling
• Construction
• Deployment
• In addition, a set of umbrella
activities are applied
throughout the process
• Project tracking and control
• Risk management
• Quality assurance
• Configuration management
• Technical reviews
How the framework activities and the actions and tasks that occur
within each activity are organized with respect to sequence and
Adapting a Process Model
 the overall flow of activities, actions, and tasks and the
interdependencies among them
 the degree to which actions and tasks are defined within
each framework activity
 the degree to which work products are identified and
required
 the manner which quality assurance activities are applied
 the manner in which project tracking and control activities
are applied
 the overall degree of detail and rigor with which the
process is described
 the degree to which the customer and other stakeholders
are involved with the project
 the level of autonomy given to the software team
 the degree to which team organization and roles are
prescribed
The Essence of Practice
Polya suggests:
1. Understand the problem (communication
and analysis).
2. Plan a solution (modeling and software
design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and
quality assurance).
Understand the Problem
Who has a stake in the solution to the
problem?
 That is, who are the stakeholders?
What are the unknowns?
 What data, functions, and features are required
to properly solve the problem?
Can the problem be compartmentalized?
 Is it possible to represent smaller problems
that may be easier to understand?
Can the problem be represented graphically?
 Can an analysis model be created?

26
Plan the Solution
 Have you seen similar problems before?
 Are there patterns that are recognizable in a potential
solution? Is there existing software that implements the data,
functions, and features that are required?
 Has a similar problem been solved?
 If so, are elements of the solution reusable?
 Can sub-problems be defined?
 If so, are solutions readily apparent for the sub-problems?
 Can you represent a solution in a manner that leads to
effective implementation?
 Can a design model be created?
Carry Out the Plan
Does the solution conform to the plan?
 Is source code traceable to the design model?
Is each component part of the solution
provably correct?
 Has the design and code been reviewed, or
better, have correctness proofs been applied to
algorithm?
Examine the Result
Is it possible to test each component part of
the solution?
 Has a reasonable testing strategy been
implemented?
Does the solution produce results that
conform to the data, functions, and features
that are required?
 Has the software been validated against all
stakeholder requirements?
Hooker’s General Principles
1: The Reason It All Exists
2: KISS (Keep It Simple, Stupid!)
3: Maintain the Vision
4: What You Produce, Others Will Consume
5: Be Open to the Future
6: Plan Ahead for Reuse
7: Think!
How It all Starts
SafeHome:
 Every software project is precipitated by some
business need—
the need to correct a defect in an existing
application;
the need to the need to adapt a ‘legacy system’ to a
changing business environment;
the need to extend the functions and features of an
existing application, or
the need to create a new product, service, or
system.

31
General issues that affect most
software
Heterogeneity
 Increasingly, systems are required to operate as
distributed systems across networks that include
different types of computer and mobile devices.
Business and social change
 Business and society are changing incredibly quickly
as emerging economies develop and new technologies
become available. They need to be able to change
their existing software and to rapidly develop new
software.
Security and trust
 As software is intertwined with all aspects of our lives,
it is essential that we can trust that software.
Software myths
Management myths
 Standards and procedures for building software
 Add more programmers if behind the schedule
Customer myths
 A general description of objectives enough to start
coding
 Requirements may change as the software is
flexible
Practitioner myths
 Task accomplished when the program works
 Quality assessment when the program is running
 Working program the only project deliverable
Software engineering ethics
Software engineering involves wider
responsibilities than simply the application of
technical skills.
Software engineers must behave in an honest
and ethically responsible way if they are to be
respected as professionals.
Ethical behaviour is more than simply
upholding the law but involves following a set
of principles that are morally correct.
Issues of professional
responsibility
Confidentiality
 Engineers should normally respect the
confidentiality of their employers or clients
irrespective of whether or not a formal
confidentiality agreement has been signed.
Competence
 Engineers should not misrepresent their level
of competence. They should not knowingly
accept work which is outwith their
competence.
Issues of professional
responsibility
 Intellectual property rights
 Engineers should be aware of local laws governing the
use of intellectual property such as patents, copyright,
etc. They should be careful to ensure that the
intellectual property of employers and clients is
protected.
 Computer misuse
 Software engineers should not use their technical skills
to misuse other people’s computers. Computer misuse
ranges from relatively trivial (game playing on an
employer’s machine, say) to extremely serious
(dissemination of viruses).
Credits
Pressman Slides

Sommerville Slides

Whitten-Bentley Slides