Table of Contents
Every project, irrespective of the domain, has processes associated with it. These process make sure the development goes through smoothly and mistakes are identified before they become catastrophic. They are a result of years if lessons learnt and experience.
However, we, being humans are not very inclined with following processes. Whats more, is that when it comes to embedded systems, this inclination becomes even more evident. Not only do we not want to follow them, there are often situations where the processes are either not matured enough or are missing.
I have seen, over many years, and experienced it first hand the benefits of having processes and the headaches of not having them. I have now become an ardent follower of documentation of every step and tell all my interns and team members to religiously follow it.
In this article, I want to bring out the common crimes committed in the development process and their impacts.
Informal development process
The process used to create embedded software is often ad hoc, and not written down. Team members come up with features or solutions to problems while having a chat over coffee and go over to implement them. These features or solutions are seldom captured. The steps vary from project to project and developer to developer. This results in uneven quality.
Not enough paper
Too often, too few steps of development result in a paper trail. For example, test results may not be written down. The common way is the person working on it checks if the test is passed or not. If something is not right, they think they will remember it and inform others later. The “later”, however, never comes and the problem is lost in thin air until it shows up during an investment pitch or product launch. Among other things, this can require re-doing tasks such as testing to make sure they were fully and correctly performed.
No written requirements
Software requirements are not written down or are too informal. They may only address changes for a new product version without any written document stating old version requirements. This can lead to misunderstandings about intended product functions and difficulty in designing adequate tests.
Requirements with poor measurability
Software requirements can’t be tested due to missing or subjective measurement criteria. As a result, it is difficult to know whether a requirement such as “product shall be user friendly” has been met.
Instead of a requirement being written as “product shall be user friendly”, the requirement should list down in details the aspects of ‘user-friendly.’ Each aspect should be captured as a requirement that can be tested.
Requirements omit extra-functional aspects
Product requirements may state hardware processing speed and hardware reliability, but omit software response times, software reliability, and other non-functional requirements. Implementing and testing these undefined aspects is left at the discretion of developers and might not meet market needs.
High requirements churn
Functionality required of the product changes so fast the software developers can’t keep up. This is likely to lead to missed deadlines and can result in developer burnout.
No SQA function
Nobody is formally assigned to perform an SQA function, so there is a risk that processes (however light or heavy they might be) aren’t being followed effectively regardless of the good intentions of the development team. Software Quality Assurance (SQA) is, in essence, ensuring that the developers are following the development process they are supposed to be following. If SQA is ineffective, it is possible (and in my experience likely) that some time spent on testing, design reviews, and other techniques to improve quality is also ineffective.
No mechanism to capture technical and non-technical project lessons learned
There is no methodical effort to identify technical, process, and management problems encountered during the course of the project so that the causes of these problems can be corrected. As a result, mistakes are repeated in future projects.
Ignoring issues considering them to be not/less important
One of the most common mistakes I have seen is to ignore issues as not important that crop up during tests in the development process. One classic example is that of the Mars pathfinder
Avoiding these common mistakes and going a step ahead with the implementation of these processes can have long term benefits. No matter what project you do, be it a commercial one, for a client or for submission in your college, avoid these mistakes and start using proper processes for development. You have the added benefit of being able to justify your time taken.
Vivek is a Senior Embedded Innovation Specialist. He has been working on Embedded Systems for the past 10 years. He loves to share his knowledge and train those who are interested. Nerdyelectronics.com was started out of this interest.
