Quality Assurance (QA) vs Quality Control (QC)

You've been wondering about the difference between these two terms? Read further
.
Quality assurance is all the planned and systematic activities implemented withi
n the quality system to provide confidence that the project will satisfy the rel
evant quality standards.
Quality control involves monitoring specific project results to determine if the
y comply with relevant quality standards, and identifying ways to eliminate caus
es of unsatisfactory results.
So in other words:
-QA is a group of processes in place to make sure that an organization document
what they do and they do what they document. Think about audit, ISO 900x, CMM. T
he goal here is to prevent the defect.
-QC is to control the product to make sure it complies with a defined standard.
Think about unit test, integration test, system test. The goal here is to detect
the defect then fix it.
===========================
Agile vs. RUP
At our company we have these meetings, where people from the same competence in
a region come together to talk about all kinds of stuff, from business related t
o more fun related stuff. Because I went to the Dutch Developer Days 2005 with E
dwin Waegemakers, we were asked to do a little presentation. We decided to give
three small presentations, one about Team System, one about integration strategy
and one about Agile Development. I would do first and last.
I've written about the Agile presentation at DevDays before and planned to use i
t in my own presentation, but a little less on the archetypes and a little more
my personal experience. The plan was to bring it lightly and at the same time tr
igger our RUP 'specialists' as an Agile hooligan, and I can say it worked pretty
well. I placed Agile strongly against RUP, although in practice this of course
isn't the case. Or at least not as hard as I had put it.
Agile vs. RUP
For a lot of developers documentation can be a drag to write. I have a personal
experience on a project I joined, where they over-used RUP. Normally you get a p
ile of documentation of about 2" high. On the project, I got a pile of about 10"
high. If I wanted to read that through, before actually doing something useful.
The project had just started, and there wasn't anything in it like functional s
pecs. Just project guidelines and rules and technical visions, etc, etc, etc. So
I used that in the presentation, with the Agile tenet to produce working softwa
re over extensive documentation. I highlighted extensive, as some people got the
idea Agile has no documentation at all. That triggered some reactions!
Fun thing was, that our director just had seen a presentation last week, where R
UP was presented as thé answer to all problems in projects, sort of speak. This we
ek I presented it as if RUP was about just documentation, and Agile development
would really work. His conclusion was that now he knows he's getting old, as he
had never seen (technological) advancements update so fast. Last week RUP was ev
erything, now it's already outdated and replaced. ;-)
Project swing
Of course Agile isn't a replacement for RUP and you cannot appoint one as a clea
r winner. I don't think that's necessary either. I think RUP is great, but you h
ave to have experienced people doing RUP projects as you don't want to overload
everyone with documentation, but also have to carefully look at what the custome
r wants. RUP also uses iterations, but for some reason I have the feeling Agile
development can better understand and react to what the customers needs, not wha
t he thinks he wants. That comes to show in this funny picture of a swing. It's
funny to see how everyone within a project has (or can have) a different view on
the swing. I think it's hard to get the same swing in every picture. But my bel
ieve is, it's much harder to retrieve from a customer to what he really wants an
d needs. To get the same picture in how a customer explains it and what a custom
er really needed, you need good iterations and a lot of communication. For some
reason, I have the feeling communication in RUP is more through documents where
as in Agile it's face to face communcation between the customer and the entire t
eam. And I think that's an important difference.
Of course everything should still be managed, also documentation. ;-)
I'm particullary interested in how to manage the customer and/or final deadline.
Once the customer gets the hang of changing and adding functionality, how can w
e manage them and the project so that we can deliver what we promised up front,
and still meet some final deadline. Where is the line, between making agreements
with a customer, and kind of just see what happens?
For those who want to know more about Agile Development :
Manifesto for Agile Software Development - Some big names are behind Agile.
Martin Fowler's New Methodology
Agile via SCRUM can be found on ControlChaos
Agile via Extreme Programming
Agile Methods
Darrell Norton's weblog
Steve Eichert's weblog