Overview of Software

Engineering

Dr. Oyedeji A.I.

Preamble
 “You’ve got to be very careful if you
don’t know where you’re going,
because you might not get there.”
 Moving from “Disorganized” , non-
standard unsystematic approach
 To Goal oriented, systematic,
methodological, scientific and principled
technology driven approach.
Software Engineering
Standards Programming standards, protocols, COM/DCOM,
CORBA, Design standards Testing Standard GUI
standard
Principles Principles of Development, testing, implementation,
Principle of reuse
Models Process model, Waterfall model RAD Model, Design
model
Methods Analysis-Design-Build-Test-deliver, unit testing,
module testing, installation testing
Tools Editors, modelling tools, compiler, CASE, I-CASE
report writer, DBM tool
Estimation Function point analysis

Building Use of templates and checklist

 Current state of affairs
The Service-Oriented Computing (SOC)
paradigm refers to the set of concepts,
principles, and methods that represent
computing in Service-Oriented Architecture
(SOA) in which software applications are
constructed based on independent
component services with standard interfaces.
 Software Engr/programming
The main idea of SOC/SOA is to explicitly
separate software engineering from
programming.

to emphasize on software engineering, and to

deemphasize on programming.

SOC separates software development into

three independent parties:
 Software Engr/programming
Application builders (by software
engineers),

service providers (by programmers),

and
service brokers (joint effort from
standard organizations, computer
industry, and government)
Engineering
 Engineering is …
 The application of scientific principles and methods
 To the construction of useful structures & machines
 Examples
 Mechanical engineering
 Civil engineering
 Chemical engineering
 Electrical engineering
 Nuclear engineering
 Aeronautical engineering
Software Engineering
 The term is 43 years old: NATO Conferences
 Garmisch, Germany, October 7-11, 1968
 Rome, Italy, October 27-31, 1969
 The reality is finally beginning to arrive
 Computer science as the scientific basis
 Other scientific bases?
 Many aspects have been made systematic
 Methods/methodologies/techniques
 Languages
 Tools
 Processes
 Software Engineering in a
Nutshell
 Development of software systems whose
size/complexity warrants team(s) of engineers
 multi-person construction of multi-version software
[Parnas 1987]

 Some questions to put SE in perspective:

What are the sizes of some typical software products?
Maple.exe = 1.3 Mbytes.-- System over 3.8 Mbytes
Netscape.exe = 1.26 megabytes.
Microsoft Office 97 > 180 megabytes.

How many people would it take to build these in 1 year? 2?

Software Engineering in a
Nutshell
What would you do if a bug could cost lives and $2 billion?

What would you do if a delay could cost $100’s of millions?

 Scope
 study of software process, development principles,
techniques, and notations
 Goal
 production of quality software, delivered on time, within
budget, satisfying customers’ requirements and users’ needs
Ever-Present Difficulties
 Few guiding scientific principles
 Few universally applicable methods
 As much
managerial / psychological / sociological
as technological
Why These Difficulties?
 SE is a unique brand of engineering
 Software is malleable
 Software construction is human-intensive
 Software is intangible
 Software problems are unprecedentedly complex
 Software directly depends upon the hardware
 It is at the top of the system engineering “food chain”
 Software solutions require unusual rigor
 Software has discontinuous operational nature
Software Engineering ≠
Software Programming
 Software programming
 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 Engineering ≠
Software Programming
 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
Software Engineering
Software Development Lifecycle
 A framework that describes the
activities performed at each stage of a
software development project.
 Software Development Lifecycle
Waterfall Model
Requirements Communication
Planning
Design
Modeling
Implementation Construction
Deployment
Integration

Validation

Deployment
Software Development Lifecycle
Waterfall Model
 Requirements – defines
needed information, function,
behavior, performance and
interfaces.
 Design – data structures,
software architecture, interface
representations, algorithmic
details.
 Implementation – source
code, database, user
documentation, testing.
Waterfall Strengths
 Easy to understand, easy to use
 Provides structure to inexperienced staff
 Milestones are well understood
 Sets requirements stability
 Good for management control (plan, staff,
track)
 Works well when quality is more important
than cost or schedule
Waterfall Deficiencies
 All requirements must be known upfront
 Deliverables created for each phase are
considered frozen – inhibits flexibility
 Can give a false impression of progress
 Does not reflect problem-solving nature of
software development – iterations of phases
 Integration is one big bang at the end
 Little opportunity for customer to preview the
system (until it may be too late)
When to use the Waterfall Model
 Requirements are very well known
 Product definition is stable
 Technology is understood
 New version of an existing product
 Porting an existing product to a new
platform.
Incremental SDLC Model
 Construct a partial
implementation of a total
system
 Then slowly add increased
functionality
 The incremental model
prioritizes requirements of the
system and then implements
them in groups.
 Each subsequent release of the
system adds function to the
previous release, until all
designed functionality has
been implemented.
Incremental Model Strengths
 Develop high-risk or major functions first
 Each release delivers an operational product
 Customer can respond to each build
 Uses “divide and conquer” breakdown of tasks
 Lowers initial delivery cost
 Initial product delivery is faster
 Customers get important functionality early
 Risk of changing requirements is reduced
 Incremental Model Weaknesses
 Requires good planning and design
 Requires early definition of a complete and
fully functional system to allow for the
definition of increments
 Well-defined module interfaces are
required (some will be developed long
before others)
 Total cost of the complete system is not
lower
 When to use the Incremental Model
 Risk, funding, schedule, program complexity, or
need for early realization of benefits.
 Most of the requirements are known up-front
but are expected to evolve over time
 A need to get basic functionality to the market
early
 On projects which have lengthy development
schedules
 On a project with new technology
V-Shaped SDLC Model
 A variant of the Waterfall
that emphasizes the
verification and validation
of the product.
 Testing of the product is
planned in parallel with a
corresponding phase of
development
 V-Shaped Steps
 Project and Requirements  Production, operation and
Planning – allocate resources maintenance – provide for
enhancement and corrections
 Product Requirements and  System and acceptance testing –
Specification Analysis – complete check the entire software system
specification of the software in its environment
system

 Architecture or High-Level Design  Integration and Testing – check

– defines how software functions that modules interconnect
fulfill the design correctly

 Detailed Design – develop  Unit testing – check that each

algorithms for each architectural module acts as expected
component
 Coding – transform algorithms
into software
V-Shaped Strengths
 Emphasize planning for verification and
validation of the product in early stages
of product development
 Each deliverable must be testable
 Project management can track progress
by milestones
 Easy to use
V-Shaped Weaknesses
 Does not easily handle concurrent
events
 Does not handle iterations or phases
 Does not easily handle dynamic
changes in requirements
 Does not contain risk analysis activities
When to use the V-Shaped Model
 Excellent choice for systems requiring
high reliability – hospital patient control
applications
 All requirements are known up-front
 When it can be modified to handle
changing requirements beyond analysis
phase
 Solution and technology are known
Software Development Lifecycle
Spiral Model
Spiral SDLC Model
 Adds risk analysis,
and 4gl RAD
prototyping to the
waterfall model
 Each cycle involves
the same sequence of
steps as the waterfall
process model
 Spiral Quadrant
Determine objectives, alternatives and constraints

Objectives: functionality, performance,

hardware/software interface, critical success factors,
etc.
Alternatives: build, reuse, buy, sub-contract, etc.
Constraints: cost, schedule, interface, etc.
 Spiral Quadrant
Evaluate alternatives, identify and resolve risks

 Study alternatives relative to objectives and

constraints
 Identify risks (lack of experience, new
technology, tight schedules, poor process, etc.
 Resolve risks (evaluate if money could be lost by
continuing system development
 Spiral Quadrant Spiral Quadrant
Develop next-level Develop next-level
product product

Typical activites:  Typical activities

Create a design  Develop project plan
Review design  Develop configuration
Develop code management plan
Inspect code  Develop a test plan
Test product  Develop an

installation plan
 Spiral Model Strengths
 Provides early indication of insurmountable risks,
without much cost
 Users see the system early because of rapid
prototyping tools
 Critical high-risk functions are developed first
 The design does not have to be perfect
 Users can be closely tied to all lifecycle steps
 Early and frequent feedback from users
 Cumulative costs assessed frequently
 Spiral Model Weaknesses
 Time spent for evaluating risks too large for small or
low-risk projects
 Time spent planning, resetting objectives, doing risk
analysis and prototyping may be excessive
 The model is complex
 Risk assessment expertise is required
 Spiral may continue indefinitely
 Developers must be reassigned during non-development
phase activities
 May be hard to define objective, verifiable milestones
that indicate readiness to proceed through the next
iteration
 When to use Spiral Model
 When creation of a prototype is appropriate
 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)
 Structured Evolutionary Prototyping
Model

Developers build a prototype during the

requirements phase
Prototype is evaluated by end users
Users give corrective feedback
Developers further refine the prototype
When the user is satisfied, the prototype code
is brought up to the standards needed for a
final product.
 Structured Evolutionary Prototyping
Steps
•A preliminary project plan is developed
•An partial high-level paper model is created
•The model is source for a partial requirements
specification
•A prototype is built with basic and critical attributes
•The designer builds
•the database
•user interface
•algorithmic functions
•The designer demonstrates the prototype, the user
evaluates for problems and suggests improvements.
•This loop continues until the user is satisfied
 Structured Evolutionary Prototyping
Strengths
 Customers can “see” the system requirements
as they are being gathered
 Developers learn from customers
 A more accurate end product
 Unexpected requirements accommodated
 Allows for flexible design and development
 Steady, visible signs of progress produced
 Interaction with the prototype stimulates
awareness of additional needed functionality
 Structured Evolutionary Prototyping
Weaknesses

 Tendency to abandon structured program

development for “code-and-fix” development
 Bad reputation for “quick-and-dirty” methods
 Overall maintainability may be overlooked
 The customer may want the prototype delivered.
 Process may continue forever (scope creep)
 When to use
Structured Evolutionary Prototyping
 Requirements are unstable or have to be
clarified
 As the requirements clarification stage of a
waterfall model
 Develop user interfaces
 Short-lived demonstrations
 New, original development
 With the analysis and design portions of object-
oriented development.
 Rapid Application Model (RAD)
 Requirements planning phase
 User description phase – automated tools
capture information from users
 Construction phase – productivity tools, such as
code generators, screen generators, etc
 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 costs
 Time-box approach mitigates cost and schedule
risk
 Customer involved throughout the complete
cycle minimizes risk of not achieving customer
satisfaction and business needs
 Focus moves from documentation to code
(WYSIWYG).
 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
 Requirements
 Problem Definition → Requirements Specification
 determine exactly what the customer and user want
 develop a contract with the customer
 specifies what the software product is to do
 Difficulties
 client asks for wrong product
 client is computer/software illiterate
 specifications are ambiguous, inconsistent, incomplete
 Architecture/Design
 Requirements Specification → Architecture/Design
 architecture: decompose software into modules with
interfaces
 design: develop module specifications (algorithms, data
types)
 maintain a record of design decisions and traceability
 specifies how the software product is to do its tasks
 Difficulties
 miscommunication between module designers
 design may be inconsistent, incomplete, ambiguous
Software Architecture
 The architecture of a system is a
comprehensive framework that
describes its form and structure, its
components and how they fit together.
 Why is Architecture Important?
 Architecture constitute a small intellectually
graspable model
 Enabler for communication btw all parties
(stakeholder and developers)
 Architectural styles and patterns
 Styles  Patterns
 Data centered  Concurrency
architecture  Persistence
 Data flow  Distribution
 Call and return
 Object oriented
 Layered
Architecture vs. Design
 Architecture is concerned with the selection of
architectural elements, their interactions, and
the constraints on those elements and their
interactions necessary to provide a framework
in which to satisfy the requirements and serve
as a basis for the design.
 Design is concerned with the modularization
and detailed interfaces of the design elements,
their algorithms and procedures, and the data
types needed to support the architecture and
to satisfy the requirements.
Software system modeling
 System models – Abstract descriptions of
systems whose requirements are being
analysed
 Formal methods – Techniques and notations
for the unambiguous specification of software
 Objectives
 To explain why the context of a system should be modelled
as part of the requirements engineering process
 To describe behavioural modelling, data modelling and
object modelling
 To introduce some of the notations used in the Unified
Modeling Language (UML)
 To introduce formal methods and formal modeling
approaches
 The Unified Modeling Language
 Devised by the developers of object-oriented analysis and design
methods
 Has become an effective standard for software modelling
 Has nine different notations State
StateClass
Diagrams
Use
UseCase Diagrams
Diagrams
Use Case UseCase
Case
Diagrams
State
State
Object
Use Case
Sequence Diagrams
Diagrams Diagrams
Diagrams
Diagrams
Diagrams Diagrams
Diagrams

Scenario
Scenario State
State
Collaboration
Diagrams Component
Diagrams
Diagrams Models Diagrams
Diagrams Diagrams

Scenario
Scenario
Component
Component
Statechart
Diagrams Deployment
Diagrams
Diagrams
Diagrams
Diagrams Diagrams
Activity
Diagrams
Software modeling and models
 Software modeling helps the engineer to
understand the functionality of the system
 Models are used for communication among
stakeholders
 Different models present the system from
different perspectives
 External perspective showing the system’s context or
environment
 Process models showing the system development process as
well as activities supported by the system
 Behavioural perspective showing the behaviour of the
system
 Structural perspective showing the system or data
architecture
Category of modeling elements
 Implementation & Integration
 Design → Implementation
 implement modules; verify that they meet their
specifications
 combine modules according to the design
 specifies how the software product does its tasks
 Difficulties
 module interaction errors
 order of integration may influence quality and
productivity
Component-Based
Development
 Develop generally applicable components of a
reasonable size and reuse them across
systems
 Make sure they are adaptable to varying
contexts
 Extend the idea beyond code to other
development artifacts
 Question: what comes first?
 Integration, then deployment
 Deployment, then integration
Different Flavors of
Components
 Third-party software “pieces”
 Plug-ins / add-ins
 Applets
 Frameworks
 Open Systems
 Distributed object infrastructures
 Compound documents
 Legacy systems
Verification and Validation
 Analysis
 Static
 “Science”
 Formal verification
 Informal reviews and walkthroughs
 Testing
 Dynamic
 “Engineering”
 White box vs. black box
 Structural vs. behavioral
 Issues of test adequacy
Deployment & Evolution
 Operation → Change
 maintain software during/after user operation
 determine whether the product still functions
correctly
 Difficulties
 rigid design
 lack of documentation
 personnel turnover
Configuration Management
(CM) [Tichy 1988]
 CM is a discipline whose goal is to
control changes to large software
through the functions of
 Component identification
 Change tracking
 Version selection and baselining
 Software manufacture
 Managing simultaneous updates (team
work)
Software Qualities
 Qualities (a.k.a. “ilities”) are goals in the
practice of software engineering
 External vs. Internal qualities
 Product vs. Process qualities
External vs. Internal Qualities
 External qualities are visible to the user
 reliability, efficiency, usability
 Internal qualities are the concern of
developers
 they help developers achieve external
qualities
 verifiability, maintainability, extensibility,
evolvability, adaptability
Product vs. Process Qualities
 Product qualities concern the developed
artifacts
 maintainability, understandability,
performance
 Process qualities deal with the
development activity
 products are developed through process
 maintainability, productivity, timeliness
Some Software Qualities
 Correctness
 ideal quality
 established w.r.t. the requirements specification
 absolute
 Reliability
 statistical property
 probability that software will operate as expected
over a given period of time
 relative
Some Software Qualities
(cont.)
 Robustness
 “reasonable” behavior in unforeseen
circumstances
 subjective
 a specified requirement is an issue of correctness;
an unspecified requirement is an issue of
robustness
 Usability
 ability of end-users to easily use software
 extremely subjective
Some Software Qualities
(cont.)
 Understandability
 ability of developers to easily understand
produced artifacts
 internal product quality
 subjective
 Verifiability
 ease of establishing desired properties
 performed by formal analysis or testing
 internal quality
Some Software Qualities
(cont.)
 Performance
 equated with efficiency
 assessable by measurement, analysis, and
simulation
 Evolvability
 ability to add or modify functionality
 addresses adaptive and perfective maintenance
 problem: evolution of implementation is too easy
 evolution should start at requirements or design
Some Software Qualities
(cont.)
 Reusability
 ability to construct new software from existing
pieces
 must be planned for
 occurs at all levels: from people to process, from
requirements to code
 Interoperability
 ability of software (sub)systems to cooperate with
others
 easily integratable into larger systems
 common techniques include APIs, plug-in
protocols, etc.
Some Software Qualities
(cont.)
 Scalability
 ability of a software system to grow in size
while maintaining its properties and
qualities
 assumes maintainability and evolvability
 goal of component-based development
Some Software Qualities
(cont.)
 Heterogeneity
 ability to compose a system from pieces developed in
multiple programming languages, on multiple platforms, by
multiple developers, etc.
 necessitated by reuse
 goal of component-based development
 Portability
 ability to execute in new environments with minimal effort
 may be planned for by isolating environment-dependent
components
 necessitated by the emergence of highly-distributed systems
(e.g., the Internet)
 an aspect of heterogeneity
Software Process Qualities
 Process is reliable if it consistently leads to high-
quality products
 Process is robust if it can accommodate
unanticipated changes in tools and environments
 Process performance is productivity
 Process is evolvable if it can accommodate new
management and organizational techniques
 Process is reusable if it can be applied across
projects and organizations
Assessing Software Qualities
 Qualities must be measurable
 Measurement requires that qualities be
precisely defined
 Improvement requires accurate
measurement
 Currently most qualities are informally
defined and are difficult to assess
Software Engineering
“Axioms”
 Adding developers to a project will likely result in
further delays and accumulated costs
 Basic tension of software engineering
 better, cheaper, faster — pick any two!
 functionality, scalability, performance — pick any two!
 The longer a fault exists in software
 the more costly it is to detect and correct
 the less likely it is to be properly corrected
 Up to 70% of all faults detected in large-scale software
projects are introduced in requirements and design
 detecting the causes of those faults early may reduce their
resulting costs by a factor of 100 or more