[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFC] Software Process Improvement in Free Software, Closing the Quality Cycle, Inventing Non-Developer-Demotivating QA/QM/SPI



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear Fabian,

Fabian Fagerholm wrote:
| On Mon, 2004-11-01 at 07:12 +0100, Thomas Schorpp wrote:
|
|>as i see you try to maintain quality in debian efficently.
|>
|>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.
|
|
| This sounds quite interesting, but I wonder if there is enough knowledge
| about these things in the Debian community to even have a meaningful
| discussion?

At least many experienced SW engineers and prooject leads, QMs who have
worked for the big ones (Siemens, SAP, HEIDELBERG) or automotive (BOSCH,
JOHNSON, VDO, HARMAN-BECKER, VW, PORSCHE, BMW, DC, HP, NASA) have at
least basic experience in these practices. I'd like to get assigned some
webspace on qa-debian.org to publish presentations and guides what
should convince the current team to be commited to extend QA to QM and
SPI with (my) help.

First Readings and base could be the mentioned SPR book, the SEI
(sei.cmu.edu) publications are more advanced but considered as too
"academic" in industry.

A most practical invention was the Rational's Software Unified Process,
prefered by developers. Even small and middle companies like it.

| It seems that issues about "process" are generally frowned
| upon, and it is a frequent topic for flamewars on the debian-devel list
| (and elsewhere).
|

I'm fully aware of that, so we've to invent systems for qualiy circles
not considerable to take the "typical" free linux developers their
freedom. A strongest requirement.
Most of the above models are for "herding" proprietary sw-development in
large organisations often implemeted in "misuse" of the standards for
negative additional "stress and power pressure" on hired developers
maintained by isolated teams of ph-d's of older age.
It's best practice to get the developers in and commited to the system (
at my knowlegde only HEIDELBERG has done so) or high risk of failure
would occur from the start.

First for us theres to be an research project with assessments due to
the advanced requirements to OSS, if sufficent output, after then the
implementation.


| In this sense, I would probably suggest to begin by trying to inform and
| educate the community in this area, and gradually build a knowledge base
| to enable this discussion.
|

I'm gladly ready to start if i've got the little resources needed to do so.


y
tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.90 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iQCVAwUBQYdjB2qsze5HSzyoAQJk0AQAzSYV1UvamV7HF0p9+4BatMt7GbMT0Q5Z
V0ewfXQZ6TcD5LfvpnaYL+9vhgeCphil6eMW3xaUf+fscT66ylHwPTXT3aZyk2Z2
E6e5+h3oX4ywK/y7e4ZeN8G+L0gC8NyFTbp8fgGs7IK4xjKdr2FJg2HGbflozKZy
QeaxU7gvmoA=
=9jGp
-----END PGP SIGNATURE-----



Reply to: