Processes are part of the constructive quality
assurance. Their major benefit is process reliability through defined working
procedures. I state that commercial software development cannot be successful
without processes.
Even agile methodologies as Scrum follow own processes.
They are also based on a schedule planning which is characterized by shorter
release cycles (sprints) compared to “heavy weighted” process models. Vice
versa most of the (non-agile) process models are also able to deal with
short-term changes of the project goals and requirements.
The world of software development is not polarized to
agile methodologies versus derivatives of the classical waterfall model.
Actually the different models differ primarily by the explicitness of their
process definitions, by the flexibility how processes and methods can be
tailored to different conditions and by the importance of process compliance
towards human interaction or required changes.
My experience is that the definition of quality gates
is more important than process compliance. Quality gates assure the quality of
an input or output artifact of a process, iteration or project stage. They are
defined by checks (test methods or threshold values for metrics) and according
success criteria, which a test object (artifact) must fulfill to pass the gate,
i.e. that the artifact can be used respectively handed-over to the next
development step. An example is the check of requirements for conformity with
the project goals, feasibility, completeness, consistency, etc. after the
business analysis. The meaningfulness of such a quality gate is not a question
of light or heavy weighted or agile process models.
No comments:
Post a Comment