SPI in Embedded Software Applications
Bjarne Månsson 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 telecommunication networks.
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 and FPGAs.
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 like:
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 company:
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. [1]. 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. [2].
Requirement Management
Quality Assurance
Configuration Management
Project Tracking
Subcontract Management
Integrated Software Management
Process Definition
Training Program
Peer Reviews
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. [3] and [4].
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 requirements.
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. [5].
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 of:
As to the software project creation we confirmed the following items:
0,2..0,8
1..10
P*E
actions
- Are the technical requirements difficult? Is the product the-state-of-the-art?
- 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
External resources
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 following items:
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 specific level:
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. [7].
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. [8]. 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 improvements
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
SPI lessons learned
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 cycle
Beware of the SPI "silver bullet" life cycle, ref. [9]. 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