SPI in Embedded
Software Group Manager
BARCO Communication Systems Denmark
The main products in BCS Denmark are codecs: digital video
and audio compression equipment for high-quality transmission via common
The high-quality transmission usually relates to primary
contribution of video and audio
A corresponding audio codec features conversion of audio
signals at 384 kbit/s into compressed audio at telecommunication bandwidth
of 64 kbit/s.
Because of the high requirements to conversion rates,
the codec contains a lot of dedicated electronics in the form of ASICs
Embedded software applies system control and monitoring
but only signal processing at low bit rates (audio).
PC software is used to replace the equipment display and
keyboard featuring equipment control and monitoring.
Fig. BjM.2 : BCS product software techniques
Fig. BjM.3 : BCS product life cycle model
Though the product development complied with the life
cycle in all phases, the first releases experienced a number of drawbacks
During 1994, the BCS thought it would like to be ISO
9001 certified. At the preliminary auditions by the certification institute,
the software issue was brought up. The QA procedures were based on the
product life cycle model and as the product was mostly hardware based,
the software was only dealt with in 5 lines of text!
Another hint was given. The BCS had always promoted the
use of the latest development techniques, "the-state-of-the-art". When
somebody told the management that on a maturity scale from 1 to 5, BCS
was on level 1 (not telling, however, that so was the situation
for 90% of other companies too), an unsatisfied roar rolled through the
Do something about that software!
Better software in a shorter time at a lower price!
In my 20 years of software development, I have been
looking for some way to get hold of this unpredictable, shapeless, intangible
workmanship which somebody even has dared to call art. Though everybody
knew of the problems, no firm philosophy, method, or tool had emerged though
a few attempts had been performed, ref. . This is very strange taking
into consideration that hardware development is performed under well known
methods as described in the product life cycle.
And then it starts as "best practice" out of the experience
from many software developments’ "seek and try". The inspiration came from
the Capability Maturity Model CMM presented in Denmark during the spring
of 1995, ref. .
Integrated Software Management
Technology Change Management
Fig. BjM.4 : The CMM key process areas
Buzzwords arise all the time, and in 1995 everybody said
"OOM", "CASE tool", and "Reuse". The CMM indicated with which key process
areas to start. It is e.g. pointed out that no method or tool can solve
the lack of requirement specifications, and that in order to gain benefit
from reuse, configuration management must be introduced.
Later on, we did not strictly follow the order of areas
in the CMM, but we went more for every topic, which is also the basic idea
in the Bootstrap model.
In order to make the ISO 9001 certification possible,
the software was introduced into the QA procedures by software guidelines,
which give recommendations to the essential documentation of:
The first obvious result was the ISO 9001 certification
in mid 1995 in which software was an integrated part.
Another result was recordings of an improved error
rate measured on the codec RE 3400 releases.
Fig. BjM.5 : The RE 3400 error rates on releases
Despite good experience in writing software requirement
and design specifications, we were still having difficulties in revealing
all the relevant requirements from the hardware to the software. Though
everybody still said "OOM", we were advised in real time applications to
go for the Structured Analysis and Design. This was introduced in late
1995 together with the tool Select Yourdon, ref.  and .
Fig. BjM.6 : Example on SA/SD-RT
The original object of the SA/SD-RT was for the hardware
engineers and the software engineers to have a common base to discuss the
full implementation. But it turned out to be a method for the software
engineers to find all relevant questions in connection with the
Introducing the SA/SD-RT as early as in 1995 has enabled
us to revise the method and the tool to our specific use. An example is
that because we are not using entities (database data flows), we have removed
this item from our recommended templates.
In the software implementation phase we had to
set a number of rules:
We could now see that the oncoming projects required a
number of software engineers, which trigged off some more guidelines:
* Project : Demoproject for PVCS
* Used in : PVCS demonstration
* Description : The module only contains a
* demo description.
$Workfile: demo.c $
$Log: F:/sw_faggr/Projdemo/Source/vcs/demo.c_v $
* Rev 1.0 18 Feb 1997 13:34_08 BjM
* Description of the change in this revision
The software test and verification is a subject
too often put aside. In our case, we had already some very bad experiences
of not properly testing the software together with the hardware. Choosing
the V-model was very natural taking into consideration that the hardware
already followed this model, ref. .
Fig. BjM.8 : The test and verification V-model
But finding the proper method and tool to each of the
V-model stages turned out to be a difficult task. Software engineers were
used to test the software in the "monkey" way - testing what they thought
should be tested which is not much more than usual debug testing.
After some research, we recommended the test following
methods and tools:
One hurdle to overcome was the strong belief of every
software engineer that a test tool can do the methodical work too! "Is
the tool not able to generate the test case for me?" No, there is still
a lot of test work to do for the software engineer.
The management guideline contains the following subjects
As to the software project creation we confirmed
the following items:
- Are the technical requirements difficult? Is the product
- Is the market moving? Do we know the market?
- Do we usually see many errors after release?
- Are the goals too ambitious?
- Is the requirement specification well prepared?
Is the project plan by DR1 realistic?
- Do you expect additional resources during the project?
Do you expect overtime work?
Agreement with Barco
Fig. BjM.10 : Example of risk analysis
As to the software project planning we confirmed
the following items:
Fig. BjM.11 : QA checklist
As to the software project reviews we confirmed
the following items:
* Requirements mapped into the code?
* Is the SD-RT diagram implemented?
* Is the interface to the module OK?
* Is the code easy to maintain?
As to the software project follow up we confirmed
the following items:
Fig. BjM.13 : Example on QA deviation reports
As the software project metrics we confirmed the
Fig. BjM.14 : Release plan tracking
In BCS, the software metrics has been an overlooked subject,
so even if we did introduce these items to the projects, we could not retrieve
information from the "experience" database. And because we did not get
any immediate results out of the metrics, the trend was that we did not
even do any metrics on the new projects.
In summary we did not introduce any new software
project management items, but we merely confirmed the existing hardware
related items. In a few cases, e.g. risk analysis, we expanded the items
of the subject.
As to the action plans, we set the goal of reaching a
This is handled in the Bootstrap model, which compiles
all process improvements into a single number with divisions of a quarter.
In this way, even minor improvements can be measured, and you benefit from
measuring even small improvements, which is good for the motivation, ref.
The Bootstrap assessment can be performed by either self-assessment
or by certified assessment.
The self-assessment involves a questionnaire which one
or more people from the organisation may answer.
The certified assessment involves 3 days’ interview of
management and of a number of project groups made by external auditors.
At the end of 1996, BCS decided to do both a self-assessment
and a certified assessment. The self-assessment was based on three different
questionnaires and it gave the following results:
Fig. BjM.15 : Assessment results
The questionnaire containing most questions (SYNQUEST)
gets the nearest to the certified assessment (luckily enough!), ref. .
But anyhow, any self-assessment gives a clue of the present maturity level:
Better do some self-assessment than none at all!
You get most benefit from SPI if you apply the
on concurrent projects.
We applied the SA/SD-RT and implementation methods on
3 major projects with good results. But the introduction of the test and
verification V-model was delayed compared with the progress of the 3 projects,
resulting in a very bad software quality on one of the major projects.
Also, software project management was not introduced early
enough on the 3 projects. The software time planning (time estimates),
software project plan, and the risk analysis (all due in the early phase
of the project) were hardly used in the product project.
And now we have to wait for the next major project before
we can benefit from these methods!
An advantage of introducing SPI as part of the QA procedures
was that we were not delayed by any "pilot project evaluation". Though
we did some trial investigations before introducing a major new method
or tool, we gained a lot of knowledge and motivation from everyone being
educated to the same level at the same time.
Fig. BjM.16 : SPI Summary with respect to Concurrent Projects
Introducing SPI in a development-based company requires
a strong health and lots of good spirits - like in any other project matter!
But keeping some rule-of-thumb in mind can help you through
the strongest of bad luck.
Below I sum up some of the main good and bad experiences
from the 3 years of SPI introduction.
The SPI iceberg
Beware of the SPI iceberg. It is easy to "buy" a method
or a tool but it is much harder to get it working inside the company.
Fig. BjM.17 : The SPI iceberg
The SPI "silver bullet" life
Beware of the SPI "silver bullet" life cycle, ref. .
It is easy to set up unrealistic expectations to the outcome of the SPI,
but that only works until the SPI is being used in real life. The hard
work is to get SPI down to earth and get it working in actual practice.
Fig. BjM.18 : The SPI "silver bullet" life cycle
For the next action plan, the main topics will be:
A BARCO group member is the BARCO Communication Systems,
which is a world leader in high quality solutions for the broadcast, cable
TV and telecommunication markets with