An Introduction to Software
Engineering
Evolution of Software Engineering
• Engineering: The Application of Science to the
Solution of Practical Problems
• The field of software engineering was
born in NATO Conferences, 1968 in
response to chronic failures of large
software projects to meet schedule and
budget constraints
• Since then, term became popular
because software is getting more and
more important to industry and business
but the “software crisis” still persists.
What is Software
Engineering?
• Different focuses for this term exist in various
textbooks. Some are listed below.
• The application of a systematic, disciplined,
quantifiable
approach
to
development,
operation, and maintenance of software; that is,
the application of engineering to software. (IEEE
Standard Computer Dictionary, 610.12, ISBN
1-55937-079-3, 1990)
What is Software Engineering?
(ctd)
•
Software engineering is concerned with the
theories, methods and tools for developing,
managing and evolving software products. (I.
Sommerville, 6ed.)
• A discipline whose aim is the production of
quality software, delivered on time, within
budget, and satisfying users' needs. (Stephen
R. Schach, Software Engineering, 2ed.)
• Multi-person construction
software (Parnas, 1987)
of
multi-version
What is Software Engineering?
(ctd.)
•
The practical application of scientific knowledge
in the design and construction of computer
programs and the associated documentation
required to develop, operate and maintain them
(B.W. Boehm)
•
The establishment and use of sound engineering
principles in order to obtain economically
software that is reliable and works efficiently on
real machines (F.L. Bauer)
What is Software Engineering?
(ctd.)
•
The technological and managerial discipline
concerned with systematic production and
maintenance of software products that are
developed and modified on time and within cost
constraints (R. Fairley)
•
A discipline that deals with the building of
software systems which are so large that they
are built by a team or teams of engineers
(Ghezzi, Jazayeri, Mandrioli)
Other Definitions of Software
Engineering
• “A systematic approach to the analysis, design,
implementation and maintenance of software.” (The
Free On-Line Dictionary of Computing)
• “The systematic application of tools and techniques
in the development of computer-based applications.”
(Sue Conger in The New Software Engineering)
• “Software Engineering is about designing and
developing high-quality software.” (Shari Lawrence
Pfleeger in Software Engineering -- The Production
of Quality Software)
So, Software Engineering is
…
• Scope
– study of software process, development
principles, techniques, and notations
• Goals
– production of quality software,
– delivered on time,
– within budget,
– satisfying customers’ requirements and users’
needs
SOFTWARE ENGINEERING-A
LAYERED
TECHNOLOGY
• Quality focus - Bedrock that supports
software Engineering.
• Process - Foundation for software
Engineering
• Methods - Provide technical How-to’s for
building software
• Tools - Provide semi-automatic and
automatic support to methods
Software Programming ≠
Software Engineering
• Software programming: the process of translating a
problem from its physical environment into a language
that a computer can understand and obey. (Webster’s
New World Dictionary of Computer Terms)
–
–
–
–
Single developer
“Toy” applications
Short lifespan
Single or few stakeholders
•
Architect = Developer = Manager = Tester = Customer = User
– One-of-a-kind systems
– Built from scratch
– Minimal maintenance
Software Programming ≠
Software Engineering
• Software engineering
–
–
–
–
Teams of developers with multiple roles
Complex systems
Indefinite lifespan
Numerous stakeholders
•
Architect ≠ Developer ≠ Manager ≠ Tester ≠ Customer ≠ User
– System families
– Reuse to amortize costs
– Maintenance accounts for over 60% of overall
development costs
What is the difference between software
engineering and system engineering?
• System engineering is concerned with all
aspects
of
computer-based
systems
development including hardware, software and
process engineering.
• Software engineering is part of this process
concerned with developing the software
infrastructure,
control,
applications
and
databases in the system.
• System engineers are involved in system
specification, architectural design, integration
and deployment.
What is the difference between software
engineering and computer science?
• Computer science is concerned with theory and
fundamentals;
• software engineering is concerned with the
practicalities of developing and delivering useful
software.
• Computer science theories are still insufficient to
act as a complete underpinning for software
engineering (unlike e.g. physics and electrical
engineering).
Software Engineering Challenges
• Functionality. The capability to provide functions which
meet stated and implied needs when the software is used
• Reliability. The capability to maintain a specified level of
performance
• Usability. The capability to be understood, learned, and
used
• Efficiency. The capability to provide appropriate
performance relative to the amount of resources used
• Maintainability. The capability to be modified for purposes
of making corrections, improvements, or adaptation
• Portability. The capability to be adapted for different
specified environments without applying actions or means
other than those provided for this purpose in the product
Software Development Life Cycle
(SDLC)
• Software-development life-cycle is used to facilitate the
development of a large software product in a systematic,
well-defined, and cost-effective way.
• An information system goes through a series of phases
from conception to implementation. This process is
called the Software-Development Life-Cycle.
• Various reasons for using a life-cycle model include:
– Helps to understand the entire process
– Enforces a structured approach to development
– Enables planning of resources in advance
– Enables subsequent controls of them
– Aids management to track progress of the system
The Software Life Cycle
• Encompasses all activities from initial analysis until
end of work
• Formal process for software development
– Describes phases of the development process
– Gives guidelines for how to carry out the phases
• Development phases
– Requirement Gathering and Analysis
– Design
– Implementation
– Testing
– Maintenance
SDLC Phases and outcomes
Requirement Gathering and
Analysis
• Decide what the project is suppose to do
• Do not think about how the program will accomplish
tasks
– Describes what program will do once completed
– User manual: tells how user will operate program
– Performance criteria
• Output: Software requirements specification (SRS)
document
Design
•
•
•
•
Plan how to implement the system
Discover structures that underlie problem to be solved
Decide what classes and methods you need
Design approaches:• Structure Design
• Detailed Design
– Description of classes and methods
– Diagrams showing the relationships among the
classes
• Output: (Software Design Document)
Implementation
• Write and compile the code
• Code implements classes and methods
discovered in the design phase
• Output: (Code listing and unit testing
reports)
Testing
•
•
•
•
Testing strategies:Unit Testing
Integration Testing
System testing
– Alpha
– Beta
– Acceptance
• Run tests to verify the program works correctly
• Output: ( Test cases and test reports)
Maintenance
• Users install program
• Users use program for its intended
purpose
• Maintenance approaches:• Corrective
• Perfective
• adaptive
• Output(Revised version and resports)
What is a software process?
• A set of activities whose goal is the development or
evolution of software.
• Generic activities in all software processes are:
– Specification - what the system should do and its
development constraints
– Development - production of the software system
– Validation - checking that the software is what the
customer wants
– Evolution - changing the software in response to
changing demands.
Generic software process models
•
•
•
•
•
•
The waterfall model
The Prototype Model
Spiral Mode
Iterative enhancement model
Rapid application development (RAD) model
Evolutionary process models
waterfall model
• This is the most common and classic of life cycle
models, also referred to as a linear sequential
life cycle model.
• It is very simple to understand and use. In a
waterfall model, each phase must be completed
in its entirety before the next phase can begin.
• The least flexible and most obsolete of the life
cycle models.
• Well suited to projects that has low risk in the
areas of user interface and performance
requirements, but high risk in budget and
schedule predictability and control.
Waterfall model
Waterfall model phases
•
•
•
•
•
Requirements analysis and definition
System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance
Advantages of Waterfall Model
•
•
•
•
•
It is a linear model.
It is a segmental model.
It is systematic and sequential.
It is a simple one.
It has proper documentation
Disadvantages
• It is difficult to define all requirement at the beginning of
the project.
• Model is not suitable for accommodating any change
• It does not scale up well to large projects
• Inflexible partitioning of the project into distinct stages
makes it difficult to respond to changing customer
requirements.
• Therefore, this model is only appropriate when the
requirements are well-understood and changes will be
fairly limited during the design process.
• Few business systems have stable requirements.
• The waterfall model is mostly used for large systems
engineering projects where a system is developed at
several sites.
Iterative Waterfall Model
• Waterfall model assumes in its design that
no error will occur during the design phase
• Iterative waterfall model introduces
feedback paths to the previous phases for
each process phase
• It is still preferred to detect the errors in
the same phase they occur
• Conduct reviews after each milestone
31
Iterative Waterfall Model
Feasibility
Study
Req. Analysis
Design
Coding
Testing
Maintenance
V-model
• Another variant of the waterfall model — the V-model —
associates each development activity with a test or
validation at the same level of abstraction.
• Each development activity builds a more detailed model
of the system than the one before it, and each validation
tests a higher abstraction than its predecessor.
• The least flexible and most obsolete of the life cycle
models. Well suited to projects that has low risk in the
areas of user interface and performance requirements,
but high risk in budget and schedule predictability and
control.
V-Model
Advantages
• Simple and easy to use.
• Each phase has specific deliverables.
• Higher chance of success over the
waterfall model due to the development of
test plans early on during the life cycle.
• Works well for small projects where
requirements are easily understood.
Disadvantages
• Very rigid, like the waterfall model.
• Little flexibility and adjusting scope difficult
and expensive.
• Software is developed during the
implementation phase, so no early
prototypes of the software are produced.
• Model doesn’t provide a clear path for
problems found during testing phases.
Prototyping Model
• prototyping paradigm begins with requirements
gathering.
• Developer and customer meet and define the
overall objectives for the software, identify
whatever requirements are known, and outline
areas where further definition is mandatory.
• A "quick design" then occurs. The quick design
focuses on a representation of those aspects of
the software that will be visible to the
customer/user (e.g., input approaches and
output formats).
Prototyping Model
• It is based on the idea of building a
prototype before building the actual
system
– Prototype exhibits limited functional abilities,
low reliability, and inefficient performance
– Used to show input types, user interactions
using dummy functions
– Used to resolve technical issues resulting of
unknown components (e.g. new hardware)
38
Prototyping Model
• Customers could believe it’s the working
system
• Developer could take “shortcuts” and only
fill the prototype instead of redesigning it
• Customers may think that the system is
almost done, and only few fixes are
needed
39
Prototyping Model
Feasibility study
Requirement Gathering
Quick Design
Refine Requirements
Build Prototype
Customer Evaluation
Design
Implement
Test
Maintain
40
Advantage &
limitations of Prototyping Models
Advantage
• Suitable for large systems for which there is no manual
process to define there requirements.
• User training to use the system.
• User services determination.
• System training.
• Quality of software is good.
• Requirements are not freezed.
Limitations of Prototyping Model
• It is difficult to find all the requirements of the software
initially.
• It is very difficult to predict how the system will work after
development.
Increment process model / Iterative
enhancement model
• In
incremental
model
the
whole
requirement is divided into various builds.
• Each module (independent units) passes
through
the
requirements,
design,
implementation and testing phases.
• The incremental build model is a method
of software development where the
product is designed, implemented and
tested incrementally until the product is
finished.
• It is also called iterative enhancement model;.
• In this model, the software is broken down
into several modules, which are incrementally
developed and delivered.
• First, the development team develops the core
module of the system and then it is later refined
into increasing levels of capability of adding new
functionalities in successive versions
• Each subsequent(coming after something in
time) release of the module adds function to the
previous release. The process continues till the=
complete system is achieved.
Increment/Iterative-enhancemen
t model
Advantages
• The feedback from early increments improve the
later stages.
• The possibility of changes in requirements is reduced
because of the shorter time span between the design
of a component and its delivery.
• Users get benefits earlier than with a conventional
approach.
• Smaller sub-projects are easier to control and manage.
• The project can be temporarily abandoned if more urgent
work crops up.
• Job satisfaction is increased for developers who see
their labors bearing fruit at regular, short intervals
Disadvantages
• Programmers may be more productive working
on one large system than on a series of smaller
ones.
• Some problems are difficult to divide into
functional units (modules), which can be
incrementally developed and delivered
• Software breakage, that is, later increments may
require modifications to earlier increments.
Rapid Application Development
Model (RAD)
• RAD is proposed when requirements and
solutions can be modularized as independent
system or software components, each of which
can be developed by different teams.
• User involvement is essential from requirement
phase to deliver of the product
• Process is stared with rapid prototype and is
given to user for evolution. user feedback is
obtained and prototype is refined.
• SRS and design document are prepared with the
association of users.
• RAD becomes faster if the software engineer
uses the component’s technology (CASE Tools )
such that the components are really available for
reuse.
• Since the development is distributed into
component-development teams, the teams work
in tandem and total development is completed in
a short period (i.e., 60 to 90 days).
Martin Approach to RAD
• The Martin approach to RAD includes four
phases:
–
–
–
–
Requirements planning
User design
Construction
Cutover
Rapid Application Model (RAD)
• Requirements planning phase (a workshop
utilizing structured discussion of business
problems)
• User description phase – automated tools
capture information from users
• Construction phase – productivity tools, such as
code generators, screen generators, etc. inside
a time-box. (“Do until done”)
• Cutover phase -- installation of the system, user
acceptance testing and user training
RAD Strengths
• Reduced cycle time and improved productivity
with fewer people means lower cost
• Customer involved throughout the complete
cycle minimizes risk of not achieving customer
satisfaction and business needs
• Focus moves from documentation to code .
• Uses modeling concepts to capture information
about business, data, and processes.
RAD Weaknesses
• Accelerated development process must give
quick responses to the user
• Risk of never achieving closure
• Hard to use with legacy systems
• Requires a system that can be modularized
• Developers and customers must be committed
to rapid-fire activities in an abbreviated time
frame.
When to use RAD
•
•
•
•
•
•
•
Reasonably well-known requirements
User involved throughout the life cycle
Project can be time-boxed
Functionality delivered in increments
High performance not required
Low technical risks
System can be modularized
Evolutionary Process Model
• In EP model development engineering effort is made
first to establish correct, precise requirement definitions
and system scope, as agreed by all the users across the
organization.
• This is achieved through application of iterative
processes to evolve a system most suited to the given
circumstances.
• The process is iterative as the software engineer
goes through a repetitive process of requirement until all
users and stakeholders are satisfied.
• This model differs from the iterative enhancement model
in the sense that this does not require a useable product
at the end of each cycle.
• In evolutionary development, requirements are
implemented by category rather than by priority
Evolutionary Development..
• Main characteristics:
– The phases of the software construction are
interleaved
– Feedback from the user is used throughout the
entire process
– The software product is refined through many
versions
• Types of evolutionary development:
– Exploratory development
– Throw-away prototyping
Evolutionary development
• Exploratory development
– Objective is to work with customers and to
evolve a final system from an initial outline
specification.
Should
start
with
well-understood requirements and add new
features as proposed by the customer.
• Throw-away prototyping
– Objective is to understand the system
requirements. Should start with poorly
understood requirements to clarify what is
really needed.
Evolutionary Development…
• Advantages:
– Deals constantly with changes
– Provides quickly an initial version of the system
– Involves all development teams
• Disadvantages:
– Quick fixes may be involved
– “Invisible” process, not well-supported by
documentation
– The system’s structure can be corrupted by
continuous change
Spiral Model
• Presented by Boehm in 1985. The spiral model is
focused on risk management.
• The spiral model is favored for large, expensive, and
complicated projects.
• The spiral model is similar to the incremental model, with
more emphases placed on risk analysis.
• A software project repeatedly passes through these
phases in iterations (called Spirals in this model).
• The baseline spiral, starting in the planning phase,
requirements is gathered and risk is assessed.
• Each subsequent spiral builds on the baseline spiral.
Spiral model
Advantages
• High amount of risk analysis.
• Risks are explicitly assessed and resolved
throughout the process
• Focus on early error detection and design
flaws.
• Good for large and mission-critical
projects.
• Software is produced early in the software
life cycle.
Disadvantages
• Can be a costly model to use.
• Risk analysis requires highly specific
expertise.
• Project’s success is highly dependent on
the risk analysis phase.
• Doesn’t work well for smaller projects.
Selection of a Life Cycle Model
Selection of a model is based on:
a) Requirements
b) Development team
c) Users
d) Project type and associated risk
Based On Characteristics Of
Requirements
Based On Status Of
Development Team
Based On User’s Participation
Based On Type Of Project With
Associated Risk
Limitations &
advantages of Spiral Model
Limitations of Spiral Model
• No strict standards for software development.
• No particular beginning or end of a particular
phase.
Advantages of Spiral Model
• It is risk-driven model.
• It is very flexible.
• Less documentation is needed.
• It uses prototyping