Cell Phone Software Forum
| View previous topic :: View next topic |
| Author |
Message |
Phlip
Guest
|
 Posted: Sat Apr 14, 2007 6:05 pm Post subject: Re: Agile/Iterative methodologies taught in Universities ? |
 |
|
Vladimir Trushkin wrote:
| Quote: |
Phlip wrote:
Andy Champ wrote:
Yes, folks, they were told to use Agile methods on one of those few
occasions when a waterfall method was the correct choice.
In what order should they do the requirements?
Waterfall is never the "correct choice". It's the admission of defeat -
that
you can't change a design easily or deploy early and often.
Waterfall in its pure form is no more relevant and is not used.
Iterative development has taken its place long ago. Please refer to
valid arguments.
|
Yeah, Andy. Get with the program!
--
Phlip
http://www.oreilly.com/catalog/9780596510657/
"Test Driven Ajax (on Rails)
assert_xpath, assert_javascript, & assert_ajax |
|
| Back to top |
|
 |
| |
Ads |
Advertising
Sponsor
|
|
Vladimir Trushkin
Guest
|
| Posted: Sat Apr 14, 2007 6:32 pm Post subject: Re: Agile/Iterative methodologies taught in Universities ? |
|
|
On Apr 14, 5:05 pm, "Phlip" <phlip...@yahoo.com> wrote:
| Quote: |
Vladimir Trushkin wrote:
Phlip wrote:
Andy Champ wrote:
Yes, folks, they were told to use Agile methods on one of those few
occasions when a waterfall method was the correct choice.
In what order should they do the requirements?
Waterfall is never the "correct choice". It's the admission of defeat -
that
you can't change a design easily or deploy early and often.
Waterfall in its pure form is no more relevant and is not used.
Iterative development has taken its place long ago. Please refer to
valid arguments.
Yeah, Andy. Get with the program!
|
I guess Andy means waterfall as something opposite to agile, which is
not necessarily a big-bang design following by a big-bang
implementation, etc. If I am wrong I apologize sincerely.
----
Best Wishes,
Vladimir |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Randy MacDonald
Guest
|
| Posted: Sat Apr 14, 2007 6:48 pm Post subject: Re: Agile/Iterative methodologies taught in Universities ? |
|
|
"Alexei Polkhanov" <apolkhanov@relic.com> wrote in
news:1176424201.068237.147010@p77g2000hsh.googlegroups.com:
<snip>
....
| Quote: |
If you need proof - you can easy obtain it yourself if you look for
process artifacts on your last project. Doe it have title with clearly
stated version? Do you have index and traceability matrix to design
documents, test plans and maintenance plan? Are all articles only
contain single requirement? Are they numbered? Is it clear where every
article originated from? Do all diagrams comply with notation (i.e.
class cardinality specified correctly etc.). Verify if every article
can be traced to article in test plan and allocated to entity
described in design document.
Another problem with "agile" processes is that they are simply not
VERIFIABLE processes. They live very little artifacts like
documentation and collected metrics so you cannot verify how closely
they have been followed or how effective they are at the end. In this
respect they more like a religion, because they just give you system
of beliefs not the well documented and traceable process. In order to
provide this traceability and visibility "HEAVYWEIGHT" processes were
created and there is no way around it.
|
I'll assume your words are not flamebait. The tests one writes for TDD
are the most _precise_ and _complete_ verifications I've ever seen.
Verifiability is the core of agile mehodologies. "must pass all the
tests" is actually a very powerful requirement. The existence of tests
which provide 100% coverage _by definition_ put most if not all of these
artifacts you espouse in the redundant, therefore waste, pile.
--
------------------------------------------------------------------------
|\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram)
|/\| ramacd@nbnet.nb.ca |
|\ | | The only real problem with APL is that
BSc(Math) UNBF'83 | it is "still ahead of its time."
Sapere Aude | - Morten Kromberg
Natural Born APL'er | Demo website: http://156.34.82.154/
-----------------------------------------------------(INTP)----{ gnat }- |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Phlip
Guest
|
| Posted: Sat Apr 14, 2007 8:54 pm Post subject: Re: Agile/Iterative methodologies taught in Universities ? |
|
|
Randy MacDonald wrote:
| Quote: |
Alexei Polkhanov wrote:
snip
...
If you need proof - you can easy obtain it yourself if you look for
process artifacts on your last project. Doe it have title with clearly
stated version? Do you have index and traceability matrix to design
documents, test plans and maintenance plan? Are all articles only
contain single requirement? Are they numbered? Is it clear where every
article originated from? Do all diagrams comply with notation (i.e.
class cardinality specified correctly etc.). Verify if every article
can be traced to article in test plan and allocated to entity
described in design document.
Another problem with "agile" processes is that they are simply not
VERIFIABLE processes. They live very little artifacts like
documentation and collected metrics so you cannot verify how closely
they have been followed or how effective they are at the end. In this
respect they more like a religion, because they just give you system
of beliefs not the well documented and traceable process. In order to
provide this traceability and visibility "HEAVYWEIGHT" processes were
created and there is no way around it.
|
In an XP project, you can add a 'raise "insert fault"' (a "throw") to any
block in the code, then you can count every developer and customer test that
now fails. The customer tests that fail _are_ the set of requirements that
require that block of code.
XP provides the features you request, both their benefits and their
side-effects. And XP provides them without overhead. You get them as a
by-product of working very rapidly, with a clean code base and a low bug
rate. You don't need to pay extra for them, or waste your productivity by
working too much on them.
| Quote: |
I'll assume your words are not flamebait. The tests one writes for TDD
are the most _precise_ and _complete_ verifications I've ever seen.
|
They are the best we have ever seen in practice, but not the best coverage
possible.
| Quote: |
Verifiability is the core of agile mehodologies. "must pass all the
tests" is actually a very powerful requirement. The existence of tests
which provide 100% coverage _by definition_ put most if not all of these
artifacts you espouse in the redundant, therefore waste, pile.
|
The problem with the statement hinges on the _definition_ of coverage. If
you mean branch coverage, such that at least one tests covers each sides of
every branch, at least once, that's what TDD provides.
If you mean exhaustive path coverage, it doesn't.
The benefits of TDD go beyond the static analysis of the code. TDD helps
resist bugs in new code. It helps entropy favor robustness. These are
unexplored concepts, well beyond the reach of "code coverage" questions!
--
Phlip
http://flea.sourceforge.net/PiglegToo_1.html |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Ron Ruble
Guest
|
| Posted: Sun Apr 15, 2007 3:12 am Post subject: Re: Agile/Iterative methodologies taught in Universities ? |
|
|
Alexei Polkhanov wrote:
| Quote: |
Agreed. RUP was the latest process framework to emphasize IID.
However,
many in the agile community have seen more than our share of iterative
processes degenerate into heavyweight, document-driven, waterfall-ish
processes. Agile takes the opposite approach in that it starts with a
bare minimum process, and adds to it only when the team determines
that
a little more process is warranted. RUP requires one to tailor the
process
by removing or altering unnecessary artifacts/roles/activities.
Unfortunately,
this is seldom done, and the result is a very heavyweight process.
Well and if you familiar with 12207 you know that there is a process
for tailoring acquisition process for certain needs. For example there
is no need to perform system analysis if software is not part of
bigger system. Note that failure to follow defined process does not
mean that problem is in process itself.
If you need proof - you can easy obtain it yourself if you look for
process artifacts on your last project. Doe it have title with clearly
stated version? Do you have index and traceability matrix to design
documents, test plans and maintenance plan? Are all articles only
contain single requirement? Are they numbered? Is it clear where every
article originated from? Do all diagrams comply with notation (i.e.
class cardinality specified correctly etc.). Verify if every article
can be traced to article in test plan and allocated to entity
described in design document.
Another problem with "agile" processes is that they are simply not
VERIFIABLE processes. They live very little artifacts like
documentation and collected metrics so you cannot verify how closely
they have been followed or how effective they are at the end.
|
I would have to say this strikes me as a misstatement.
Based on my understanding, agile does not preclude the
possibility of producing documentation or collecting
metrics. It simply is based on the idea that documentation
should exist for a -purpose- other than "we've always
done it this way", or to satisfy a need to impress with
the weight of documentation. A 40 pound tome which no
one reads is a limited value; a 2 page document or stack
of index cards which is referred to often is far preferable.
| Quote: |
In this
respect they more like a religion, because they just give you system
of beliefs not the well documented and traceable process.
|
I don't know about your experience; in mine, the documented
and traceable process is of no more value in and of itself
than smoke. It is of value as part of a delivered product.
If the product isn't delivered, the documentation is no
mitigating factor. I know of hundreds of failed projects
that were exhaustively and thoroughly documented.
| Quote: |
In order to
provide this traceability and visibility "HEAVYWEIGHT" processes were
created and there is no way around it.
|
In my experience, traceability and visibility are tangential
to the weight of the process, not a direct result of it.
I try to use agile methods as much as possible; and some
of the code, and the 2,3, and 4 page documentation
delivered with it are still in use as much as 10 years
later. Integrated into new applications, and extended for
other platforms.
And I've worked on heavyweight projects that never saw the
light of day and produced hundreds of pounds of documentation
that no one ever read. And consumed millions of dollars
in wasted funds. I understand the Dallas airport baggage
system, the FBI document management system, and the IRS
unified systems, all canceled with massive cost overruns,
are all extensively and well documented.
I'm not willing to say, as others have, that BUFD is evil
and agile is always good. But I believe strongly the
evidence of my eyes, and that evidence says that the
industry has real problems that aren't addressed adequately
by "the way we've always done it." |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Randy MacDonald
Guest
|
| Posted: Sun Apr 15, 2007 6:17 am Post subject: Re: Agile/Iterative methodologies taught in Universities ? |
|
|
"Phlip" <phlipcpp@yahoo.com> wrote in
news:uH7Uh.139$Yo2.22@newssvr19.news.prodigy.net:
| Quote: |
The problem with the statement hinges on the _definition_ of coverage.
If you mean branch coverage, such that at least one tests covers each
sides of every branch, at least once, that's what TDD provides.
If you mean exhaustive path coverage, it doesn't.
I can see where a lack of path coverage would occur if you do code-first, |
but I've never seen it demonstrated how these oncovered paths get
introduced unless you do more than the minimum required to pass the tests.
Do you have an example?
--
------------------------------------------------------------------------
|\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram)
|/\| ramacd@nbnet.nb.ca |
|\ | | The only real problem with APL is that
BSc(Math) UNBF'83 | it is "still ahead of its time."
Sapere Aude | - Morten Kromberg
Natural Born APL'er | Demo website: http://156.34.82.154/
-----------------------------------------------------(INTP)----{ gnat }- |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Phlip
Guest
|
| Posted: Sun Apr 15, 2007 7:08 am Post subject: Re: Agile/Iterative methodologies taught in Universities ? |
|
|
Randy MacDonald wrote:
| Quote: |
I can see where a lack of path coverage would occur if you do code-first,
but I've never seen it demonstrated how these oncovered paths get
introduced unless you do more than the minimum required to pass the tests.
Do you have an example?
|
No; maybe I use the verbiage wrong.
A truly exhaustive test suite would test every combination of every path
thru a program. That would take longer to run than the Sun will take to go
off main sequence.
You simply mean "branch coverage", where tests cover each side of every
branch.
--
Phlip
http://flea.sourceforge.net/PiglegToo_1.html |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Randy MacDonald
Guest
|
| Posted: Mon Apr 16, 2007 1:46 am Post subject: Re: Agile/Iterative methodologies taught in Universities ? |
|
|
"Phlip" <phlipcpp@yahoo.com> wrote in
news:wHgUh.4206$H_5.721@newssvr23.news.prodigy.net:
| Quote: |
Randy MacDonald wrote:
I can see where a lack of path coverage would occur if you do
code-first, but I've never seen it demonstrated how these oncovered
paths get introduced unless you do more than the minimum required to
pass the tests. Do you have an example?
No; maybe I use the verbiage wrong.
A truly exhaustive test suite would test every combination of every
path thru a program. That would take longer to run than the Sun will
take to go off main sequence.
You simply mean "branch coverage", where tests cover each side of
every branch.
|
I'm just looking for a demonstration of how, in a TDD context, this branch
coverage would differ from this exhaustive coverage. It's like you're
trying to refute mathematical induction.
later ...
------------------------------------------------------------------------
|\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram)
|/\| ramacd@nbnet.nb.ca |
|\ | | The only real problem with APL is that
BSc(Math) UNBF'83 | it is "still ahead of its time."
Sapere Aude | - Morten Kromberg
Natural Born APL'er | Demo website: http://156.34.72.215/
-----------------------------------------------------(INTP)----{ gnat }- |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Andy Champ
Guest
|
| Posted: Mon Apr 16, 2007 2:32 am Post subject: Re: Agile/Iterative methodologies taught in Universities ? |
|
|
Randy MacDonald wrote:
| Quote: |
I'm just looking for a demonstration of how, in a TDD context, this branch
coverage would differ from this exhaustive coverage. It's like you're
trying to refute mathematical induction.
|
I have two parts of the program, one with branches A or B, the other
with branches C or D. I can test each part of each branch with just 2
tests, one exercising A&C and the other B&D. But a true exhaustive test
would require you to test A&C A&D B&C B&D.
Andy |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Phlip
Guest
|
| Posted: Mon Apr 16, 2007 2:36 am Post subject: Re: Agile/Iterative methodologies taught in Universities ? |
|
|
Andy Champ wrote:
| Quote: |
Randy MacDonald wrote:
I'm just looking for a demonstration of how, in a TDD context, this
branch coverage would differ from this exhaustive coverage. It's like
you're trying to refute mathematical induction.
|
Thanks, Andy:
| Quote: |
I have two parts of the program, one with branches A or B, the other with
branches C or D. I can test
|
first
| Quote: |
each part of each branch with just 2 tests, one exercising A&C and the
other B&D. But a true exhaustive test would require you to test A&C A&D
B&C B&D.
|
--
Phlip
http://flea.sourceforge.net/PiglegToo_1.html |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Randy MacDonald
Guest
|
| Posted: Mon Apr 16, 2007 6:00 pm Post subject: Re: Agile/Iterative methodologies taught in Universities ? |
|
|
Andy Champ <no.way@nospam.com> wrote in
news:bMOdnfmF8p3jOr_bRVnygQA@pipex.net:
| Quote: |
Randy MacDonald wrote:
I'm just looking for a demonstration of how, in a TDD context, this
branch coverage would differ from this exhaustive coverage. It's
like you're trying to refute mathematical induction.
I have two parts of the program, one with branches A or B, the other
with branches C or D. I can test each part of each branch with just 2
tests, one exercising A&C and the other B&D. But a true exhaustive
test would require you to test A&C A&D B&C B&D.
Andy
|
I fail to see where these four parts A B C D came from. What tests failed
to cause them to be necessary? To me, such a structure comes from coding
first and retrofitting tests after the fact. Of course, like all overkills,
it will be expensive.
--
------------------------------------------------------------------------
|\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram)
|/\| ramacd@nbnet.nb.ca |
|\ | | The only real problem with APL is that
BSc(Math) UNBF'83 | it is "still ahead of its time."
Sapere Aude | - Morten Kromberg
Natural Born APL'er | Demo website: http://156.34.86.95/
-----------------------------------------------------(INTP)----{ gnat }- |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Anders Arnholm
Guest
|
| Posted: Tue Apr 17, 2007 12:22 pm Post subject: Re: Agile/Iterative methodologies taught in Universities ? |
|
|
["Followup-To:" header set to comp.software.extreme-programming.]
Randy MacDonald <ramacd@nbnet.nb.ca> skriver:
| Quote: |
Andy Champ <no.way@nospam.com> wrote in
news:bMOdnfmF8p3jOr_bRVnygQA@pipex.net:
Randy MacDonald wrote:
I'm just looking for a demonstration of how, in a TDD context, this
branch coverage would differ from this exhaustive coverage. It's
like you're trying to refute mathematical induction.
I have two parts of the program, one with branches A or B, the other
with branches C or D. I can test each part of each branch with just 2
tests, one exercising A&C and the other B&D. But a true exhaustive
test would require you to test A&C A&D B&C B&D.
I fail to see where these four parts A B C D came from. What tests
failed to cause them to be necessary? To me, such a structure comes
from coding first and retrofitting tests after the fact. Of course,
like all overkills, it will be expensive.
|
A and C probalt came from one unittest and B and D from an other, but
there doesn't have to exists a test that does the way of A and D, and
B and C to make the code needed to implement with a TDD strategy.
Test teory gives that we can and it may be relevant to add some more
tests to the suite.
/ Balp
--
http://anders.arnholm.nu/ Keep on Balping |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
223 Attacks blocked
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
