search

ai-se / phaseDelay

does phase delay increase bug costs?
2 stars 1 forks source link

trying to explain phases in a cyclic progress #27

Closed timm closed 9 years ago

timm commented 9 years ago

Hey Bill, is there any issue here:

Is each such cycle its own before/planning/req/des/code/test thing? or, do folks go agile spinning between (say) req/des or (say) res/code?

please advise

t

WilliamNichols commented 9 years ago

Distinctions without a difference. There is a lot of confusion on this point about what agile does and does not do. A lot of it is nonsensical argument about the semantics with different people meaning different things. TSP teams work in ways that are more or less agile. This is supported by the inclusion of TSP in the most recent State of Scrum reports as a (minority) agile method.

First, the TSP "phase" is an accounting concept. Phase is a logical concept related to, but not quite the same as an activity. Think of "coding" as "mostly coding, but not testing a feature yet" Every component or feature must pass through the logical phases from concept to completion. Modern agile largely conflate design, code, and unit test but maintain broader distinctions that they resist calling "phase", but that's what they are. For example, "idea", "ready (groomed)", "in progress (design/code/UT)", "tested (code complete) ready for integration", "accepted", "released" are phases I pulled from data from Rally.

By the time agile gets to the "in-progress" they are implementing a functional requirement, or a small slice of that requirement (a story). They cycle back to requirements in later cycles with new features.

TSP gathers more detailed accounting in the "in-progress" stage. Almost every team uses some form of incremental build with components representing either modules or features that cut across multiple physical components .

TSP teams will cycle back to requirements if the requirements are not stable. This will usually only be seen on a longer project. With a duration of 1-3 months, requirements seldom change a great deal.

timm commented 9 years ago

"TSP teams will cycle back to requirements if the requirements are not stable. This will usually only be seen on a longer project. With a duration of 1-3 months, requirements seldom change a great deal."

ok... answer me this next question and we are done

in january, we spec a project before1,req1,design1,code1,test1

in march, we are into code1 and the requriements become unstable

so back we go to req2,design2,code2

now when we say, in code2 that an issue "comes" from requirements, do we mean req1, req2, or something else?

WilliamNichols commented 9 years ago

If you are in code 2, or UT 2, it would be the requirements 2 for that coding. If you were in a post code complete testy phase, or Product LIfe, then likely it meant requrements 1.

A typical req 2 defect would be "where was that input supposed to come from? or what are the legal bounds?", These are questions a developer might ask if he/she was confused as to how to implement a requirement.

SO the removal phase should give you a pretty good indication of how old the defect is.

a Req 1 defect would likely have a removal in system, acceptance, or product life. life defect is more likely to be something like to be "user/ttest exceeded bounds,

Your mielage may vary, just as with agile teams depending upon whether thers is an independent QC group performing test.,

Sent from my iPhone

On Aug 14, 2015, at 2:43 PM, Tim Menzies notifications@github.com<mailto:notifications@github.com> wrote:

"TSP teams will cycle back to requirements if the requirements are not stable. This will usually only be seen on a longer project. With a duration of 1-3 months, requirements seldom change a great deal."

ok... answer me this next question and we are done

in january, we spec a project before1,req1,design1,code1,test1

in march, we are into code1 and the requriements become unstable

so back we go to req2,design2,code2

now when we say, in code2 that an issue "comes" from requirements, do we mean req1, req2, or something else?

— Reply to this email directly or view it on GitHubhttps://github.com/ai-se/phaseDelay/issues/27#issuecomment-131206403.

timm commented 9 years ago

oooooh..... so its "waterfall" per cycle and there can be many cycles

WilliamNichols commented 9 years ago

Yes. At least close enough. which is the typical way scrum sprints are organized. Functionality is fixed during the sprint. Unstable requirements usually manifest as work added to the baseline plan. I do 't have that baseline at this time. Waterfall is used as a pejorative, so i usually avoid it because it many stop listening after they hear "waterfall". When someone says that they read Royce, I can't help thinking wanda's reply to Otto in that john Cleese movie

Otto, I'm not an ape, apes don't read philosophy" Wanda "yes they do Otto, they just don't understand it"

Sent from my iPhone

On Aug 14, 2015, at 3:47 PM, Tim Menzies notifications@github.com<mailto:notifications@github.com> wrote:

oooooh..... so its "waterfall" per cycle and there can be many cycles

— Reply to this email directly or view it on GitHubhttps://github.com/ai-se/phaseDelay/issues/27#issuecomment-131218084.

timm commented 9 years ago

If you are in code 2, or UT 2, it would be the requirements 2 for that coding. If you were in a post code complete testy phase, or Product LIfe, then likely it meant requrements 1.

oooops... hang on... does that mean phase delay would rarely be observed by us since often we are just throwing back to recent errors in the same cycle (which would not be long ago)?

WilliamNichols commented 9 years ago

We see phase delay, but should be cautious about what is measured Defects have a log entry for 1) a phase injected 2) a phase found, and 3) a wbs item or component containing the defect

A requirements defect in test is a big delay. A requirements defect in code is a smaller delay. Determining if the requirements bug was a recent injection or recently discovered is another matter, but if you are not finding lingering defects in some sort of test, you have big problems.

There are some costs we do not measure, such as help desk processing, QA tracking, and patch deployment. What we see is the developer facing cost of a bug found in review, inspection, test, or product life. A cleaver told me he measured the QA overhead of processing a bug at about 7 hours. When we measure field bug fixes we typically get about 1,6 per calendar week across several demanding domains.

Sent from my iPhone

On Aug 14, 2015, at 4:55 PM, Tim Menzies notifications@github.com<mailto:notifications@github.com> wrote:

If you are in code 2, or UT 2, it would be the requirements 2 for that coding. If you were in a post code complete testy phase, or Product LIfe, then likely it meant requrements 1.

oooops... hang on... does that mean phase delay would rarely be observed by us since often we are just throwing back to recent errors in the same cycle (which would not be long ago)?

— Reply to this email directly or view it on GitHubhttps://github.com/ai-se/phaseDelay/issues/27#issuecomment-131236956.

timm commented 9 years ago

k

WilliamNichols commented 9 years ago

Btw,

NASA makes a habit of sending out missions before software is finished. Yes, a requirements defect on a deployed and remote piece of hardware does seem like it could be expensive. There are some extraordinarily expensive failures in defense and aerospace.

It also confused the issue when high assurance is conflates with cost of quality. DO-178b/c will be expensive even if no defects are found because MCDC test is expensive. The reported defect levels, ( 0.1 degrees per KLOC) however, are very good but not extraordinary. We've seen defects per MLOC done at normal dev rates., but no exhaustive testing as regulators require.

The other problem

Sent from my iPhone

On Aug 14, 2015, at 5:51 PM, Tim Menzies notifications@github.com<mailto:notifications@github.com> wrote:

k

— Reply to this email directly or view it on GitHubhttps://github.com/ai-se/phaseDelay/issues/27#issuecomment-131247349.