chapter 1: starting a projectathena.ecs.csus.edu/~buckley/csc233/csc233_chapter3.pdf · management....

CSc 233 Spring 2012

Dilbert Scott Adams

CSc 233 Spring 2012

Dilbert Scott Adams

2

CSc 233 Spring 2012

Dilbert Scott Adams

3

CSc 233 Spring 2012

…prerequisites

I thought we had agreed long ago that the Department Policy was

that all instructors would check for the completion of all

prerequisites in the prerequisite chain.

This may have been requested, but I don't recall it ever becoming

policy.

I don't check prerequisites. We are a 21st century computer

science department at a university with an expensive CMS

system. I would think that this is a university-wide problem and

requires a university-wide solution that is better than having

hundreds of faculty do such busy-work.

Manage It! Your Guide to Modern, Pragmatic Project

Management. Johanna Rothman

4

CSc 233 Spring 2012

How hard would it be for CMS to make a second prerequisite

check after grades have been submitted but before the semester

begins?

A few hours work by a talented programmer should suffice, don't

you think?

A day in the life…



5



6

Chapter 3: Using Life Cycles

Life Cycle:

“The way you and the team organize the work of

product development.”

“When… to define requirements, design, develop, and

test, as well as concurrently.”

There is no one right way… it depends.

On what?



7

What process?

• Evidence… shops that had no well-defined process were unable to deliver on-time with expected features.

• There is no “Best Practice” process.

Necessary but not necessarily sufficient

• Every project is different, every team is unique… the Project Manager decides what works & what does not.

• The methodology chosen should include periodic reevaluation and inclusion of practices that fit your project and your team.

Ship It! A Practical Guide to

Successful Software Projects.

Richardson & Gwaltney.

Pragmatic Bookshelf, 2005



8

Figure 3.1

Type Examples

Strengths & necessary conditions

for success Project Priorities Prognosis for success

Manages cost risk. 1. Features set

Known and agreed upon 2. Low defects

Well-understood system architecture 3. Time to release

Requirements stable over the project

Project team stable over the project

Manages technical risk 1. Features set Successful assuming the

Ever-evolving requirements 2. Low defects finishing parts are

3. Time to release and occur.

Manages schedule risk. 1. Time to release Successful

Can absorb small requirements 2. Low defects

changes but not enough changes that 3. Feature set

affect the architecture.

Manages both schedule & technical

risk 1. Time to release Successful

Difficult to do well without a 2. Feature set

integrated team. 3. Low defects

You guys start coding; 1. Time to release Unsuccessful

I’ll get the requirements” 2. Feature set

3. Low defects

Waterfall,

Phase gateSerial

Successful with feedback

Ad hoc Code & fix

Spiral,

evolutionary

prototyping

Iterative

Design to

schedule,

staged

delivery

Incremental

Agile (such

as Scrum,

XP)

Iterative /

Incremental



9

Figure 3.2 Serial

Requirements Analysis Design Code Integration Test

Iterative

Requirements

Prototype:

Analysis,

Design, Code

Prototype:

Analysis,

Design, Code

Prototype:

Analysis,

Design, Code

Integration Test

Incremental

Some

Requirements

Analysis to

choose overall

architecture

Design, Code,

Integrate &

Test

Design, Code,

Integrate &

Test

Final

IntegrationFinal Test

Agile

Some

requirements /

Planning

Timebox TimeboxRepeat as

neededTimebox Timebox

Each timebox results in running tested features.

CSc 233 Spring 2012



10

Figure 3.2 Serial


Iterative

Requirements

Prototype:

Analysis,

Design, Code

Prototype:

Analysis,

Design, Code

Prototype:

Analysis,

Design, Code

Integration Test

Incremental

Some

Requirements

Analysis to

choose overall

architecture

Design, Code,

Integrate &

Test

Design, Code,

Integrate &

Test

Final


Agile

Some

requirements /

Planning




CSc 233 Spring 2012



11

Figure 3.2 Serial


Iterative

Requirements

Prototype:

Analysis,

Design, Code

Prototype:

Analysis,

Design, Code

Prototype:

Analysis,

Design, Code

Integration Test

Incremental

Some

Requirements

Analysis to

choose overall

architecture

Design, Code,

Integrate &

Test

Design, Code,

Integrate &

Test

Final


Agile

Some

requirements /

Planning




CSc 233 Spring 2012



12

Figure 3.2 Serial


Iterative

Requirements

Prototype:

Analysis,

Design, Code

Prototype:

Analysis,

Design, Code

Prototype:

Analysis,

Design, Code

Integration Test

Incremental

Some

Requirements

Analysis to

choose overall

architecture

Design, Code,

Integrate &

Test

Design, Code,

Integrate &

Test

Final


Agile

Some

requirements /

Planning




Completed features at the end of each iteration



13

Combination: Iterative & Incremental

Feedback needed:

• To assess remaining project risks

• To assess project’s state

• To assess how quickly the team can produce working

software

The more you know, the better you can predict “done”.

Initial pass at

requirements

Prototype what we

do know about.

Get feedback.

Select an

architecture

Fully implement 3

features,

integrating as we

go.

Test architecture

Demo what we

have.

Keep

implementing,

integrating as we

go.

Final test.

CSc 233 Spring 2012

Incremental development

• Scheduling and staging strategy in which the various parts of

the system are developed at different times or rates, and

integrated as they are completed.

• It does not imply, require nor preclude iterative development

or waterfall development - both of those are rework strategies.

• The alternative to incremental development is to develop the

entire system with a "big bang" integration.



14

CSc 233 Spring 2012

Iterative development

• Rework scheduling strategy in which time is set aside to

revise and improve parts of the system.

• It does not presuppose incremental development, but works

very well with it.

• Typical difference is that the output from an increment is not

necessarily subject to further refinement, and its testing or user

feedback is not used as input for revising the plans or

specifications of the successive increments.

• The output from an iteration is examined for modification, and

especially for revising the targets of the successive iterations.



15



16

Fig 3.7 One Large Project Life Cycle

Prototype

architecture and

select product

architecture

Design, code,

integrate and test

features D, E, F,

G, H

More stages of

Design, code,

integrate and test,

including add

more smoke tests

Initial

Definition of

Requirements

Final

integrationFinal test

Select test

architecture

Develop whole

product smoke

tests

Develop first

pass of system

tests to verify

release criteria

Develop system

tests to test

features A, B, C in

more depth

More iterations of

adding more

detailed system

tests and adding

more tests to

verify release

criteria

Design, code, integrate and test

features A, B, C: add to smoke tests

were makes sense

Developer Life Cycle

Tester Life Cycle



17

Feedback

Design

Debug Code

Test



18

Code & Refactor Loop

Refactor

Test

Code

Start a feature

Build at least daily

CSc 233 Spring 2012



19

Waterfall

Agile

CSc 233 Spring 2012



20

Waterfall Project Team

Agile Project Team

CSc 233 Spring 2012



21

Waterfall Project Scope Change

Agile Project No Scope Change



22

Architectural Risk

• Risk is that the architecture will not work for all

features.

• Why would the Waterfall life cycle be the riskiest for

managing architectural risks?

“The only way to really manage architectural risk is

to implement something and test it.”



23

Stuck with a serial lifecycle!

• Plan to iterate on everything (planning, requirements

& prototyping)

• Prototype and show your customer as much as

possible as early as possible.

Feedback!!!

• Integrate testing from the beginning… work with the

testers.

• Implement by feature, integrating and testing…

• Documentation? Yes, but it’s not the deliverable.



24

The author’s favorite Life Cycle

• Agile is her first choice… but!!

If the customer is not readily available,

If the team members are not “into” collaborating,

If the team members are not disciplined,

forget it!

• Regardless, staged delivery is recommended.

Finished features get pushed out as soon as

possible.

chapter 1: starting a projectathena.ecs.csus.edu/~buckley/csc233/csc233_chapter3.pdf · management....

Documents