cse senior design i building a plan instructor: mike o’dell several of the slides in this module...

CSE Senior Design ICSE Senior Design I

Building a PlanBuilding a Plan

Instructor: Mike O’DellInstructor: Mike O’Dell

Several of the slides in this module are a modification and amplification of Several of the slides in this module are a modification and amplification of slides prepared by Mr. Tom Rethard for use in a prior Senior Design Class. slides prepared by Mr. Tom Rethard for use in a prior Senior Design Class.

They were originally for use with They were originally for use with A Discipline for Software EngineeringA Discipline for Software Engineering (Watts (Watts S. Humphrey), sponsored by the U.S. Department of Defense. Original slides S. Humphrey), sponsored by the U.S. Department of Defense. Original slides

are copyright SEI; modifications are Copyright © 2002, T. Rethard. Further are copyright SEI; modifications are Copyright © 2002, T. Rethard. Further modifications by Mike O’Dell. All Rights Reserved.modifications by Mike O’Dell. All Rights Reserved.

2

CSE 4316 2

Why Plan?Why Plan?A plan helps you focusfocus on the goal

“Begin with the end in mind.1”A plan let’s you estimateestimate job completionA plan helps you track progresstrack progressA plan gives you milestonesmilestones that provide

a sense of accomplishment sense of accomplishment along the wayA plan helps you identify problems identify problems earlyA plan establishes commitments establishes commitments for the

team and each individual on it1 Stephen R. Covey, The Seven Habits of Highly Effective People

2

CSE 4316 3

The Planning Process… The Planning Process… SimplifiedSimplified

Plan the work … then work the planRefine, refine, refine…

2

CSE 4316 4

What is a Plan?What is a Plan?

An agreement agreement by the team on the cost and schedule for a specified job

A structurestructure for organizing the workA frameworkframework for obtaining the required

resources (people, funds, etc.)A recordrecord of what was initially assumed

and committedIt’s a CONTRACTCONTRACT!

2

CSE 4316 5

Components of a PlanComponents of a PlanA LifecycleLifecycle Planning Model: The Master

Plan for the Project Order and criteria for key events Correct model for the job?

Work Estimates How big is the job (size and effort)? What can be done with resource/time?

Schedule and Work Breakdown When do we expect to have things done? What are we committing to?

2

CSE 4316 6

Representative Lifecycle Representative Lifecycle ModelsModels

Pure Waterfall (the old granddaddy) Code-and-Fix (and plan to fail) Spiral (new age sophistication) Modified Waterfalls (making the best of an old

standby) Evolutionary/Rapid Prototyping (design as you

go) Agile development – iteration in timeboxes Staged Models (show as you go)

Design to schedule

Hybrids – some combinationcombination of above

2

CSE 4316 7

Agile MethodologiesAgile Methodologies

Iterative and incremental developmentAdaptive planning based on customer

and market changesPlan milestones are flexible and subject

to change “rolling wave” progression TimeBox development Staged (potentially shippable increments) Scrum

2

CSE 4316 8

Clear Product SpecificationsClear Product Specifications

Provide the details of whatwhat will be done, and howhow it will be done: Requirements Specification (SRS – whatwhat),

managed via the Product Backlog Design Documentation (DDS - howhow ) Test Plan (verify the what and the how)

These provide the basis for product acceptance

2

CSE 4316 9

Processes/ProceduresProcesses/Procedures

Defines howhow things will get done Provides the basis for establishing critical

milestones and deliverables Establishes entry and exit criteria for

critical phases Establishes the standards that will be used Defines the tools that are required to

complete the work

2

CSE 4316 (from Essential Scrum, Rubin) 10

Scrum OverviewScrum Overview

Scrum Essentials Roles Activities Artifacts

2

CSE 4316 (from Essential Scrum, Rubin) 11

Scrum Activities OverviewScrum Activities Overview

2

CSE 4316 12

Characteristics of a Good Characteristics of a Good Requirement (PBI/User Story)Requirement (PBI/User Story)

Independent. Independent. One of the characteristics of Agile Methodologies such as Scrum is the ability to move stories around, taking into account their relative priority - for example - without much effort. If you find user stories that are tightly dependent, a good idea might be to combine them into a single user story.

2

CSE 4316 13


Negotiable. Negotiable. The only thing that is fixed and set in stone in an agile project is a Sprint backlog (and, even then, it can be broken). While the story is in the product backlog, it can be rewritten or even discarded, depending on business, market, technical or any other type of requirement by team members.

2

CSE 4316 14


Valuable. Valuable. The focus here is to bring actual product-related value to the end-user. Coming up with technical stories that are really fun to code but bring no value to the end-user violates one of the Agile Principles, which is to continuously deliver valuable software.

2

CSE 4316 15


Estimable. Estimable. If a user story size cannot be estimated, it will never be planned, tasked, and, thus, become part of an iteration. So there's actually no point in keeping this kind of user story in the Product Backlog at all. Most of the time, estimation cannot be executed due to the lack of supporting information either in the story description itself or directly from the Product Owner.

2

CSE 4316 16


Small. Small. User story sizes should typically take only a few days to implement. Anything beyond that range should be considered too large to be estimated with a good level of certainty or even "epic" and broken down into smaller user stories. There's no problem in starting with epic stories, as long as they are broken down when the time to place them in a Sprint backlog comes closer.

2

CSE 4316 17


Testable. Testable. Bear in mind that a story should only be considered DONE, among other things, if it was tested successfully. If one cannot test a story due to lack of information (see "Estimable" above), the story should not be considered a good candidate to be part of a Sprint Backlog.

2

CSE 4316 18


I.N.V.E.S.T.I.N.V.E.S.T.

2

CSE 4316 19

Tips for Successful Requirement Tips for Successful Requirement DeterminationDetermination

Start by establishing what the team thinks the features/functionsfeatures/functions of the system should be Brainstorm as team and write everything

down on the Product Backlog (using the template provided)

Meet with your sponsorsponsor to review/modify your list and discuss alternatives Add any features/functions that the sponsor

believes are required

2

CSE 4316 20

Tips for Successful Requirement Tips for Successful Requirement DeterminationDetermination

Consider and add ancillary requirementsancillary requirements E.g., performance, packaging, look and feel

Discuss and add as necessary any “non-“non-functional” requirementsfunctional” requirements E.g., standards that you must adhere to,

maintenance and support, safetyDiscuss and analyze the feasibility analyze the feasibility of

meeting or exceeding each requirement within the budget, time and skills allowed. Assess effort required.

2

CSE 4316 21

What is a System Requirements What is a System Requirements Specification (SRS)?Specification (SRS)?

A detailed description detailed description of the features and functions of a product, incorporating: End-user and sponsor input Developer input Management input

The basis for your Product BacklogProduct BacklogYour documented commitmentcommitment to deliverYour contractcontract with your stakeholders that

identifies WHAT you will create

cse senior design i building a plan instructor: mike o’dell several of the slides in this module...

Documents