Software Engineering
Download
Report
Transcript Software Engineering
CS565 Advanced Software Development
Software Development Process
A. O’Riordan, 2006, 2007
Software Engineering as a Discipline
the methodology, techniques and tools related to the development
and management of software from conception through requirements
identification, design, implementation, deployment to the final
retirement.
Software Engineering is relatively new field of engineering
term software engineering was coined in 1967 at a NATO study group
first conference held at Garmisch-Partenkirchen, Germany, 7th to 11th
October 1968
An Engineering Approach
software production should be an engineering-like activity
up to that point software was primarily developed in an ad hoc
manner - low-level assembler
it is commonly perceived that the quality of software is
not acceptable
buggy and behind schedule
not enough reuse - either code or design
no rigorous measurable process
A Test-based Approach
A methodology of validation and verification was called for
but classical proof-based techniques developed by Dijkstra
and others where proving too restricting and unwieldy.
Therefore
Formal proof is dispensed with, and a great effort invested
instead in testing.
But
More mature disciples such as architecture work without
large-scale testing, relying instead on careful application
of design principles and good practice.
Software Crisis
software crisis - Frederick Brookes, "No Silver Bullet”,
Information Processing 1986.
Brookes identified inherent problems associated with software
production which are caused by the nature of software itself
essence (unavoidable problems) and accidents (could engineer
solutions to these)
essence of software comprises:
complexity
conformity
changeability
invisibility.
Example: Invisibility
A number of reports called into question the verifiability
and “undebuggability” of large systems: Parnas’
evaluation let to his resignation from the SDI Panel on
Computing in Support of Battle Management.
e.g. software in not manufactured in the traditional sense
what are the raw materials?
how to visualize?
Software is principally based on ideas, abstractions and
design patterns.
Software Failure
Because of the durability of this crisis, Pressman says that
the software crisis should more properly be called a
chronic affliction.
Large-scale disasters attributed to software defects offer
sober warnings:
The explosion of the Ariane 5 rocket shortly after takeoff
Patriot missile failure during the Gulf War
Proposals to Solve Software Crisis I
high-level languages
structured design
e.g. UML (Unified Modeling Language), C++, Java
CASE (computer assisted software engineering)
e.g. SSADM (Structured Systems Analysis and Design)
object orientation
compilers for languages such as Fortran, COBOL, C, etc.
e.g. drawing tools, data dictionary
quality assurance
testing, ISO 9000, process maturity
Proposals to Solve Software Crisis II
4GLs and scripting
Components
e.g. Microsoft .NET, J2EE (Java 2 Enterprise Edition)
Web programming and services
e.g. SQL (Structured Query Language), Javascript
e.g. XML (eXtensible Markup Language), PHP (PHP: Hypertext
Preprocessor)
intelligent agents and AI
e.g. knowledge representation, user modelling
but none have been entirely successful!
Example: Software Components
Most software is currently custom built, as opposed to
being assembled from small encapsulated components.
For example in electrical engineering, an engineer rarely builds all
the circuits from scratch. Preexisting component circuits are
selected offtheshelf and assembled for the new purpose.
Software is moving towards this componentbased
assembly as the discipline matures.
Technologies such as object orientation, design patterns, etc. are
leading to this type of design. Components allow reusable units to
be deployed, e.g. web browser plug-ins
The Software Development Lifecycle
A large software application can be seen as having the
following development steps:
Requirements Specification
System Architecture
Customer and developer work together to identify actual problems for
which a solution is sought - feasibility of endeavour may also be accessed
A broad system specification of What is to be done – identify major
subsystems and approach
Design
Produce a design specification for the new system - alternative ways of
satisfying the specification may be explored - this is the How
The Software Development Lifecycle II
Implementation
System Integration
The completed system is assembled and tested
Maintenance
Chosen design translated into executable programs – build program code,
databases, etc.
Manage the day-to-day support of system operation as well as provision
of any future upgrades
Retirement
Product replaced or removed from service
Lifecycle Models
Waterfall
simpler
Evolutionary
Spiral
more complex
Waterfall Model
Requirements
definition
System and
software design
Implementation
and unit testing
Integr ation and
system testing
Operation and
maintenance
Characteristics of Waterfall Model
Consists of a set of phases that a project progresses through in a
sequential order.
Each phase must be completed before the project can progress to the
next phase.
At the end of each phase is some form of gateway, usually a formal
review where that decision is made.
There is no overlap between phases.
Characteristics of Waterfall Model II
It is straightforward, simple to understand and use.
Deliverables are frozen at the end of each phase and serve as a
baseline for the following phases.
You do not see the software until the end of the project (big bang
software development).
Changes are not supposed to happen or are limited or are tightly
controlled.
Evolutionary Model
Concurr ent
activities
Outline
description
Specification
Initial
version
Development
Intermediate
versions
Validation
Final
version
Evolutionary Model Characteristics
Exploratory prototyping - Objective is to work with customers and to
evolve.
Applicable for
small or medium-size interactive systems
for parts of large systems (e.g. the user interface)
for short-lifetime systems
Allows you to put functional software into the hands of the customer
much earlier than either the waterfall.
Requires careful planning at both the project management level and
the technical level.
Spiral Model
Determine objectives
alternatives and
constraints
Risk
analysis
Evaluate alternatives
identify, resolve risks
Risk
analysis
Risk
analysis
REVIEW
Requirements plan
Life-cycle plan
Development
plan
Plan next phase
Integration
and test plan
Prototype 3
Prototype 2
Risk
analysis Prototype 1
Operational
protoype
Simulations, models, benchmarks
Concept of
Operation
S/W
requirements
Requirement
validation
Product
design
Detailed
design
Code
Unit test
Design
V&V
Integr ation
test
Acceptance
test
Develop, verify
Service
next-level product
Spiral Model Characteristics I
Developed by Barry Boehm. "A Spiral Model of Software Development
and Enhancement", Computer, May 1988
A risk-oriented software life cycle.
Each spiral addresses major risks that have been identified.
After all the risks have been addressed, the spiral model terminates as
a waterfall software life cycle.
Spiral Model Characteristics II
You start small, explore the risks, develop a plan to deal with the
risks, and then commit to an approach for the next iteration.
Each iteration involves six steps:
Determine objectives, alternatives, and constraints.
Identify and resolve risks.
Evaluate alternatives.
Develop deliverables and verify that they are correct.
Plan the next iteration.
Commit to an approach for the next iteration.