The basics of software engineering practices have not changed a lot during the last 25 years. Of course we have seen the introduction of new paradigms like object oriented and agile methods. But the basic principles behind quality are still the same.
When the software labor effort in a product of a company grows from a very small size with one or two developers to more than 15-30 developers, this usually puts new demands on both software processes and software architecture to cope with the increased group of developers working with the same piece of the code. Two developers can handle requirements, configuration management, quality assurance, project planning and follow up in a more informal way than is possible in a larger team. With a larger team a lot of communication problems arise that do not exist when the team is smaller.
There are still three elements that are essential to assuring good quality in software products. These three areas (called elements) are defined in Baker (2007). These elements are:
·
Establish Requirements and Control Changes
·
Evaluate Process and Product Quality
·
Establish and Implement Methods to Achieve Quality (methods to build
quality into products or other entities)
Establish Requirements and Control Changes includes definition of the requirements of the product and the control of changes of the requirements. In this area we need a process for establishing the requirements. We also need a defined process for controlling changes of the requirements, like a Change Control Board (CCB). The important thing is not what the process looks like, but that there exist a process that handles the requirements in a controlled way. The importance is on always knowing what to do and what is the most important for the project. It can be done differently depending of which software development model that is being followed. For instance the requirement definition process for the Waterfall model and the Agile model will obviously look very different. But the most important, for both models, is that the engineers always know what the customer needs, so that development can be focused to those areas.
Evaluate Process and Product Quality includes the definition of the testing processes, but also the process for making sure that the processes that are defined in the organization are being followed. Just like within development, testing has its own test models that there has to be decided which one to follow in this particular case. There also has to be a routine for continuously checking that the teams are following the processes defined, if there are any problems in the current processes and a way of changing and improving the current processes.
Establish and Implement Methods to Achieve Quality (methods to build quality into products or other entities). This area defines processes to establish what shall be done and by whom. So development, configuration management, project planning, project follow up and role definitions need to be defined and put into use. You have to decide which development model to use, is it a Plan-and-document model or a more Agile model like Scrum or Kanban? You also need to consider how to keep track of all the artifacts that are being developed in the projects. This is done in the configuration management process.
We have to keep in mind that there is no proofs that a structured and consistent usage of processes will lead to better quality products. Gibson (2006) has studied 35 organizations and measured their improvements on cost, productivity and quality. And have found empirical evidence supporting the connection between these three elements and better cost, productivity and quality.
Although there is general belief that the use of a structured, consistent process will lead to better quality products, a number of researchers point out that the cause and effect relationships have not been established quantitatively. Thus, the relationship between quantitative measures of process quality and their relationship to product quality has not been clearly demonstrated. However, there is empirical evidence supporting our intuitions that there is a connection, i.e., a cause and effect relationship (Baker 2007).
The other area that will be affected by the number of engineers working with the software system is the architecture. There will not be a lot of problems with the architecture due to communication issues in an organization with one or two engineers. But when the size of the organization increases, the software architecture needs to be refactored in a way that supports the number of developers involved in the project.
·
(Baker 2007)
Basic principles and concepts for achieving quality, Emanuel R. Baker, Mattew
J. Fisher, 2007, Software Engineering Institute, Carnegie Mellon University
·
(Chrissis 2006)
CMMI: Guidelines for process integration and product improvement, M. B.
Chrissis, M. Konrad, S. Shrum, 2006, Addison-Wesley
·
(Gibson 2006)
Performance results of CMMI-based process improvement, Diane L. Gibson, Dennis
R. Goldenson, Keith Kost, July 2006
