Software Engineering

Presenter Uzair Iqbal Janjua

 Software and Software
Engineering
9th-century.
An algorithm is a finite set of, finite number of
instructions, in sequence to solve a specific problem or
to perform a specific task.
1950s
In 1950s the era of computing the concept of algorithm
was utilized by the scientist to develop a computer
program.
A computer program is a set of computer instructions
and procedures with data definition given to computer
hardware to perform specific task or function.
In early 1950s computer were large and were only
accessible to a few peoples in closed laboratories
 Software and Software
Engineering
1960.
With the evolution, the collection of computer programs
termed as software and it became common to use this
word in normal business.
In this era the expert able to write a computer programs
(software) was called as programmer.
1962
In early era of computing, the purpose of computer was
computation of numerical mathematics, so researchers and
scientist focused to introduce languages like Fortran and
Algol which were able to cater only mathematical tasks.
In 1962, Cobol language was launched for business
applications.
 Software and Software
Engineering
In early 1960s US Department of Defence
launched PL/I("Programming Language One",
pronouncedpee-el-wun) under the slogan
Everybody can program, thanks to PL/1 for the
development of scientific as well as for
commercial software.
1963.
first time-sharing system by MIT.
October 1968
NATO sponsored conference.
50 experts participated.
software engineering, software crisis
 Software and Software
Engineering
Software Engineering is about methods, tools and
techniques used for developing quality software.
all definition have consensus that,
Software engineering is an engineering discipline that is
software
concerned engineering
with all is a software
aspects of quality methodology
production.
or discipline
Computer based
science focuses on engineering
on theory and fundamentals;
softwareprinciples,
engineering to guide developers
is concerned to
with the practicalities
of developing and delivering useful software.
develop quality software for the
System engineering is concerned with all aspects
customers
of computer-based systems development
including hardware, software and process
engineering. Software engineering is part of this
more general process.
 Software
Definition of Software
Software is a general term for the various kinds ofprograms
used to operatecomputers and related devices. (The
termhardwaredescribes the physical aspects of computers
and related devices.)
Instructions (computer programs) that when executed provide
desired features, function, and performance
Data structures that enable the programs to adequately manipulate
information
Documents that describe the operation and use of the programs
Properties of Software
Software is developed or engineered but not manufactured.
Software doesnt wear out.
Most software continues to be custom built instead of component
based construction.
 Software
Software costs often dominate computer
system costs. The costs of software on a PC
are often greater than the hardware cost.
Software costs more to maintain than it does
to develop. For systems with a long life,
maintenance costs may be several times
development costs.
Roughly 60% of software costs are
development costs, 40% are testing costs. For
custom software, evolution costs often exceed
development costs.
 Software Types
System software
Application software
Engineering/scientific software
Embedded software
Product-line software (e.g., inventory
control, word processing, multimedia)
Web applications
Artificial intelligence software
 Software Types
Ubiquitous computing (small, wireless
devices)
Netsourcing (net-wide computing)
Open source (operating systems,
databases, development environments)
The ".com" marketing applications
 Software Products
Generic products
Stand-alone systems that are marketed and sold to any customer who
wishes to buy them.
Examples PC software such as graphics programs, project management
tools; CAD software; software for specific markets such as appointments
systems for dentists.
The specification of what the software should do is owned by the software
developer and decisions on software change are made by the developer.

Customized products
Software that is commissioned by a specific customer to meet their own
needs.
Examples embedded control systems, air traffic control software, traffic
monitoring systems
The specification of what the software should do is owned by the customer
for the software and they make decisions on software changes that are
required.
 Legacy Software Systems
Were developed decades ago, continually
modified to meet changes in business
requirements and computing platforms.
Support core business functions.
Have longevity and business criticality.
The proliferation of such systems is
causing headache for large organizations
who find them costly to maintain and risky
to evolve.
 Legacy Software Systems
(Adaptive) Must be adapted to meet the
needs of new computing environments or
more modern systems, databases, or
networks.
(Perfective) Must be enhanced to
implement new business requirements.
(Corrective) Must be changed because of
errors found in the specification, design, or
implementation.

(Note: These are also the three major

reasons for any software maintenance)
 Software Development Life Cycle
(SDLC)
A software development lifecycle is
essentially a series of distinct steps, set of
activities, or phases, that provide a model
for the development and lifecycle
management of an application or piece of
software that ensures good software is
built.
The activities may be linear, incremental, or
evolutionary.
Each phase in the life cycle has its own
process and deliverables that feed into the
next phase.
There are typically 5 phases.
 SDLC

Generic Process
Requirement Framework
gathering and
Communication
analysis
Involves communication among the customer and other stake
Design
holders; encompasses requirements gathering
Planning
Implementation or coding
Establishes a plan for software engineering work; addresses
Testing
technical tasks, resources, work products, and work schedule
Deployment
Modeling (Analyze, Design)
Encompasses the creation of models to better under the
Maintenance
requirements and the design
Construction (Code, Test)
Combines code generation and testing to uncover errors
Deployment
Involves delivery of software to the customer for evaluation14and
feedback
 Why (SDLC)
Time
create a good workflow.
Meets the needs of its users.
user's needs are determined.
designed and coded.
tested and reworked when necessary.
ready to go live.
handle errors, other problems and upgrades
throughout the application's lifespan.
 Modeling: Software Design
Brings together customer requirements, business needs, and
technical considerations to form the blueprint for a product
Creates a model that that provides detail about software data
structures, software architecture, interfaces, and components
that are necessary to implement the system
Architectural Design
Represents the structure of data and program components that are
required to build the software
Considers the architectural style, the structure and properties of
components that constitute the system, and interrelationships that
occur among all architectural components
User Interface Design
Creates an effective communication medium between a human
and a computer
Identifies interface objects and actions and then creates a screen
layout that forms the basis for a user interface prototype
Component-level Design
Defines the data structures, algorithms, interface characteristics,
and communication mechanisms allocated to each software
component 16
Traditional Process Models
 Waterfall Model
(Description)
Oldest software lifecycle model and best understood by
upper management.
Used when requirements are well understood and risk is low.
Work flow is in a linear (i.e., sequential) fashion.
Used often with well-defined adaptations or enhancements
to current software.

18
 Waterfall Model
(Diagram)
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Constructio
n
Code
Test Deployment
Delivery
Support
Feedback
19
 Waterfall Model
(Problems)
Doesn't support iteration, so changes can cause confusion.
Difficult for customers to state all requirements explicitly and
up front.
Requires customer patience because a working version of
the program doesn't occur until the final phase.
Problems can be somewhat alleviated in the model through
the addition of feedback loops (see the next slide).

20
 Waterfall Model with Feedback
(Diagram)
Communication
Project initiation
Requirements
gathering

Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Constructio
n
Code
Test Deployment
Delivery
Support
Feedback
21
 When to use Waterfall
Model
This model is used only when the requirements are very well
known, clear and fixed.
Product definition is stable.
Technology is understood.
There are no ambiguous requirements.
Ample resources with required expertise are available freely.
The project is short.

22
 Incremental Model
(Description)
Used when requirements are well understood.
Multiple independent deliveries are identified.
Work flow is in a linear (i.e., sequential) fashion.
Iterative in nature; focuses on an operational product with
each increment.
Provides a needed set of functionality sooner while delivering
optional components later
Useful also when staffing is too short for a full-scale
development.
Risk management is incremental.
multi-waterfall cycle
This model is more flexible less costly to change scope and
requirements. 23
 Incremental Model
(Diagram)
Increment #1
Communicati
on Plannin
g Modelin
g Constructi
on Deployme
nt

Increment #2
Communicati
on Plannin
g Modelin
g Constructi
on Deployme
nt

Increment #3
Communicati
on Plannin
g Modelin
g Constructi
on Deployme
nt

24
 Incremental Model
(Problems)
Requires good planning and design.
Requires early definition of a complete and fully functional
system to allow for the definition of increments.
Each phase of an iteration is rigid and do not overlap each
other.

25
 When to use Incremental
Model
This model can be used when the requirements of the
complete system are clearly defined and understood.
Major requirements must be defined; however, some details
can evolve with time.
There is a need to get a product to the market early.
A new technology is being used.
Resources with needed skill set are not available.
There are some high risk features and goals.

26
Rapid Application Development Model
(RAD) (Description)
In RAD model the components or functions
are developed in parallel as if they were
mini projects.
It is a type ofincremental model.
The developments are time boxed,
delivered and then assembled.
 RAD
(Diagram)

Communicati
on Deployment
Integration
Delivery
feedback

Planning
Rapid Application Development Model
(RAD)
Business modeling:The information flow is identified
between various business functions.
Data modeling:Information gathered from business
modeling is used to define data objects that are needed
for the business.
Process modeling:Data objects defined in data
modeling are converted to achieve the business
information flow to achieve some specific business
objective.
Application generation:Automated tools are used to
convert process models into code and the actual system.
Testing and turnover:Test new components and all the
interfaces.
 RAD Model
(Problems)
Depends on strong team and individual performances for
identifying business requirements.
Only system that can be modularized can be built using RAD.
Requires highly skilled developers/designers.
High dependency on modeling skills.
Inapplicable to cheaper projects as cost of modeling and
automated code generation is very high.

30
 When to use RAD Model

RAD should be used when there is a need to create a system

that can be modularized in 2-3 months of time.
It should be used if theres high availability of designers for
modeling and the budget is high enough to afford their cost
along with the cost of automated code generating tools.

31
 Prototyping Model
(Description)
Follows an evolutionary and iterative approach.
Used when requirements are not well understood.
Serves as a mechanism for identifying software
requirements.
Focuses on those aspects of the software that are visible to
the customer/user.
Feedback is used to refine the prototype.

32
 Prototyping Model
(Diagram)
Quick
Planning
Communicati
on
Start

Modeling
Deployment Quick
, Design
Delivery,
and
Feedback
Constructio
n
Of
Prototype
33
 Prototyping Model
(Problems)
The customer sees a "working version" of the software,
wants to stop all development and then buy the prototype
after a "few fixes" are made
Developers often make implementation compromises to get
the software running quickly (e.g., language choice, user
interface, operating system choice, inefficient algorithms)
Lesson learned
Define the rules up front on the final disposition of the prototype
before it is built
In most circumstances, plan to discard the prototype and
engineer the actual production software with a goal toward
quality

34
 When to Use Prototyping Model

Prototype model should be used when the desired system

needs to have a lot of interaction with the end users.
Typically, online systems, web interfaces have a very high
amount of interaction with end users, are best suited for
Prototype model. It might take a while for a system to be
built that allows ease of use and needs minimal training for
the end user.
Prototyping ensures that the end users constantly work with
the system and provide a feedback which is incorporated in
the prototype to result in a useable system. They are
excellent for designing good human computer interface
systems.

35
 Spiral Model
(Description)

Invented by Dr. Barry Boehm in 1988.

Follows an evolutionary approach.
Used when requirements are not well understood and risks are
high.
Inner spirals focus on identifying software requirements and
project risks; may also incorporate prototyping.
Outer spirals take on a classical waterfall approach after
requirements have been defined, but permit iterative growth of
the software.
Operates as a risk-driven modela go/no-go decision occurs
after each complete spiral in order to react to risk
determinations.
Requires considerable expertise in risk assessment.
Serves as a realistic model for large-scale software 36
development.
Spiral Model
(Diagram)
Planning

Communication

Start Modeling

Start

Deployment Construction

37
 Spiral Model
(Problems)
Can be a costly model to use.
Risk analysis requires highly specific expertise.
Projects success is highly dependent on the risk analysis
phase.
Doesnt work well for smaller projects

38
 When to Use Spiral Model

When costs and risk evaluation is important

For medium to high-risk projects
Long-term project commitment unwise because of potential
changes to economic priorities
Users are unsure of their needs
Requirements are complex
New product line
Significant changes are expected (research and exploration)

39
General Weaknesses of
Evolutionary Process Models
1) Prototyping poses a problem to project planning because
of the uncertain number of iterations required to
construct the product
2) Evolutionary software processes do not establish the
maximum speed of the evolution
If too fast, the process will fall into chaos
If too slow, productivity could be affected
3) Software processes should focus first on flexibility and
extensibility, and second on high quality
We should prioritize the speed of the development over zero
defects
Extending the development in order to reach higher quality
could result in late delivery
40
Specialized Process
Models
Component-based Development
Model
Consists of the following process steps
Available component-based products are researched and
evaluated for the application domain in question
Component integration issues are considered
A software architecture is designed to accommodate the
components
Components are integrated into the architecture
Comprehensive testing is conducted to ensure proper
functionality
Relies on a robust component library
Capitalizes on software reuse, which leads to
documented savings in project cost and time

42
Formal Methods Model
(Description)
Encompasses a set of activities that leads to formal
mathematical specification of computer software
Enables a software engineer to specify, develop, and
verify a computer-based system by applying a rigorous,
mathematical notation
Ambiguity, incompleteness, and inconsistency can be
discovered and corrected more easily through
mathematical analysis
Offers the promise of defect-free software
Used often when building safety-critical systems

43
Formal Methods Model
(Challenges)
Development of formal methods is currently quite time-
consuming and expensive
Because few software developers have the necessary
background to apply formal methods, extensive training
is required
It is difficult to use the models as a communication
mechanism for technically unsophisticated customers

44
 Difference Between Waterfall And
Incremental Model
Waterfall Model Incremental Model
User involvement
user involvement is not much client is involved at every stage
Supply
after all the stages of life cycle is Every increment is delivered to
completed the user
Variability
cannot be traced back easily be modified
Credentials
The main focus is documentation focus is not documentation but a
as end product user satisfied product
Manpower
More manpower is required less staff is required
 Difference Between Waterfall And
Incremental Model
Waterfall Model Incremental Model
Time limitation
quality portion is delivered after operational product is given to
months the user within weeks
Project size
only suited for large projects suited for small project
Client Decision Making
No Yes
Risk Involvement
High Low
Testing
After completion of coding phase After every iteration
The Unified Process
Background
Birthed during the late 1980's and early 1990s when
object-oriented languages were gaining wide-spread
use.
Many object-oriented analysis and design methods were
proposed; three top authors were Grady Booch, Ivar
Jacobson, and James Rumbaugh.
They eventually worked together on a unified method,
called the Unified Modeling Language (UML).
UML is a robust notation for the modeling and
development of object-oriented systems.
UML became an industry standard in 1997.
However, UML does not provide the process framework,
only the necessary technology for object-oriented
development.
48
Background (continued)
Booch, Jacobson, and Rumbaugh later developed the
unified process, which is a framework for object-
oriented software engineering using UML
Draws on the best features and characteristics of
conventional software process models.
Emphasizes the important role of software architecture.
Consists of a process flow that is iterative and incremental,
thereby providing an evolutionary feel.
Consists of five phases: inception, elaboration,
construction, transition, and production.

49
Phases of the Unified
Process
Inception Elaboration

planning

modeling
communication

construction
Construction

deployment

Production Transition
50
Inception Phase

Encompasses both customer communication and planning

activities of the generic process.
Business requirements for the software are identified.
A rough architecture for the system is proposed.
A plan is created for an incremental, iterative development.
Fundamental business requirements are described through
preliminary use cases.
A use case describes a sequence of actions that are performed
by a user.

51
 Elaboration Phase
Encompasses both the planning and modeling activities of the
generic process.
Refines and expands the preliminary use cases.
Expands the architectural representation to include five views
Use-case model
Analysis model
Design model
Implementation model
Deployment model
Often results in an executable architectural baseline that
represents a first cut executable system.
The baseline demonstrates the viability of the architecture but
does not provide all features and functions required to use the
system.

52
 Construction Phase

Encompasses the construction activity of the generic

process.
Uses the architectural model from the elaboration phase as
input.
Develops or acquires the software components that make
each use-case operational.
Analysis and design models from the previous phase are
completed to reflect the final version of the increment.
Use cases are used to derive a set of acceptance tests that
are executed prior to the next phase.

53
 Transition Phase

Encompasses the last part of the construction activity and the

first part of the deployment activity of the generic process
Software is given to end users for beta testing and user
feedback reports on defects and necessary changes
The software teams create necessary support documentation
(user manuals, trouble-shooting guides, installation procedures)
At the conclusion of this phase, the software increment
becomes a usable software release

54
 Production Phase
Encompasses the last part of the deployment activity of the
generic process
On-going use of the software is monitored
Support for the operating environment (infrastructure) is
provided
Defect reports and requests for changes are submitted and
evaluated

55
Unified Process Work
Products
Work products are produced in each of the first four
phases of the unified process.
In this course, we will concentrate on the analysis model
and the design model work products.
Analysis model includes
Scenario-based model, class-based model, and behavioral
model.
Design model includes
Component-level design, interface design, architectural
design, and data/class design.

56

Conclusion
The choice of project is made according to the
requirements. While all software projects have to be
professionally managed and developed, different
techniques are appropriate for different types of
system.
Whenever the concern is documentation we will make
choice of waterfall model.
When our concern is making software that readily accepts
change we will choose incremental mode.
Games should always be developed using a series of
prototypes whereas safety critical control systems require
a complete and analyzable specification to be developed.
 References
http://researchpedia.info/difference
-between-waterfall-and-incremental-m
odel/
http://searchmicroservices.techtarget
.com/definition/software
http://istqbexamcertification.com/wh
at-is-incremental-model-advantages-
disadvantages-and-when-to-use-it/