CSC 480 Software Engineering Lecture 2 August 26, 2002.

CSC 480Software Engineering

Lecture 2August 26, 2002

CSC 480 Software Engieering 28/26/2002

Topics

Overview Process models Iterative models


Process

A process is a partially ordered steps to achieve a goal

In software engineering, your goal is toEfficiently and predictably deliver a software

product that meets the need of your businessWhat are the steps? In what order?

There is not one single answer to all cases


Some Application Types

Stand-alone residing on a single computer e.g., word processor

Distributed consist of parts interacting across a network e.g., Web-based video game

Embedded part of unique application involving hardware e.g., automobile controller

Real-time functions must execute within small time limit (typically micro-sec) e.g., radar software


Trends & Influences

Structured programming Object-Orientation Reuse and components Formal methods


Structured Programming

Use control constructs, avoid using gotoA hierarchy of functions, with those in higher

levels calling those at lower levelsModules tend to couple with each other,

making change difficult


Object-Orientation

Encapsulate data and functionality in objectsMapping to real-world entities

Both congregation and inheritance hierarchies

Easier to modify and add components


Class & Object Hierarchies


Reuse & Components

Reuse can reduce cost and improve quality

Reuse at component level is more effective

COM JavaBeans

Example – a JClass chart by sitraka.com


Formal Methods

SE methods that rely on mathematics as their base are called formal methods.

The logical, not the computational aspects are used

Requirements and design can be express more precisely

Domain element A

Range element A(x)

1 4

2 6

3 3

4 4

5 6

6 8

t, t´ : N N

dom(t´) = dom(t) rng(t´) = rng(t) x, y dom(t), x y t´(x) t´(y) x rng(t´), card[ t´-1(x) ] = card[ t-1(x) ]

SortPartial function

Range of t

Number ofelements in the set ...

Set of elementsmapped onto x by t

“implies”


A Typical S.E. Roadmap1. Understand nature & scope of proposed product

2. Select the development process, and create a plan

4. Design and build the product

6. Deliver and maintain the product

3. Gather requirements

5. Test the product Activities commonly found in all projects


Five Key Expectations (Humphrey)

Influencedby people

Used forprocess development

Part oftheproject

Aspectof the product

3. Keep all work visible

5. Measure quality

4. A. Design onlyagainst requirements

B. Programonly against designsC. Test only against

requirements and designs

1. Predetermine quantitative quality goals

2. Accumulate data for subsequent use


Software Process Models

A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective


Process Models The waterfall model

Separate and distinct phases of specification and development

Evolutionary development Specification and development are interleaved

Formal systems development A mathematical system model is formally transformed to an

implementation

Reuse-based development The system is assembled from existing components


Waterfall ModelRequirements

definition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation andmaintenance


The Waterfall Model

Requirementsanalysis

Design

Implementation

Integration & Test

Produces … specification

... diagrams & text

... code & comments

... test report for entire code

Operation & Maintenance... user manual & enhancements


Waterfall Model Phases Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance The drawback of the waterfall model is the

difficulty of accommodating change after the process is underway


Waterfall Model Problems

Inflexible partitioning of the project into distinct stages

This makes it difficult to respond to changing customer requirements

Therefore, this model is only appropriate when the requirements are well-understood


More Detailed Waterfall Version

Design

Implementation& unit testing

Integration

System testing

Conceptanalysis

Analysis

Maintenance


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

Throw-away prototyping Objective is to understand the system

requirements. Should start with poorly understood requirements


Evolutionary Development

ValidationFinal

version

Development Intermediateversions

Specification Initialversion

Outlinedescription

Concurrentactivities


Evolutionary Development Problems

Lack of process visibility Systems are often poorly structured Special skills (e.g. in languages for rapid prototyping)

may be required Applicability

For small-/medium-size interactive systems For parts of large systems (e.g. the UI) For short-lifetime systems


Formal Systems Development

Based on the transformation of a mathematical specification through different representations to an program

Transformations are ‘correctness-preserving’ so it is straightforward to show that a program conforms to its specification

Embodied in the ‘Cleanroom’ approach to software development



Requirementsdefinition

Formalspecification

Formaltransformation

Integration andsystem testing


Formal Transformations

R2Formalspecification R3 Executable

program

P2 P3 P4

T1 T2 T3 T4

Proofs of transformation correctness

Formal transformations

R1

P1



Problems Need for specialised skills and training to apply

the technique Difficult to formally specify some aspects of the

system such as the user interface Applicability

Critical systems especially those where a safety or security case must be made before the system is put into operation


Reuse-Oriented Development

Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems

This approach is becoming more important but still limited experience with it


Reuse-Oriented Development

Requirementsspecification

Componentanalysis

Developmentand integration

System designwith reuse

Requirementsmodification

Systemvalidation

Process stagesComponent analysisRequirements modificationSystem design with reuseDevelopment and integration


Process Iteration (iterative models)

System requirements ALWAYS evolve in the course of a project so process iteration where earlier stages are reworked is always part of the process for large systems

Iteration can be applied to any of the generic process models


Incremental Development Rather than deliver the system as a single

delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality User requirements are prioritised and the highest

priority requirements are included in early increments Once the development of an increment is started, the

requirements are frozen though requirements for later increments can continue to evolve


Incremental Development

Valida teincrement

Develop systemincrement

Design systemarchitecture

Integrateincrement

Valida tesystem

Define outline requirements

Assign requirements to increments

System incomplete

Finalsystem


Iteration No.

Analyzerequirements

Test whole

Implement

Design

Test units

Integrate

1 2 3 867 868

Update SRS3

Update SDS2

Update source code

Update Test documentation

Update SPMP1

1 Software Project Management Plan; 2 Software Design Specification;3 Software Requirements Specification


Incremental Development

Advantages Customer value can be delivered with each

increment so system functionality is available earlier

Early increments act as a prototype to help elicit requirements for later increments

Lower risk of overall project failure The highest priority system services tend to

receive the most testing


Extreme Programming

New approach to development based on the development and delivery of very small increments of functionality

Relies on constant code improvement, user involvement in the development team and pairwise programming


Spiral Development

Process is represented as a spiral rather than as a sequence of activities with backtracking

Each loop in the spiral represents a phase in the process.

No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required

Risks are explicitly assessed and resolved throughout the process


The Spiral Model

Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis Proto-

type 1

Prototype 2Prototype 3

Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

CodeUnit test

IntegrationtestAcceptance

testService Develop, verifynext-level product

Evaluate alternativesidentify, resolve risks

Determine objectivesalternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-cycle plan

REVIEW


The Spiral Model


Spiral Model Sectors Objective setting

Specific objectives for the phase are identified Risk assessment and reduction

Risks are assessed and activities put in place to reduce the key risks

Development and validation A development model is chosen

Planning The project is reviewed and the next phase of the spiral is

planned


Process Trade-offs

Factor Pure Waterfall

Iterative

Spiral

Iterative

Incremental

Ease of doc control

Easier Harder Harder/Medium

Enabling of customer interaction

Harder Easier Easier

Promotion of good design

Medium/Easier

Easier Harder

Leverage of metric data

Harder Medium/Easier

Medium/Easier

Date post:	18-Jan-2016
Category:	Documents
Upload:	nelson-douglas
View:	218 times
Download:	1 times

CSC 480 Software Engineering Lecture 2 August 26, 2002.

Documents