Solve your build-or-buy firmware conundrum (steps 1-3)
Article By : Jacob Beningo
Engineering careers ride on product success. So how might a team go about deciding whether they should build or buy all or some software components?
Every development team needs to make the decision as to whether they will design and build their software from scratch or buy software components. Often, it is not as much a business decision as it is an engineer's ego claiming to do it faster and better than "them."
Even if that boast is true, launching a successful product requires many more considerations to be taken into account in order to be successful, efficient, and to maximize productivity.
So how might a team go about deciding whether they should build or buy all or some software components? Here are six key steps to take before reaching a conclusion.
Step #1 – Identify available resources
The first step is to identify the resources that are currently available to the project team. Taking stock will give the team an understanding of how many engineers are available, the allotted time to complete the project (rarely is there ever enough), the overall project budget, and perhaps even start-up capital. Teams may even consider identifying the tools that are readily available that could affect the development schedule.
Step #2 – Categorize the firmware's components based on complexity
Developing a basic software architecture will provide the development team with a general idea about the device complexity and the major software components that will be required. For example, identifying that a graphical user interface with a touch screen is required would undoubtedly be ranked high on the complexity list due to the need for graphics drivers, communication drivers, image design interfaces, and messaging interfaces. Each component the system requires can be ranked with a value from one to ten, with ten being the most complex software component. Components with high complexity rankings are candidates for purchasing.
Step #3 – Review the teams’ skillset
Once a required component list has been generated and complexity rankings assigned, the available team members’ skills can be evaluated against those components. Each team member can be ranked based on expertise and previous experience developing each component. Ranking skills in this manner allows the team to identify skill gaps as well as leverage past experiences to get an accurate read on development time (see figure 1).
Figure 1: Component complexity and skill ranking.