Re: [RFC] Software Process Improvement in Free Software, Closing the Quality Cycle, Inventing Non-Developer-Demotivating QA/QM/SPI
Hello Martin,
Martin Schulze wrote:
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.
As I mentioned, this is subject for research. And I was on error with
ISO 9001, sorry, the old ISO SW-QM standard has been ISO 9000-3 (part
three) and some ANSI standards in U.S. and I've never seen a
SW-organisation certified with ISO 900x. The assessments and SPI
standard is ISO (TR) 15504, most used in Europe, in the U.S. CMMx is
preferred.
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.
No, I cant agree, such processes are definitely not possible for SPI or
higher level QM-Projects AND it's been even no more "best practice" and
recommended in driving software development projects for at least 10
years. Implementing before analysis, controlled project-/teammanagement,
has shown up as "resource wasting", sorry. So SPI (Software Process
Improvement) targets Project Management mainly, as known source of most
bug hazards in the end.
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.
Its easy. Take a look at esi.es and sei.cmu.edu, practical introduction
presentations are to find on many websites of consultancy companies.
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.
So in automotive with extensive outsourcing.
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.
I meant exactly Your statement "show me code" above, thats descriptive.
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.
No (or I do not understand what You mean by that).
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.
Research.
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.
I'll try gladly and report success and failure.
Regards,
Joey
Y
Tom
Reply to: