Risk areas in Embedded Systems Development: Development Process

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 pathfinderAvoiding 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.