CMM only specifies that there must be a requirements PROCESS that is followed; it doesn't require that this
process work completely or faultlessly (or at all!).
Sounds just like ISO-9000, then. Shame. Never mind.
But I could equally well make the same statement for the quality of screen or LCD panel that developers used.
That's legibility, not readability. Related, but distinct. I presumed that Stephen's question was in the context that the character glyphs were well-formed enough to be legible, and that his question was about recognising and making sense of them, not about being able to make them out at all.
Maybe it's worth complicating matters further by considering separately how to present things on screen and in print, since it's fairly well-known than a bunch of different constraints apply to the two cases.
It's just that Something that improved the capture of requirements by 0.5%
> is more likely to have a significant impact on the outcome of most software > projects than improving the readability of code by 300%.
Not wishing to be funny or anything, but how do you know? And taking your statement at face value, suppose the figures were 0.2% and 450%? What then?
To me, the outcome of most software projects is continuous, not discrete. The longer development flows, the more likely it is that stuff downstream from the requirements-gathering phase (such as, say, fixing a problem or adding a feature) has a noticeable impact on the project's pool of users. Especially when the code so unreadable to the next bucket of programmers on the job that it's more productive to redevelop than to suffer their attempts at modification. -- Frank Wales [EMAIL PROTECTED]
---------------------------------------------------------------------- PPIG Discuss List ([EMAIL PROTECTED]) Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss Announce admin: http://limitlessmail.net/mailman/listinfo/announce PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
