Dr D. Greer, Queens University Belfast (Email:[email protected] Chapter Two 1 Chapter Two Software Process Learning Outcomes Appreciate the need for

Dr D. Greer, Queens University Belfast (Email:[email protected] Chapter Two 1

Chapter Two

Software Process

Learning OutcomesAppreciate the need for a defined software process

Be able to describe in detail the main software process models

Be able to compare software process models and choose between them

Know about alternative approaches – agile and reengineering

Software Engineering


The software process

Structured set of activities required e.g. Specification, Design, Validation, Evolution

Activities vary depending on the organisation and the type of system being developed

Must be explicitly modelled if it is to be managed Process Characteristics

• Understandability• Visibility• Supportability• Acceptability• Reliability• Maintainability• Rapidity


Generic vs Software engineering process

Generic – building any product• Specification - set out requirements and constraints

• Design - Produce a paper model of the system

• Manufacture - build the system

• Test - check the system meets the required specifications

• Install - deliver system to customer and ensure it is operational

• Maintain - repair faults in the system as they are discovered

Software• Normally, specifications are incomplete / anomalous

• Very blurred distinction between specification, design and manufacture

• No physical realisation of the system for testing

• Software does not wear out - maintenance does not mean component replacement


Software process models

Waterfall model• Separate and distinct phases of specification and development

Prototyping Models Incremental Models

• Specification and development are interleaved• The Spiral model • Agile Methods

Formal transformation• A mathematical system model is formally transformed to an

implementation Reuse-based development

• The system is assembled from existing components


Waterfall model

Requirementsdefinition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation andmaintenance


Prototyping Model

Prototyping is used: 2 types• Evolutionary prototyping

» 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. Starts with poorly

understood requirements

Requirements are difficult to capture accurately! Prototype - a working model of part or all of the final system

» Use of high-level languages to create working programs quickly. Modern 4GLs are very suitable

» Prototype may be inefficient/ not as robust as final system/ less functionality


RequirementsGathering

Design

Implementation

Testing

Design

Implementation

Testing

Maintenance


Problems with Prototyping• Documentation may get neglected

• Effort in building a prototype may be wasted

• Difficult to plan and manage

Advantages• Faster than the waterfall model

• High level of user involvement from start

• Technical or other problems discovered early - risk reduced


Evolutionary Strategies

main purpose of software process model is “to give risk-reducing structure” [Ould, 1990].

growing recognition that in many cases software should be developed in an evolutionary fashion [e.g. McConnell, 1993]

e.g. Microsoft Visual C++ is shipped every 4 months Strategies

• Evolutionary Prototyping• Incremental (Staged) Delivery• Design-to-Schedule• Evolutionary Delivery

Ould, M.A., Strategies for Software Engineering: The Management of Risk and Quality, John Wiley, NY, 1990.

McConnell, S., Rapid Development: Taming Wild Software Schedules, Microsoft Press, Redmond, WA, 1996


Evolutionary Prototyping

Initial Concept

Design and

implement initial

prototype

Refine prototype

until acceptable

Complete and

release prototype

final product

Build prototype and evolve software from itPrototype typically the user interface, but may be any high-risk

area of the system. Evolutionary prototyping especially useful

when requirements are changing rapidlywhen the customer is reluctant to commit to a set of requirements when there is a lack of understanding of what is required [when the developer is unsure of which technical solution to use.


Problems with Evolutionary Prototyping• Difficult to plan as amount of effort is uncertain

• Documentation may be neglected

• Could degenerate into “Build and Fix” with poorly structured code

• Languages which are good for prototyping not always best for final product

Advantages• Effort of prototype is not wasted

• Faster than the waterfall model

• High level of user involvement from start

• Technical or other problems discovered early - risk reduced


Incremental (staged) Delivery

Software concept

Requirements Analysis

Architectural Design

Stage 1: Detailed design, code, debug, test and delivery


Stage n: Detailed design, code, debug, test and delivery

Differs from Evolutionary Prototyping

in that requirements are

fully known at the start


Mechanism• requirements gathered in initial stages

• overall architectural design is determined

• requirements met in successive stages of the project

• users get part of the functionality delivered at an early stage (As in evolutionary prototyping)

Problems• Needs careful planning - stages have interdependencies

• If not planned well - extra effort in interfacing stages

• Users may tire of constant changes

• funding may be difficult to obtain for a succession of changes


Design-to-Schedule

Software concept



High Priority: Detailed design, code, debug, test

Medium-High Priority: Detailed design, code, debug, test

Medium Priority: Detailed design, code, debug, test

Medium-Low Priority: Detailed design, code, debug, test

Low Priority: Detailed design, code, debug, test

Release

run out of time/money

n

Stages prioritised lower prioritylast. Thus if

deadline or budgetis reached before product finishedlowest priority

stagescan be omitted.

Note: Variation onIncremental Model


Incremental and Iterative Delivery

(Tom Gilb, 1988 – he called it “evolutionary”/ “evo”)

Software concept





Stage n: Detailed design, code, debug, test and delivery

evaluate & feedback

evaluate & feedback

evaluate & feedback

Gilb, T., Principles of Software Engineering Management, Addison-Wesley, 1988

Each stage is VALUABLE!

Architecture at each stage Must be OPEN = easy

to change and add to


Incremental and Iterative Delivery

Initial Objectives

Initial course

New Objectives

Revised course

CHANGE


Agile Methods

http://agilemanifesto.org/ and http://www.martinfowler.com/articles/newMethodology.html

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Candidates: XP (Extreme Programming), Cockburn's Crystal Family, Open Source, Highsmith's Adaptive Software Development, Scrum, Feature Driven Development, DSDM (Dynamic System Development Method)


What is Extreme Programming

Things we know from Software Engineering:

Software Eng. Practice XP Principles

Code Reviews are good Review code all the time

Testing is good Everybody tests all the time

Design is good Part of daily business

Simplicity is good Always have the simplest design that does the job

Architecture is important Everybody works in refining architecture

Integration Testing is important

Continuously integrate and test

Short Iterations are good Make iterations really short

Pair Programming

Unit and functional tests

Refactorin g

Simplest Design that works

Use of a metaphor

Continuous Integration

The Planning Game


What is XP?

A lightweight, efficient, low-risk, flexible,predictable, scientific and fun way to develop software (Kent Beck)

‘lightweight’ being replaced by the term ‘agile’

4 Values• Communication

» Unit testing, pair programming, task estimation done with > 1 person

• Simplicity» XP coach asks “What is the simplest thing that could possibly work?”

• Feedback» Each task feeds back to the instigator, early deliverables

• Courage» E.g. Throwing code away, refactoring, trying out new ideas


XP – Overview of the 12 Practices

The Planning Game• Business People: Scope, Priority, Composition of releases, Dates of

releases• Technical People: Estimates, Consequences of choices, Process, Detailed

Scheduling Small Releases

• Sensible but reduce cycle as much as possible Metaphor

• Similar to ‘architecture ‘ but for non-technical too e.g see system as contracts and customers

Simple Design• Runs all the tests, No duplicated logic, all the required bits, fewest

classes and methods


Collective Ownership• Everyone owns and can improve the code

Continuous Integration• Code integrated and tested after a few hours-1 day• Run the tests until they work

40 hour week• max

On site customer• (real) customer sits with team

Coding Standards• Same indentation, layout etc• Least amount of work possible


Testing• Tests are written before the code

• Test run (automated) frequently (after all changes)

• Customers provide acceptance tests

Pair Programming• One person has keyboard, other checks and suggests

Refactoring• XP teams improve the software throughout development process


Software Reengineering

What? - Re-structuring or re-writing part or all of a legacy system without changing its functionality

When? • When some but not all sub-systems of a larger system require frequent

maintenance• When hardware or software support becomes obsolete

How? • The system may be re-structured and re-documented to make it easier to maintain

Why• Reduced risk

» New software development carries high risk.

• Reduced cost» The cost of re-engineering is often significantly less than the costs of developing new

software


Forward engineering and re-engineering

Understanding andtransformation

Existingsoftware system

Re-engineeredsystem

Design andimplementation

Systemspecification

Newsystem

Software re-engineering

Forward engineering

Automated program conversionAutomated program restructuringManual Program and Data RestructuringRestructuring plus Architectural Changes

cost


Reverse engineering

Analysing software to gain an understanding of its design and specification May be part of a re-engineering process or to re-specify a system for re-

implementation Builds a program data base and generates information from this Program understanding tools (browsers, cross-reference generators, etc.) may

be used in this process Why?

• Original code may have been written under limitations which no longer apply e.g. memory needs, performance etc

• Maintenance tends to corrupt the structure of a program. It becomes harder and harder to understand

• The program may be automatically restructured to remove unconditional branches or complex conditional statements


Chapter Two

Software Process

Learning OutcomesAppreciate the need for a defined software process

Be able to describe in detail the main software process models

Be able to compare software process models and choose between them

Know about alternative approaches – agile and reengineering

Software Engineering

Documents

Dr D. Greer, Queens University Belfast (Email:[email protected] Chapter Two 1 Chapter Two Software Process Learning Outcomes Appreciate the need for