Software Engineering concerns when building embedded systems should outweigh almost all other issues for most SoC and MCU based projects.  The reason for this is simple.  Typically, the software is 80% of the work and hardware is 20% of the work for the core computer system.  With these economics, by making sure the software issues are solved correctly, the overall project costs can be contained most easily.

Software engineering costs are well known and have been tracked for tens of thousands of projects over thirty years.  The net result from this tracking is that from a statistical point of view, we know exactly what saves the most money and time and reduces the risk the most for embedded software projects.   The top factors for reducing time, cost and risk are: 

1. Software Reuse
   1. Plug in component, configure and use
   2. Port Component
2. Application Familiarity
3. Requirements Flexibility
4. Architecture Risk
5. Team Cohesion
6. CMM Level

There are many additional cost factors which also have a significant affect on the project cost.  One other very important factor is real-time constraints.  If the real-time nature of the project is driving the system close to the limits of the processor, then the costs will escalate. 

In order to contain cost, time and risk, first and foremost, it is best to reuse software components, either in whole or in part.  Buying a component and configuring it is almost always substantially cheaper than building it.  Porting existing software components and reworking code to meet your needs is typically 5%-10% of the cost of working from scratch.  These approaches create true savings.

The second factor to be considered is to look at making the requierments flexible.  Often, if the team is highly cohesive, it is best to take this approach because some features may turn out to be very difficult and by using a flexible approach, it is often possible to dramatically shorten the time, cost and risk.  This approach is often taken by OEM developers.

Another risk reduction approach is prototyping.  This is a good approach because it develops application familiarity and allows any issues associated with architectural risk to be eliminated.   The danger here is that eventually the prototype will become the product, in which case the product is largely hacked together.   This will cause high maintenance costs and poor reliability.  

Another approach used is some form of rapid development using small teams of two programmers.  This is called extreme programming by some.  This is different from prototyping, because from the outset it is known that the end result will be the product.  Given this mindset during the development, care and attention can be paid to abstract data types and system evolution which reduce maintenance costs.

Software engineering is critical in OEM developer's thinking as they develop new products and in particular, software reuse is key.