F28SD2 Software Design Overview of Software Processes Monica Farrow EM G30 Material available on...

F28SD2 Software Design

Overview of Software Processes

Monica Farrow

EM G30 [email protected] available on Vision

mailto:[email protected]

01/13/09 F28SD Software Design 2

Introduction to the module In this module we start to look at the

development of software engineering projects, initially focussing on design Software processes – an overview - today Architectural, functional and object-oriented

design Unified Modelling Language

Industry standard for object-oriented modelling Verification and validation Testing (CS students) Feasibility studies (IS students) Looking ahead


The software process The software process is :

A structured set of the activities required to develop a software system

Specification; Design; Validation; Evolution. Sommerville

A framework for the tasks that are required to build high-quality software Pressman

A process defines who is doing what, when and how to reach a certain goal Jacobson, Booch, Rumbaugh


Software engineering Software engineering encompasses

software processes as well as the associated technologies – technical methods and automated tools.

The software engineering module in 3rd year continues the study of the processes and technologies


Essential difficulties of software engineering

In 1987 Fred Brooks published a paper “No Silver Bullet”, in which he stated that building software will always be hard because of Complexity.

Each project is different to the last, with large numbers of statements. It’s not like designing one car and building lots of them.

Simplified models lose some essential properties of the project.

Leads to problems in communication and management

And....


Essential difficulties of software engineering

Conformity Software must conform to existing systems and

legislation. Changeability

External causes dictate the need for change, or people discover new uses for the product

Invisibility Software cannot be visualised. Although diagrams can

be drawn, it is not possible to show all aspects simultaneously.

This paper has been much discussed, but these essential difficulties remain.


Problems with software systems Dec 2008 Department for Transport

“the computer system was inadequately procured and tested, and that staff do not trust it”

Connecting for Health Electronic records for every patient. 2yrs behind

schedule, costs twice as much as originally planned.

Student Loans 2004 New system could not cope with volume of

enquiries Ministry of Defence 1990s

£34 billion spent on a system which was never used (too incompatible)


Process improvement The desire for improvement of process has

led to a number of models of the software construction process.

Most divide it into stages or phases, with a notion of progress towards a satisfactory

product and feedback and iteration to improve or correct at

each stage. The most famous of these is the waterfall

lifecycle model originally proposed by Royce.


Waterfall process modelRequirements capture

System and software design

Implementation and unit testing Integration

and system testing

Operation and maintenance

You’ll find slightly differentversions elsewhere.


Waterfall comments Had its roots in 1970s when we felt an engineering

discipline was vital to developing software. When Royce proposed it he didn’t call it waterfall and it had

feedback loops in it to encourage his visionary notion of “do it twice”, later echoed by Brooks.

Accountants love waterfall without loops as it provides clear contractual milestones and deliverables to hold people accountable against.

Projects are seldom so clear-cut and linear. Most require some iteration. W/Fall is often modified

with arrows back to any stage to show this.


Waterfall criticisms It’s usually late in the project before a working

version is available for user to test and criticise. Misunderstandings are not discovered until nearly

complete and the problems are expensive to fix. The earlier an issue is identified, the smaller the

cost. Errors detected in testing phase may be 50 times

more costly to fix than if they were detected during requirements or design phases.

However, the modified version is useful when the requirements are well-understood and are unlikely to change radically during development


Project costs For conventional projects,

typically 2% of budget is spent on

requirements, 4% on specification, 1% on planning, 6% on design, 20% on implementation, and 67% on maintenance

including correction of defects (11%).

RequirementsSpecificationPlanningDesignImplementationMaintenance


Generic software process models The waterfall model

Separate and distinct phases of specification and development.

Evolutionary development Specification, development and validation are

interleaved. Component-based software engineering

The system is assembled from existing components.

There are many variants of these models


The Role of Prototyping Engineers frequently build working models,

or prototypes to help them understand clients' requirements and jointly explore possible solutions. Here is a prototype

for a fold-out mobile phone,to enable easy video-watching

8 Jan 2009


The Role of Prototyping The problems faced by software engineers are no

less complex than the problems faced by other engineers

So prototypes enable software engineers to understand the problem domain and the user requirements

Prototypes imply user involvement, evaluation, feedback and iteration in the development process

As communication between the engineers and the users improves, a better understanding of user requirements and technological constraints is achieved.


Evolutionary development 2 fundamental types

Exploratory development Work with the customer Develop well understood sections Evolve by adding in new features

Throwaway prototyping Experiment with poorly understand customer

requirements Prototypes may not evolve into final system

Difficult to measure progress Systems can be poorly structured More suitable for small projects A mix of approaches works best.


Component-based software engineering

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

Process stages Component analysis; Requirements modification; System design with reuse; Development and integration.

This approach is becoming increasingly used as component standards have emerged.


Process iteration 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.

Two (related) approaches Incremental delivery; Spiral development.


The “Hanging Rope” Analogy

Iterative Delivery

Waterfall

Quality

Time


Incremental delivery 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 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.


Boehm’s spiral model


BOEHM'S Spiral Model

Demonstrates incremental development and delivery, iteration, evaluation and feedback

The project moves continually from planning of the next increment, to risk assessment, through implementation and evaluation.

PM can terminate project at any point, while ensuring that the user gains some benefit from each increment.


BOEHM'S Spiral Model

Focuses on prototyping and formalises an evolutionary approach to software development

Requires an explicit risk analysis during each cycle.

User involvement throughout the development process.

Validation and prioritisation of requirements. Tends to work best for small projects.


Rapid Application Development The Rapid Application Development (RAD)

process was initiated in the 1990s for projects with a rapidly changing business environment, where it is often impossible to arrive at a stable, consistent set of system requirements.

In these cases, a waterfall model of development is impractical. An approach to development based on iterative specification and delivery is the only way to deliver software quickly.


Characteristics of RAD processes The processes of specification, design and

implementation are concurrent. There is no detailed specification and design documentation is minimised.

The system is developed in a series of increments. End users evaluate each increment and make proposals for later increments.

System user interfaces are usually developed using an interactive development system.


Advantages of incremental development

Accelerated delivery of customer services. Each increment delivers the highest priority

functionality to the customer.

User engagement with the system. Users have to be involved in the

development which means the system is more likely to meet their requirements and the users are more committed to the system.


Problems with incremental development

Management problems Progress can be hard to judge and problems hard to find

because there is no documentation to demonstrate what has been done.

Contractual problems The normal contract may include a specification; without

a specification, different forms of contract have to be used.

Validation problems Without a specification, what is the system being tested

against? Maintenance problems

Continual change tends to corrupt software structure making it more expensive to change and evolve to meet new requirements.


Agile methods Dissatisfaction with the overheads

involved in design methods led to the creation of ‘agile’ methods. These methods : Focus on the code rather than the design;

feedback from people rather than planning Are based on an iterative approach to software

development; Are intended to deliver working software

quickly and evolve this quickly to meet changing requirements.


Agile methods Agile methods are probably best suited to

small/medium-sized business systems or PC products.

There are several different agile methods, of which Extreme Programming (XP) is one of the best known.


Extreme programming Takes iterative development to extreme

lengths Fast production of code in an efficient and

intense manner that also allows changes in requirements to be quickly reflected in the system.

Emphasis on speed and simplicity Uses Test Driven Development

Writes tests first then code Uses pair programming Involves constant refactoring of the code Customer is deeply involved


Key points so far Software processes are the activities

involved in producing and evolving a software system.

General activities are specification, design and implementation, validation and evolution.

Generic process models describe the organisation of software processes. Examples include the waterfall model, evolutionary development and component-based software engineering.


Key points so far Iterative process models describe the

software process as a cycle of activities. Rapid Application Development, including

Agile processes, have concurrent specification, design and implementation.

There is no ideal process model. Choice varies according to the type of application and the people involved.

These notes mostly from Sommerville SE8 ch 4 & ch 17


Information Systems lifecycle We have seen various types of software lifecycle

Waterfall, spiral, agile... These

concentrate on design and implementation of a software system

models lack an overall picture of the organisation and its business processes

A traditional structured design method extended in this manner is shown next

(Based on Avison and Shah) The similarities are clear So are the new features


Information Systems lifecycle

After Avison and Shah p71

ISplanning

Feasibility study

Systemsinvestigation

Systemsanalysis

Systemsdesign

Implementation

Reviewand

maintenance

Managerialdirective

New businessopportunities

Problems withexisting system

Feasibilitystudy report

Projectplans

Userrequirements

Staffassignment

Resourcerequirements

Methodsand tools

Currentsystem

data flow

New systemdata flow

Programs

Evaluationreport

Systemrequirements

Systemspecification

Training andtest plans

Procedures Documentation

New problemstatement?

New systemin operation


What’s similar? Stages rather like waterfall

Repeats with review like spiral

Progress in terms of artefacts


What’s added? Feasibility study

Review during maintenance

System is an open one

Operation feeds back to design


Feasibility study

Propose and evaluate alternatives Establish priorities Gather information Perform cost-benefit analysis Form options for computerisation Present conclusions

The negative option is a valid option!


Review during maintenance Learning from experience Effectiveness of the solution

Correctness of function Efficiency Suitability for the business process

Effectiveness of the process Kept to time? Kept to budget? Lessons learned for future developments


System is an open one Take account of influences from the

organisation which change over time Managerial directives

often arbitrary but often dominate decision making

New opportunities business process change requires system change

Longer term information systems planning system change to maintain business process


Operation feeds back to design Operation reveals errors - “maintenance” in

SE Operation reveals bottlenecks for the business Operation reveals new opportunities for

business Operation reveals difficulties for users

Summary : from the original ‘build a system then hand it over’ approach, we must be now more aware of the user and their environment.


Next

Andrew on Wednesdays NO tutorial session this Thursday 3 Tue lectures on UML

Diagrammatic language to model requirements, actions, states, classes....

F28SD2 Software Design Overview of Software Processes Monica Farrow EM G30 Material available on...

Documents

Transcript of F28SD2 Software Design Overview of Software Processes Monica Farrow EM G30 Material available on...