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.