Exploratory Development

Software quality assurance is usually understood as ensuring that a process is adhered to. But does just following a process guarantee sufficient quality? Perhaps, if a process contains focus on quality and means to maintain it. And there are right people.

Of course, theorists would say that a process guarantees quality, that all problems are caused by violation of procedures or the project is “wrong” or all mistakes because of people not of the process. But in reality people are the most important part of success and even thorough formal adherence to the process can result into failure. Therefore software quality assurance is a misleading term. It doesn’t ensure quality of a product; it merely ensures compliance with the process.

Let’s focus on ensuring quality of a product, not just adherence to a process. Quality can be controlled or it can be built into the process of product’s creation. These approaches complement each other. If there is only control then a company will have to spend much resource on rework of low-quality stuff, if there is no control at all then risk of producing a product of inadequate quality is higher.

To increase quality the team can use some tools and techniques. It’s important to assure that we know what is to be built, how to build it properly and how to test that a product built is what the customer needs.

Quality assurance is quite a big topic. There is lots of information about each of tools mentioned below; this article is aimed at providing brief overview. Bearing in mind focus on quality one should pay attention to at least the following areas:

• Requirements gathering and analysis
• Development
• Preventing problems in the future

Read more…

Is Scrum better than RUP?

Yes.

No.

That’s an incorrect question. We can’t say that Scrum is better than RUP because we can’t compare them reliably. In fact a process is a multidimensional essence. As you know from math we can’t compare two vectors – only their norm. And norm can vary depending on the space. The same is true for processes – to compare them we need single value to work with and context.

Success rate? It depends heavily on project size, executive involvement, whether requirements are stable or not, etc.

Any process has some ideal context in which it is the most useful. We can’t say that one process fails more often – this process may have been applied in a wrong environment. For instance, if one is going to apply pure Scrum in development of new Boeing – he’d better think again. And if one is going to use full-blown process in accordance to government military agencies’ norms for developing small web-site s/he will have tough time trying to get profit.

It makes sense to bear in mind while choosing, designing or adjusting a process:

• Project’s context
• Industry experience
• Needed level of flexibility and reliability

Read more…