MSO Lecture 2wouter-swierstra.github.io/MSO-2015/slides/slides02.pdfCRITICISM ON THE WATERFALL MODEL I Traditionally, the waterfall model aims to complete every phase before moving

MSO – Lecture 2

Wouter Swierstra

Ga dicht op elkaar zitten, het wordt vol..

1

LABS

No lab partner?

Come down in the break.

2

LAST LECTURE

I Overview of course: object oriented analysis and design.I Recap: remind you of some object oriented terminology:

I inheritance;I polymorphism;I abstract classes;I interfaces.

3

HOMEWORK: GO

I What are the differences between the two games? What arethe similarities?

I Could you share code? What needs to be different?I What would you do differently in your Reversi

implementation if you knew beforehand that you wouldneed to extend it?

4

WHY THIS EXERCISE?

You are all used to writing code for courses like IMP: you have aspec and a deadline. Go!

I Have you ever studied code?I Have you ever had to maintain code?I Or adapt existing code?

Code is not write only.

5

THIS LECTURE

I How can I manage the process of constructing complexsoftware?

I How do I know what the customer wants?

6

SCIENTIFIC PROCESS

I In areas such as physics, there are fixed methodologies forexperiments and measurements.

I This translates into concrete processes for in engineeringdisciplines, such as architecture.

I But what about Computer Science?

7

WATERFALL MODEL (ROYCE, 1970)

8

CRITICISM ON THE WATERFALL MODEL

I Traditionally, the waterfall model aims to complete everyphase before moving on to the next.

I Critics complain that the waterfall model is not robustagainst change:

I A client can change his mind halfway through the project;I The money can run out;I A design can prove costly too implement;

“Many of the [system’s] details only become known to us aswe progress in the [system’s] implementation. Some of thethings that we learn invalidate our design and we mustbacktrack.” – David Parnas

9

ALTERNATIVE SOFTWARE DEVELOPMENT PROCESSES

I The spiral model (Boehm, 1988);I Agile development;I eXtreme Programming;I Rapid Application Development;I The (Rational) Unified Process;I .. and many others.

All these methods aim for a more incremental or evolutionaryapproach to software construction.

10

ABOUT SOFTWARE DEVELOPMENT PROCESSES

I Managing software development is a hard problem.I But choosing a methodology is a bit like choosing an

operating system or text editor:I Each system is slightly different.I There is no clear winner.I There are zealous advocates for each system.

I My advice:I Learn to apply one methodology really well.I Don’t get stuck in a rut – stay hungry!I Always choose the right tool for the job.

11

THE UNIFIED PROCESS

I In this course, I want to focus mostly on one methodology –and how it meshes with the ideas of object orientation;

I I will focus on the Unified Process (Jacobson, Booch andRumbaugh, 1999)

I It is one of the most popular philosophies used today;I but it is not as ‘cool’ as the more recent Agile/Scrum

methodologies.I Although it can be adapted to work together with such other

methodologies.

12

THE UNIFIED PROCESS

I The Unified Process emphasises iterative softwaredevelopment.

I Develop software in time-boxed mini-projects callediterations.

I Each iteration has clearly defined milestones, including atested, integrated, executable system.

13

ITERATIVE DEVELOPMENT – PHILOSOPHY

I The iterative lifecycle is based on the successiveenlargement and refinement of a system though multipleiterations with feedback and adaptation.

I The system grows incrementally over time, iteration byiteration.

I The system may take many iterations to be productionready (or ready for deployment).

14

ITERATIVE DEVOLPMENT – IMPLEMENTATION

I The output of an iteration is not (just) an experimentalprototype but a production subset of the final system.

I Each iteration tackles new requirements and incrementallyextends the system.

I An iteration may occasionally revisit existing software andimprove it.

15

EMBRACING CHANGE

I Stakeholders usually have changing requirements.I End users;I Project management;I Upper management;I Implementors;I Testers;I . . .

I Each iteration involves choosing a small subset of therequirements and quickly design, implement and testingthem.

I This leads to rapid feedback, and an opportunity to modifyor adapt understanding of the requirements or design.

16

UNIFIED PROCESS – PHASES

I These UP defines four different phases, each split intomultiple iterations:

I Inception – Define the scope of the project;I Elaboration – Plan the project, specify features, baseline

architecture;I Construction – Finish the construction;I Transition – Hand over the project to end users.

I Each phase overlaps with some elements of the waterfallmodel,

I but the balance between them shifts as time passes.

17

18

THE UNIFIED PROCESS: BEST PRACTICES

I Develop software iteratively – involve users early!I Manage requirements;I Use component-based architectures;I Visually model software;I Verify software quality – test, code reviews, release in every

iteration.I Embrace change.

19

THE UNIFIED PROCESS

I Today: I’ll try to explain the theory behind the UP. . .I . . . but applying the UP to your own projects is your

responsibility.I This course is mostly focussed on the first two stages of the

UP: Inception and Elaboration.

20

INCEPTION

21

INCEPTION

I Envision the product scope, vision, and business case.I Upon completion, the stakeholders have a basic agreement

on the vision of the project and are able to decide whetherto continue or not.

I It typically only lasts ‘a few’ weeks.

22

INCEPTION: ARTIFACTS

I A vision document – what is the general vision of theproject? What are the key features and constraints?

I A initial list of use-cases – how will end-users interact withthe system?

I An initial project glossary – what is some of the domainspecific lingo?

I An initial business case – how will we make money?I An initial risk assessment – what might go wrong?I A project plan, showing phases and iterations – how will

we move forward?I One or several prototype experiments.

23

WHAT INCEPTION IS AND IS NOT

I It’s not about deciding how many weeks feature X will taketo implement.

I You need a ballpark estimate: 1 month or 1 year? 1M or 10Keuros?

24


I It’s not about identifying every possible interaction thatevery imaginable user can have with your system.

I You want to have an idea of which people will end up usingthe system.

I You should have a few carefully thought out use cases.

25


I It’s not about choosing the color of the icon, which GUIlibrary to use, or which operating system to support.

I You do want to think about whether it will run on tablets,mobile phones, desktops, or in the cloud.

26

ABOUT RISK

It can be very hard to identify where the risk lies in any project:

I Example: restaurant matching website;I Example: changing the limit on your creditcard limit.I Example: Amazon and Zalando.

27

ELABORATION

28

ELABORATION: GOALS

I Analyze the problem domain, establish an architecturalfoundation, develop a project plan, and eliminate highestrisks.

I You need to develop a ‘mile high and inch deep’ view of thesystem;

I Now is the time to make architectural decisions.I Build an executable architecture prototype, thereby

eliminating critical risk, for the central use cases developedin the Inception phase.

I Note: you should start building a prototype early, even if therequirements have not been finalized yet.

29

ELABORATION: ARTIFACTS

I A use-case model describing how users will interact withthe system;

I Supplementary requirements capturing the non-functionalrequirements;

I A Software Architecture Description.I An executable architectural prototype.I A revised risk list and a revised business case.I A development plan for the overall project, including the

coarse-grained project plan, showing iterations andevaluation criteria for each iteration.

30

ELABORATION OUTCOMES

I A stable vision of the software system and its architecture;I Minimized the risks that could cause the project to fail if

you choose to continue.I Better estimates for project costs and planning.

31

CONSTRUCTION

32

CONSTRUCTION: GOALS

I The main goal of the construction phase is to develop andtest a baseline product.

I Upon completion, there should be a clear description of theproduct status, together with user manuals. The tool shouldbe ready to be deployed – even if not all features are fullyimplemented.

33

TRANSITION

34

TRANSITION

I The transition aims to deliver the first version of thesoftware to its users.

I Beta testing;I Training of new users and maintainers;I Operating in parallel with existing legacy systems;I Conversion of data bases;I . . .

I This process usually involves a lot of tuning, bug-fixing,processing enhancement requests, and implementingunfinished features.

35

TRANSITION: GOALS

I Enabling users to use your product;I Achieving consensus with all stakeholders that the baseline

product is complete;I Iteratively refining the baseline until the final product is

implemented.

36

WORKFLOWS

I UP identifies six distinct kinds of ‘engineering activity’:

1. Business modeling2. Requirements3. Analysis & Design4. Implementation5. Test6. Deployment

I And three kinds of ‘supporting’ activity:

1. Project Management workflow2. Configuration and Change Management3. Environment

I I want to focus on the first three engineering activities.

37

Business Modeling aims to document existing business processesto establish a common understanding between variousstakeholders about how the organization works.

Requirements Engineering aims to describe what the systemshould do, allowing customers and developers to agree on thatdescription.

Analysis and Design aims to describe how the system should beimplemented, in accordance with the requirements it shouldsatisfy.

38

UP VS AGILE

The Agile Manifesto

We are uncovering better ways of developing software by doingit and helping others do it. Through this work we have come tovalue:

I Individuals and interactions over processes and toolsI Working software over comprehensive documentationI Customer collaboration over contract negotiationI Responding to change over following a plan

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

39

AGILE SOFTWARE DEVELOPMENT WITH SCRUM

40

REQUIREMENTS – WHY?

I Software errors cost the American economy about $60billion each year.

I 84% of all software projects are unsuccessful (late, overbudget, cancelled, etc.)

I Three of the top reasons for failure:I Poor user input 13%I Incomplete requirements 12%I Changing requirements 7%

Requirements are really important!

41

STAKEHOLDERS AND CONCERNS

Requiremenst should identify relevant stakeholders andconcerns.

A stakeholder is a person, group, or entity with an interst in orconcerns about the realization of the architecture.

A concern is a requirement, an objective, an intention, or anaspiration a stakeholder has for that system.

42

REQUIREMENTS

43

REQUIREMENTS – DEFINITION

A requirement is a feature that a system must have or a constraintit must satisfy to be accepted by the client.

Requirements engineering is the process of identifying anddefining the requirements of a software system.

Requirements engineering is a cyclic process:

1. Elicitation2. Specification3. Validation and verification4. Negotiation

44

REQUIREMENTS EXAMPLES

Requirements come in all kinds of shapes and sizes:

I Functional – features, capabilitiesI Usability – help, documentationI Reliability – frequency of failure, uptime, recoverabilityI Performance – response time, accuracy, throughputI Supportability – adaptibility, maintainability

But also sub-factors such as:

I Implementation – languages and tools, hardwareI Legal – licensingI Interface – constraints arising from other systems

45

REQUIREMENTS – HOW?

Many customers have little technical skill. Or they may not evenknow what they want themselves. How can you figure out whatthey want?

Eliciting clear requirements is not as easy as you may think. . .

(Example from O’Reilly’s Head First Object-Oriented Analysis andDesign).

46

47

48

49

EASY SPEC

I Push the button on the remote to open the door;I Push the button on the remote to close the door.

50

INITIAL DESIGN

I DogDoor classI method OpenI method CloseI method WaitForRemote

I Remote classI tell the DogDoor to open and closeI knows when the button is pressed.

51

public class DogDoor {

private boolean open;

public DogDoor() {this.open = false; }

public void open() {Console.WriteLine("The dog door opens.");open = true; }

public void close() {Console.WriteLine("The dog door closes.");open = false; }

public boolean isOpen() {return open; }

}52

public class Remote {

private DogDoor door;

public Remote(DogDoor d){ ... }

public pressButton () {if door.isOpen(){

door.close()}else{door.open()

}}

}53

WHAT ELSE?

I This defines the core class files;I (I’m ignoring the interface to the door’s hardware.)I Perhaps we should write some tests?

54

public class DogDoorSimulator {

public static void main(String[] args) {DogDoor door = new DogDoor();Remote remote = new Remote(door);

Console.WriteLine("Fido barks to go out.");remote.pressButton();

Console.WriteLine("\nFido has gone.");remote.pressButton();

Console.WriteLine("\nFido's all done.");remote.pressButton();

Console.WriteLine("\nFido's back inside.");remote.pressButton();

}}

55

SO WE’RE DONE!

I We’ve talked to our customer to establish somerequirements;

I We have implemented a system that satisfies theserequirements;

I We’ve tested that our system behaves as expected.

56

57

WHAT WENT WRONG?

I We implemented what we were asked;I The hardware works;I The software works;I Our testsuite passes.

Getting the requirements right is not just the customer’sresponsibility!

58

59

BUT WHAT IF. . .

Question: What else could possibly go wrong?

60

BUT WHAT IF. . .

I Fido does not bark to go outside?I Todd and Gina don’t hear Fido barking?I Fido is barking, but does’t want to go outside?I the door is closed before Fido returns?I the door jams?I the door closes as Fido is going outside?I . . .

61

WHY THIS EXAMPLE IS IMPORTANT

I The implementation of the DogDoor is super simple – it isessentially a single boolean.

I But figuring out what the customers want is really hard!I How can we figure out what the customer wants?

62

FINDING REQUIREMENTS

I ElicitationI talk to clients and end-users;I gather existing documentation;I observe how future users work now.

I But be careful:I ‘Customers can check bank balances’ – but only their own!I ‘A grade above 6.0 is a pass’ – but so is a 6.0!I ‘Every telephone number starts with an area code’ – unless

it’s for a cell phone.

63

ELICITATION TECHNIQUES - I

I Asking:I What do you expect from the system?I Interview, brainstorm, questionnaire, . . .

I Task analysis:I Which subtasks can you identify?I How can you organize tasks into a hierarchy?

64

ELICITATION TECHNIQUES - II

I Scenario-based analysisI How do you do Y?I But what happens if . . . ?

I EthnographyI Actively observing users do their workI May be more reliable than asking them.

65

ELICITATION TECHNIQUES - III

I Analyzing existing documents and systemsI What problems do the existing systems have?

I Prototyping – is this what you had in mind?I Domain analysis - how are other systems in this domain

built?

66

WHAT MAKES A GOOD SET OF REQUIREMENTS?

Correctness it accurately captures the client’s viewsConsistency it does not contradict other requirementsCompleteness all possible scenarios are accounted for

Clarity unambiguously formulatedRealism it can be implemented and delivered

Verifiability how can you (automatically) test that it is satisfied

67

EXAMPLES OF POOR REQUIREMENTS

I The system should be usable by elderly people.

I Not verifiable and unclear.I Better: All text should be in at least 14pt font.

I Upon completion, the final product shall not have anyerrors.

I Not verifiable and not realistic.I Better: give specific test criteria.

I The product shall respond rapidly.

I Not verifiable and unclear.I Better: The system shall respond in less than 2s.

68


I The system should be usable by elderly people.I Not verifiable and unclear.

I Better: All text should be in at least 14pt font.





69


I The system should be usable by elderly people.I Not verifiable and unclear.I Better: All text should be in at least 14pt font.





70







71




I Not verifiable and not realistic.

I Better: give specific test criteria.



72







73







74





I The product shall respond rapidly.I Not verifiable and unclear.

I Better: The system shall respond in less than 2s.

75





I The product shall respond rapidly.I Not verifiable and unclear.I Better: The system shall respond in less than 2s.

76

NOT ALL REQUIREMENTS ARE CREATED EQUALLY

Everyone wants a system that is up 24/7, is easy to take downfor maintainence, cheap to implement, immediately responsive,and that looks pretty.

Trying to identify what is really important can safe you a lot ofdevelopment time down the road.

77

REQUIREMENTS ARE NOT A WISH LIST

In the Software Project that CS students do in to complete theirBSc, many students make the same mistake:

Requirements are not a wish list

Requirements are a contract for the minimal functionality thatyou can promise to deliver.

78

TRY DIFFERENT TECHNIQUES.

The more information you have,

I the better you understand the domain,I the better you can write and prioritize your scenarios,I the greater the chance of success.

79

SCENARIOS AND USE CASES

I One of the most popular way to establish (functional)requirements is through writing scenarios and use cases.

I These document the system’s behaviour from the userspoint of view, in a way that customers can understand whatthe system does – how does the system add value to the user?

I Use cases and scenarios are crucial if you want to agree onwhat the system does.

80

SCENARIOS: DEFINITION

A narrative description of what people do and experience asthey try to make use of computer systems and applications –(M. Carroll, 1995)

81

SCENARIO: EXAMPLE

I Alice goes to the cash machine;I She enters her card and PIN;I She requests to see her bank balance and withdraws 20 euro.I She takes her money, card and a printed receipt.

Note that:

I This only describes a single transaction – it does not captureall possible interactions or all possible outcomes.

I The actors involved may be people, systems, or evenorganizations.

82

USE CASES – DEFINITION

A use case is more general than a scenario. It documents aninteraction between users and the system that yields anobservable result or value.

When writing use cases, many authors distinguish differentlevels:

I Brief – a one paragraph summary of the main successscenario;

I Casual – a few paragraphs that cover various scenarios;I Full dressed – a detailed account of all possible steps and

variations, including entry conditions, exit conditions andspecial requirements.

83

USE CASES: BRIEF

Bank Customers should be able to go to the ATM and withdrawmoney from their account. To do so succesfully, they start byidentifying themselves using their PIN and bank card. Afterselecting the account from which they wish to withdraw money,the necessary information is transmitted to the bank. Once thebank verifies that there is sufficient money in the account, themoney is dispensed, together with the bank card and a receipt.

84

USE CASES: CASUAL

Give a brief account several different scenarios:

I What if the PIN number is wrong?I What if the ATM is out of money? Or cannot dispense the

requested amount?I What if the user does not have enough money is his

account?I . . .

85

WHAT TO WRITE?

A fully dressed use case consists of:

I A unique nameI Participating actorsI Entry conditionsI Flow of eventsI Exit conditionsI Special requirements

This general format was originally suggested by AlistairCockburn and is used throughout Larman’s Applying UML andPatterns.

86

EXAMPLE: WITHDRAWING MONEY

1 Brief Description

This use case describes how the Bank Customer uses the ATM towithdraw money to his/her bank account.

2 Actors

Bank Customer and Bank

3 Entry conditions

There is an active network connection to the Bank.

The ATM has cash available.

87

EXAMPLE – BASIC FLOW OF EVENTS1. Bank Customer inserts their Bank Card.2. Use Case: Validate User is performed.3. The ATM displays the different alternatives that are

available on this unit. In this case the Bank Customeralways selects “Withdraw Cash”.

4. The ATM prompts for an account. See SupportingRequirement SR-yyy for account types that shall besupported.

5. The Bank Customer selects an account.6. Card ID, PIN, amount and account is sent to Bank as a

transaction. The Bank Consortium replies with a go/no goreply telling if the transaction is ok.

7. Then money is dispensed.8. The Bank Card is returned.9. The receipt is printed.

10. The use case ends successfully.88

ALTERNATIVE FLOWS

1 Invalid User

If in step 2 of the basic flow Bank Customer the use case:Validate User does not complete this successfully, then:

1. The use case ends with a failure condition.

2 Insufficient cash

If in step 5 in the basic flow, the Bank Customer enters anamount that exceeds the amount of cash available in the ATM,then

1. The ATM will display a warning message, and ask the BankCustomer to reenter the amount.

2. The use case resumes at step 5.

89

3 No response from Bank

If in step 6 of the basic there is no response from the Bank within3 seconds, then

1. The ATM will re-try, up to three times.2. If there is still no response from the Bank, the ATM shall

display the message “Network unavailable – try againlater”.

3. The ATM shall return the card.4. The ATM shall indicate that it is “Closed”.5. The use case ends with a failure condition.

. . . and lots more can go wrong

90

EXIT CONDITIONS

7 Post-conditions

7.1 Successful Completion

The user has received their cash and the internal logs have beenupdated.

7.2 Failure Condition

The logs have been updated accordingly.

8 Special Requirements

[SpReq:WC-1] The ATM shall support localizations for all majorEuropean languages.

[SpReq:WC-2] The ATM shall keep a log, including date andtime, of all complete and incomplete transactions with the Bank.

91

USE CASES – ADVICE

I Don’t think about implementation or user interfaces;I Do think about user experience.I Keep the writing as simple as possible – you’re not writing

a novel or academic textbook, but a piece of text that shouldbe as unambiguous as possible.

92

USE CASES – DIAGRAMS

I Sometimes it can be useful to visualize which actors interactduring certain use cases.

I In that case, it can help to draw UML use case diagrams.

93

UML USE CASE EXAMPLE

Client

Withdraw

94

Web shop

VAT Calculator

Client Process sale Authorization server

Change password

95

ELEMENTS OF UML USE CASE DIAGRAMS

Actor

System

Use Case

<uses>

<extends>

96

DIAGRAMS

I Actors may be users, other stakeholders, or even softwaresystems;

I You may want to organize actors or use cases into systemboxes.

I You can re-use use cases using the <<uses>> arrows – forinstance, both cash withdrawal and changing your PINcode require some form of authentication.

I You may want to identify special cases of a given use case,using <<extends>> arrows – for example, to distinguishAssign Window Seat and Assign Aisle Seat are bothextensions of the Assign Seat use case.

97

Airline system

Check in

Book tickets

Customer Ticket clerk

98

DETAILED VIEW

Check in

<uses>

Assign seatWeigh luggage

<uses>

Assign aisle seat

Assign corridor seat

<extends>

<extends>

99

REQUIREMENT VERIFICATION AND VALIDATION

Requirements validation is concerned with checking therequirements document for consistency, completeness, andaccuracy.

Requirements verification is a mathematical analysis, possiblyautomated, of formal specifications for consistency

100

TECHNIQUES

You need to interact with users and customers to validate yourrequirements.

I Reviews, checklists, discussionI Prototypes and mockupsI Animations

101

REQUIREMENTS NEGOTIATION

Usually, there are constraints that limit the functionality that canbe delivered (time, money, resources, . . . )

Or there are conflicting requirements between differentstakeholders.

To establish a sensible set of requirements requires negotiationwith your customer.

102

BACK TO UP – EXAMPLE PLANNING

I InceptionI start with a two day workshop with all stakeholders aimed

at inventorizing use cases, and writing a brief description ofeach one.

I Elaboration (first iteration)I work out key use cases in greater detail and discuss these

with the client.I design high-risk architectural componentsI start implementation.

As iterations proceed, more use cases are developed, togetherwith the prototype system. There are regular checks with thecustomer to check that they agree with existing requirementsand the prototype system.

103

THIS LECTURE

I How can I manage the process of constructing complexsoftware?

I Use the Rational Unified Process, or any other softwaredevelopment process.

I How do I know what the customer wants?I Write use cases and requirements documents.

104

MATERIAL COVERED

I Rational Unified Process Whitepaper – available on theMSO website.

I Craig Larman. Applying UML and Patterns. PearsonEducation. 2002. Chapters 1–7.

105

LAB EXERCISE

Write a requirements document for the Submit System – thatallows students to submit their code to the University servers.

I Study relevant sections of Larman’s Applying UML andpatterns.

I Identify actors and stakeholders involved;I Identify key use cases and giving a casual description;I Write a fully-dressed specification for the ‘Submit’ use case;I Write non-functional requirements in a Supplementary

Specification.I All lab assignments should be done in pairs.

106

Documents

MSO Lecture 2wouter-swierstra.github.io/MSO-2015/slides/slides02.pdfCRITICISM ON THE WATERFALL MODEL I Traditionally, the waterfall model aims to complete every phase before moving