Ethics

MODULE 5 “HEAD FIRST” CHAPTER 4

User Stories and TasksDr. Zhang

TWU

Goals

Dr. ZhangCSCI 3413

2

 You need to read Chapter 4 of Head First book

 Learn about the Software Process

 Read chapters 2 & 3 from Pressman book, or use the attached PowerPoint file

 More on Big Board & Burn Down chart

User Stories and Tasks

Dr. ZhangCSCI 3413

3

 You and your customer have decided on Milestone 10.0 and agreed on a deadline

 The chapter discusses what can happen during the first couple of iterations

 Each user needs to be split into tasks

 Each task needs estimate associated with it

 Entire team should participate in breaking the user stories into tasks.

 The problem is that the task estimate != story estimate

 The book recommends to perform tasks decomposition during requirements gathering

 The burn-down chart needs to be updated whenever an estimate changes for work gets done

 Big Chart: How to use it? See Head First book.

iSwoon Example

Dr. ZhangCSCI 3413

4

Standup Meeting

Dr. ZhangCSCI 3413

5

 It’s a daily meeting that

 Keeps the team motivated and aware of progress

 Keep your big up-to-date

 Highlight problem early

 It should track progress, update burn-down rate, update tasks, discuss that happened yesterday and plan today’s activities, bring up issues and last between 5-15 minutes.

Expect the Unexpected 6

 The CEO of iSwoon wants to demo the system

 What to do?

 Velocity builds a little flexibility into the schedule

 But velocity is not a substitute for good estimation; it’s a way to factor in the real-world performance of your team, not the unexpected.

Successful Software Development 7

 Successful software development is about knowing where you are.

 You may be behind, but at least you know you are behind.

 Compare to the Big Bang approach from Chapter 1, which is referred to as the waterfall approach sometime.

 What is waterfall approach? See Chapter 2 in the Pressman book, or the attached PowerPoint notes.

MODULE 5 “HEAD FIRST” CHAPTER 5

Good-enough DesignDr. Zhang

TWU

Goals

Dr. ZhangCSCI 3413

9

 Learn about good Software Design

 SRP: Single Responsibility Principle (or cohesion)

 DRY: Don’t Repeat Yourself Principle

iSwoon 10

 Chapter 4 presents a design for the iSwoon date planner.

 Date and Event classes are associated:  Date objects maintains a list of events

 Date object provide methods that add events to a date.

 The Date object checks if a event is allowed on a particular date

 Check out the UML on page 124-125.  Do you need more information on UML? The appendix in

both Head First and Pressman book are good starts. It’s easy to find related material on the Internet too.

Is iSwoon a good or bad design?

Dr. ZhangCSCI 3413

11

 The design in Chapter 4 is bad

 It can’t easily handle adding a new type of Event

 It can’t easily handle changing the name of an event

 It can’t easily handle the changing of which event is allowed for what dates

Single Responsibility Principle (SRP) 12

 The Date class has multiple responsibilities  Tracking the events planned for a date

 Tracking the events allowed for a fate

 The Single Responsibility Principle:  Every object in your system should have a single

responsibility and all the object’s services should be focused on carrying out that single responsibility

 The original iSwoon design breaks the SRP

 Check out page 153.

Spot multiple responsibilies 13

 For each class C, for each Method  Write “The C Methods itself”

 Examples:  For class Automobile, there are methods drive(), wash(),

start(), stop(), getOil()

 Write  The Automobile drives itself

 The Automobile washes itself

 The Automobile starts itself

 The Automobile stops itself

 The Automobile gets oil itself

Reduce to SRP

 If any of the sentences doesn’t make sense on a class, then you might need to move those methods to classes that do make sense for that responsibility

 This may require you to create new classes

 It’s a good way to spot the multiple responsibilities, but it’s not perfect.

Dr. ZhangCSCI 3413

14

Don’t Repeat Yourself (DRY)

 There are duplications of validateEvent() methods in the Date subclasses.

 Don’t Repeat Yourself:  Avoid duplicate code by abstracting out things that are

common and placing those things in a single location

 Duplication is bad at all levels of software engineering: Analysis, design, coding, and test.

Dr. ZhangCSCI 3413

15

The New iSwoon Design

 With the new design (see pages 162-163), three tasks can be done in one day instead of seven days!

 A great design helps you be more productive as well as making your software more flexible.

 The underlying message of this chapter is that your team needs to understand good Object Oriented design principles.

 Check out the conversation between Perfect Design and Good Enough design.

Dr. ZhangCSCI 3413

16