Re: [RFC] Software Process Improvement in Free Software, Closing the Quality Cycle, Inventing Non-Developer-Demotivating QA/QM/SPI
Moin!
Thomas Schorpp wrote:
> ive been thinking for months now about inventing and adopting
> the SPI-standards cmm(x), spice, iso12207, and iso 9001,
> etc, in free sw's lifecycles
> and would like to ask you about comments and discussion.
I would first like to see how these techniques and measurements could
apply to Free Software at all when the software is not produced by an
entity certified with ISO 9001.
Only wanting to apply something doesn't help. In Free Software
there's a saying: "show me the code", which basically means that
somebody would have to try to apply these techniques first before a
discussion about creating web space, forming a group and the like is
useful at all.
What about you explain the basics of cmm(x), spice, iso 12207, and iso
9001 to the others and demonstrate how they apply to Free Software,
and to Debian in particular. I don't think everybody on the QA list
knows all standards, techniques, measurements and the like used in the
proprietary and closed software development area. I don't know all of
them, at least.
Debian is even very special in terms of software engeneering, since
most of the software the Debian project distributes comes from third
parties and not from the project itself.
> discussion/research points:
>
> 1. closing and improving the spi/qm/qa- cycle with the developers by
> analyzing their dev-processes, tools, configuration/analysis mngmnt and
> give non-demotivating feedback with
>
> -what i call now- "CMP" ( Capability Maturity Points), scale 10-100 (log).
>
> the classic industry way has shown up to be demotivating, developers
> would avoid the system or even trick it off.
The "classic industry way" doesn't apply to Free Software with very
few exceptions. Taking this as an argument pro/contra something is
moot.
> 2. escape the megawave of developer->feature->bug->developer bad cycles
> by targeting q-lacks at the beginning of a lifecyle leaving no stage
> uncovered, just building a dam against the bug-hazard at the end
> and maintaining old waterfall structures has shown up no more
> sufficent -UNDEPENDENTLY- of the size and amount of sw-project(s).
To me this sounds like you are trying to convert some random C*O to
fund your QA work. Please explain how you want to implement this.
I.e. how do you want to interfere the package development when
maintainers hardly have a chance to intercept.
Basically, the best thing to start would be to provide explanations,
a demonstration how the techniques apply to Debian and a plan on how
to continue.
Regards,
Joey
--
GNU does not eliminate all the world's problems, only some of them.
-- The GNU Manifesto
Please always Cc to me when replying to me on the lists.
Reply to: