CS计算机代考程序代写 flex finance Excel Software Construction & Design 1

Software Construction & Design 1

The University of Sydney Page 1

Agile Software

Development Practices
SOF2412 / COMP9412

Software Development Process

Models

School of Computer Science

Dr. Basem Suleiman

The University of Sydney Page 2

Agenda

– Software Engineering
– Software Development

– Introduction
– Software processes

– Software development process models

– Agile Development Model

– Agile development Values and Principles

The University of Sydney Page 3

Software Engineering

What and Why?

The University of Sydney Page 4

• Societies, businesses and governments dependent on SW systems

• Power, Telecommunication, Education, Government, Transport, Finance, Health

• Work automation, communication, control of complex systems

• Large software economies in developed countries

• IT application development expenditure in the US more than $250bn/year1

• Total value added GDP in the US2: $1.07 trillion

• Emerging challenges

• Security, robustness, human user-interface, and new computational platforms

1 Chaos Report, Standish group Report, 2014
2 softwareimpact.bsa.org

Software is Everywhere!

The University of Sydney Page 5

Need to build high-quality software systems under resource constraints

• Social

• Satisfy user needs (e.g., functional, reliable, trustworthy)

• Impact on people’s lives (e.g., software failure, data protection)

• Economical

• Reduce cost; open up new opportunities

• Average cost of IT development ~$2.3m, ~$1.3m and ~$434k for large, medium

and small companies respectively3

• Time to market

• Deliver software on-time

3 Chaos Report, Standish group Report, 2014

Why Software Engineering?

The University of Sydney Page 6

What happened?
• European large rocket – 10 years development, ~$7 billion

• Unmanaged software exception resulted from a data conversion

from 64-bit floating point to a 16-bit signed integer

• Backup processor failed straight after using the same software

• Exploded 37 seconds after lift-off

Why did it happen?
• Design error, incorrect analysis of changing requirements, inadequate validation

and verification, testing and reviews, ineffective development processes and

management

1 http://iansommerville.com/software-engineering-book/files/2014/07/Bashar-Ariane5.pdf

Software Failure – Ariane 5 Disaster1

http://iansommerville.com/software-engineering-book/files/2014/07/Bashar-Ariane5.pdf

The University of Sydney Page 8

What is the difference

between SW Developers

and SW Engineers?

Breakout rooms – randomly allocated

The University of Sydney Page 9

http://www.purplesoft.com.au/wp-content/uploads/2017/03/software.jpg

What is Software Engineering?

http://www.purplesoft.com.au/wp-content/uploads/2017/03/software.jpg

The University of Sydney Page 10

“An engineering discipline that is concerned with all aspects of software production from the
early stages of system specification through to maintaining it after it is has gone into use.”

• NOT programming/coding! a lot more is involved

• Theories, methods and tools for cost-effective software production

• Technical process, project management and development of tools, methods to

support software production

• System Engineering (Hardware & Software) – software often dominates costs

Software Engineering

The University of Sydney Page 12

Software Process

The University of Sydney Page 14

The Software Process

– Software Development Process
– Set of activities required to develop a software

– Activities are to be done, and in what order

– Lifecycle for a Software Development project

– Processes, a set of tools, definitions of the Artifacts, etc.

– Is there a universally applicable software engineering process?
– Many different types of software systems

– Companies/engineers claim that they follow “methodology X”, but many times
they only do some of what the methodology says

The University of Sydney Page 15

The Software Process

– Many software development processes, but all include common activities

– Specification

– Design and implementation

– Validation

– Evolution

– Software processes are complex and, rely on people making decisions and
judgements

– Activities are complex and include sub-activities

– E.g., requirements validation, architectural design, unit testing

The University of Sydney Page 16

Software Process Models

– Software Development Lifecycle (SDLC)

– Description of a process from particular perspective
– Describe the activities and their sequence but may not the roles of

people

The University of Sydney Page 17

Representative Software Process Models

– Waterfall Model

– Development process activities as process phases

– Spiral Model

– Incremental development risk-driven

– Agile Model

– Iterative incremental process for rapid software development

– The Rational Unified Process (RUP or UP)

– Bring together elements of different process models

– Phases of the model in timer, process activities, good practices

The University of Sydney Page 18

Waterfall Model – Heavy-Weight Model

Development activities Teams

Divide the work into
stages

A separate team of
specialists for each stage

At each stage, the work is
passed from one team to
another

Some coordination is
required for the handoff
from team to team – using
“documents”

At the end of all of the
stages, you have a
software product ready to
ship

As each team finishes, they
are assigned to a new
product

Ian Sommerville. 2016. Software Engineering (10th ed. Global Edition). Pearson

The University of Sydney Page 19

Waterfall Model Phases

– Requirements analysis and definition
– Requirements doc.

– System and software design
– Design document based on requirements doc.

– Implementation and unit testing
– Code and test it for system components (using design doc.)

– Integration and system testing
– Software components are integrated and the resulting system is tested

– Operation and maintenance

The University of Sydney Page 20

Waterfall Model

• Intensive documenting and planning

• Easy to understand and implement

• Identified deliverables and milestones

• Discovering issues in earlier phases should lead to returning to earlier phase!

The University of Sydney Page 21

Requirements Engineering Process

Requirements engineering

main activities and deliverables

Ian Sommerville. 2016. Software Engineering (10th ed. Global Edition). Pearson

The University of Sydney Page 25

Planning in Software Development

– Plan-driven (plan-and-document / heavy-weight)
– Activities are planned in advance and progress is measured against this plan

– Plan drives everything and change is expensive

– Agile processes (light-weight)
– Planning is incremental and continual as the software is developed

– Easier to change to reflect changing requirements

– Most SW processes include elements of both plan-driven and agile

– Each approach is suitable for different types of software
– No right or wrong software processes

The University of Sydney Page 26

Waterfall Model Problems

• Difficulty of accommodating change after the process is underway

• Inflexible partitioning of the project into distinct stages makes it difficult to
respond to changing customer requirements

• Mostly used for large systems engineering projects where a system is
developed at several sites
– The plan-driven nature of the waterfall model helps coordinate the work

The University of Sydney Page 27

https://en.wikipedia.org/wiki/List_of_failed_and_overbudget_custom_software_projects

Software Failures – Budget, Schedule, Requirements

Project Duration Cost Failure/Status

e-borders (UK Advanced

passenger Information System

Programme)

2007 – 2014 Over £ 412m

(expected), £742m

(actual)

Permanent failure – cancelled after a

series of delays

Pust Siebel – Swedish Police

case management (Swedish

Police)

2011 – 2014 $53m (actual) Permanent failure – scraped due to poor

functioning, inefficient in work

environments

US Federal Government

Health Care Exchange Web

application

2013 –

ongoing

$93.7m (expected),

$1.5bn (actual)

Ongoing problems – too slow, poor

performance, people get stuck in the

application process (frustrated users)

Australian Taxation Office’s

Standard Business Reporting

2010 –

ongoing

~$1bn (to-date),

ongoing

Significant spending on contracting fees

(IBM & Fjitsu), significant scope creep and

confused objectives

https://en.wikipedia.org/wiki/List_of_failed_and_overbudget_custom_software_projects

The University of Sydney Page 28

Software Evolution

• Software is inherently flexible and can change

• As requirements change through changing business circumstances, the
software that supports the business must also evolve and change

• Business software needs to respond to rapidly changing market
• Time-to-market

• Plan-driven software development processes are not suitable for certain
types of SW systems

The University of Sydney Page 29

Rational Unified Process (RUP or UP)

Requirements

Design

Implementation &

Test & Integration

& More Design

Final Integration

& System Test

Requirements

Design

3 weeks (for example)

The system grows

incrementally.

Feedback from

iteration N leads to

refinement and

adaptation of the

requirements and

design in iteration

N+1.

Iterations are fixed in

length, or timeboxed.

Time

Implementation &

Test & Integration

& More Design

Final Integration

& System Test

• Software development

process utilizing iterative

and risk-driven approach to

develop OO software

systems

• Iterative incremental

development

• Iterative evolutionary

development

The University of Sydney Page 30

UP Phases and Disciplines

Concep

tion
Elaboration Construction

Transiti

on

The University of Sydney Page 31

Agile Development

Model

The University of Sydney Page 32

Project Failure – the trigger for Agility

– One of the primary causes of project failure was the extended
period of time it took to develop a system

– Costs escalated and requirements changed

– Agile methods intend to develop systems more quickly with
limited time spent on analysis and design

The University of Sydney Page 34

Agile Manifesto (2001) – An Eloquent Statement of

Agile Values or Goals

Agile Manifesto: http://agilemanifesto.org/

© 2001, the above authors. This declaration may be freely copied in any form, but only in its entirety through this notice.

http://agilemanifesto.org/

The University of Sydney Page 35

Agile Process

– Agile advocates believe:
– Current SW development processes are too heavy-weight or

cumbersome

– Current software development is too rigid

• Incomplete or changing requirements

– More active customer involvement needed

The University of Sydney Page 36

Agile Process

– Agile methods are considered
– Light-weight

– People-based rather than Plan-based

– Several agile methods
– No single agile method

– Extreme Programming (XP), Scrum

– Agile Manifesto closest to a definition
– Set of principles

– Developed by Agile Alliance

The University of Sydney Page 37

Agile Principles

9. Continuous attention to

technical excellence and good

design enhances agility.

10. Simplicity–the art of maximizing

the amount of work not done–is

essential.

11. The best architectures,

requirements, and designs emerge

from self-organizing teams.

12. At regular intervals, the team

reflects on how to become more

effective, then tunes and adjusts

its behavior accordingly.

5. Build projects around motivated

individuals. Give them the

environment and support they need,

and trust them to get the job done.

6. The most efficient and effective

method of conveying information

to and within a development team is

face-to-face conversation.

7. Working software is the primary

measure of progress.

8. Agile processes promote

sustainable development. The

sponsors, developers, and users

should be able to maintain a

constant pace indefinitely.

1. Our highest priority is to satisfy

the customer through early and

continuous delivery of valuable

software.

2. Welcome changing

requirements, even late in

development. Agile processes

harness change for the customer’s

competitive advantage.

3. Deliver working software

frequently, from a couple of weeks

to a couple of months, with a

preference to the shorter timescale.

4. Business people and developers

must work together daily

throughout the project.

Agile Alliance: http://www.agilealliance.org

http://www.agilealliance.org/

The University of Sydney Page 38

Software (Development) Process Models

Waterfall model

plan-driven development

Agile model

Incremental & iterative development

Agile Vs Waterfall: Showdown For Software Development Domination

Ian Sommerville. 2016. Software Engineering (10th ed. Global Edition). Pearson

Agile Vs Waterfall: Showdown For Software Development Domination

The University of Sydney Page 39

Main characteristics of Agile Development

– Agile Development as a
“software development
process”

– keep things small

– deliver partially-completed
software frequently

– talk to the customer often

– write more code than
documentation

– everyone on the team learns
together

Work for future

iterations

Work for the

current iteration

Every x weeks, produce a

new shippable product

The University of Sydney Page 40

Agile – Requirements process

– There is no “standard way” to do requirements in Agile

development

– Could be a normal “Software Requirements Document”

– But it is better to be more lightweight

– Based on user stories

– In each iteration, elaborate a small set of the functional requirements (the

high-priority behavior)

– For some key requirements, create some acceptance tests at the same time as

you write the requirements

The University of Sydney Page 41

Agile – Questions and Challenges?

– Documentation
– Still important in an Agile development

– If it is the only kind of communication in your project, it isn’t good

– Real working code is more valuable than documents

– Development plans
– Still important in an Agile project

– the format of an Agile development schedule is a bit different

– Development plan includes “iterations”

– Each iteration gives the team a chance to incorporate what they learn

The University of Sydney Page 42

Agile only works with the best developers

– Every project needs at least one experienced and competent lead
person. (Critical Success Factor)

– Each experienced and competent person on the team permits the
presence of 4-5 “average” or learning people.

– With that skill mix, agile techniques have been shown to work many
times.

The University of Sydney Page 44

Mutual Respect

– Developer: “Testers are failed programmers, they shouldn’t be

called engineers”

– Tester: “Developers are only able to produce bugs, the world

would be better with more testers and less developers”

– Business Analysts: “I don‘t know why I bother talking to testers

and developers, they are total idiots”

The University of Sydney Page 45

Not My Responsibility

– Developer: “It works in our environments, it’s operations

responsibility to make it work in production”

– Tester: ”Listen, it worked in User Acceptance Testing, it must be

a configuration issue, or a missing firewall hole and nothing I

could have spotted during testing…”

– Customer: “Hello! Nothing works here…”

The University of Sydney Page 46

How hard is it to be Agile?

– “Don’t do Agile, be Agile”
– Just doing “development in iterations” isn’t enough

– Agile Development is about:
– Keeping the process lightweight

– Making real progress in each iteration

– Communicating – face-to-face when possible

– Actively gathering customer input – early and often

– Willing to make minor changes to your process

The University of Sydney Page 47

Thinking Agile!

Best Agile Comic Strips

Best Agile Comic Strips

The University of Sydney Page 48

References

– Armando Fox and David Patterson 2015. Engineering Software as a
Service: An Agile Approach Using Cloud Computing (1st Edition). Strawberry
Canyon LLC

– Andrew Stellman, Margaret C. L. Greene 2014. Learning Agile:
Understanding Scrum, XP, Lean and Kanban (1st Edition). O’Reilly, CA, USA.

– Ivar Jacobson, Grady Booch, and James Rumbaugh. 1999. The Unified
Software Development Process. Addison-Wesley Longman Publishing Co.,
Inc., Boston, MA, USA.

– Ian Sommerville. 2016. Software Engineering (10th ed.) Global Edition.
Pearson, Essex England

The University of Sydney Page 49

Tools and Techniques for

Controlling Software

Artefacts

Next week Lecture