Description of the Scenario
The basics of software engineering has not changed a lot 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 in a product in 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
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 the software product. 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 main importance is that the process is engineers
always know what is needed by the customer of the system, so that they can
focus on development in 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 check that the teams are following the processes
defined and if there are any problems in the current processes 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.
Main
challenges
Here are some of the very characteristic problems that you
will see in an organization that is growing rapidly:
- The product management experience that they do not get the
requirements that they have asked for.
- Even more alarming they do not get an
insight into the status of the project is or when the requirements can be
implemented.
- Projects are
constantly slipping schedule.
- Problems delivering with quality on time.
- The software development process becomes slower and slower.
- The software organization gets a bad reputation for never
finishing projects on time and always having quality problems.
When your organization experience these issues, you
probably need to implement the Essential software engineering quality principles in your organization. If your
organization is experience the problems above, then it is very probable that
you have problems with the architecture. Then your organization need a
refactoring of the architecture to better support the new number of developers
that are currently working on the code at the same time. See the architecture
scenario.
When implementing the Essential software
engineering quality principles Scenario in your organization, you need to implement the
different principles differently depending on which development method your
organization is using or plan to be using. If your organization is using a
Plan-and-Document software development processes (like Waterfall, Spiral or the
Rational Unified Process (RUP) lifecycles) or an Agile (like Extreme
Programming (XP), Scrum or Kanban) the implementation of the Essential software
engineering quality principles will be done differently.
Main Business drivers and Growing pains
The main business drivers for the Scenario Essential
software engineering principles are:
- Improvement of cost, performance and quality is
needed
- Improvement of quality towards competition
- Implement a future proof architecture
When implementing dealing with problems in this Scenario,
very often companies has to deal with other drivers as well. The other drivers
are not the main drivers for this scenario, but they might be the reason that
the software organization is growing in the first place. Some examples of those
drivers are: safety standard, frequent releases to customer, selling additional
features, wider product range, ease for customers/update service, new services,
maintenance and intelligence/self-diagnostics and new markets.
Relation to other areas outside the software
development organization (product management, sales, HR, sourcing ...)
There is a lot of
relations to other organizations outside software. The software
organization is due to the problems they have with the growth not considered to
be very trustworthy on delivery times and functionality. Sometimes software
organization is also considered incompetent due to those problems. It is
important to understand that the software organization has those problems not
because they are incompetent, but due to the rapid growth of the organization
without defining the new way of working. However this is possible to change, by
following the principles described in this chapter.
When introducing a
more formal process for software development it will directly affect other
departments as well. Usually other departments outside software like the
freedom that comes with the more informal process. However they do usually not
realize that the informal process might work for a couple of software
engineers, but definitely not for 20 or more engineers. So a more formal
requirement process will get some negative comments from organizations around
the software organization. Also the configuration management process defines how
software is delivered and deployed. This of course is affecting the other
organizations around the software organization, like the product management,
sales, electronics and hardware organizations.
Summary of literature study and references
- (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
