software engineering - lecture 02

Software Engineering

Course Code: 331Lecture 02

“What happens in the ‘life’ of software”

Software Life Cycle

A structured set of activities required to develop a

software system. Many different software processes but all involve:

Specification – defining what the system should do; Design and implementation – defining the organization of

the system and implementing the system; Validation – checking that it does what the customer wants; Evolution – changing the system in response to changing

customer needs. A software process model is an abstract representation of

a process. It presents a description of a process from some particular perspective.

The software process

The waterfall model

Plan-driven model. Separate and distinct phases of specification and development.

Incremental development Specification, development and validation are interleaved.

May be plan-driven or agile. Reuse-oriented software engineering

The system is assembled from existing components. May be plan-driven or agile.

In practice, most large systems are developed using a process that incorporates elements from all of these models.

There are no right or wrong software processes.

Software process models

Code and Fix (1950–)

No process steps – no specs, docs, tests… No separation of concerns – no teamwork No way to deal with complexity

Code and Fix: Issues

Waterfall Model (1968)

Communication

The classic life cycle - oldest and most

widely used paradigm Known as “Linear sequential model” Activities ‘flow’ from one phase to

another If there are corrections, return to a

previous phase and ‘flow’ from there again

Major advantages: Good for planning and well-defined/repeated projects

Characteristics

Real projects rarely follow a sequential

flow Hard to state all requirements explicitly No maintenance or evolution involved Customer must have patience Any blunder can be disastrous Leads to “blocking states”

Drawbacks

Boehm’s first law

Problem Cost

Incremental Model

Each linear sequence produces a particular

“increment” to the software First increment typically core product; more

features added by later increments Allows flexible allocation of resources

Incremental Model

Software separated into different “increments”

- complete working portions Focus on delivery of operational product with

each increment - can be evaluated Useful when insufficient staff and can be

planned to manage technical risks, e.g. waiting for new hardware

Characteristics

The cost of accommodating changing

customer requirements is reduced. It is easier to get customer feedback on the

development work that has been done. More rapid delivery and deployment of useful

software to the customer is possible.

Benefits

The process is not visible.

Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system.

System structure tends to degrade as new increments are added. Unless time and money is spent on refactoring to

improve the software, regular change tends to corrupt its structure. Incorporating further software changes becomes increasingly difficult and costly.

Drawbacks

Prototyping

Prototypes

Horizontal Prototype

Vertical Prototype

A horizontal prototype tests a particular

layer (typically the GUI) of the system A vertical prototype tests a particular

functionality across all layers

Prototypes

Developer and customer determine objectives

and draft requirements Prototype quickly produced and evaluated by

customer Prototype then refined, and re-evaluated Process iterated, before final product

development Advantages: Customer participation and

better requirements

Characteristics

Customer may see prototype as working

model and expects fast results Developer compromised when producing

prototype quickly, e.g. different operating system or programming language

Drawbacks

Spiral Model (1988)

System is developed in series of evolutionary

releases Milestones for each iteration of the spiral Process does not end with delivery Reflects iterative nature of development

Spiral Model

Originally proposed by Boehm, couples

iterative nature of prototyping and the systematic aspects of waterfall model

Software is developed in series of incremental releases

Each iteration produces a more complete product

Better management through risk analysis(Modeling)

Characteristics

May be difficult to convince customers that

evolution is controllable Demands risk assessment expertise - major

risk will cause problems if not identified Relatively new and not widely used - cannot

determine performance

Drawbacks

Unified Process (1999)

Draws on best features of conventional

process models Emphasizes software architecture and design Integrates with UML modeling techniques

(more on this later)

Unified Process

Fourth Generation Techniques (4GT)

"Design" Strategy

Testing

Requirements gathering

Implementation using 4GL

4GT Characteristics

Use of software tools that allow software engineer to specify s/w characteristics at higher level

The tools generate codes based on specification

More time in design and testing - increase productivity

Tools may not be easy to use, codes generated may not be efficient

Software processes are the activities involved in producing a software system.

Software process models are abstract representations of these processes.

General process models describe the organization of software processes. Examples of these general models include the ‘waterfall’ model, incremental development, and reuse-oriented development.

Requirements engineering is the process of developing a software specification.

Design and implementation processes are concerned with transforming a requirements specification into an executable software system.

Software validation is the process of checking that the system conforms to its specification and that it meets the real needs of the users of the system.

Software evolution takes place when you change existing software systems to meet new requirements. The software must evolve to remain useful.

End

Key points