David is experienced in Embedded Design and Software Implementation. He has been with DISTek since 2012 and loves that he gets paid to develop and test embedded systems which are activities that he is passionate about enough to do in his free time. David's strengths are C, C++, C#, Agile development methods, CAN, and control systems.
Welcome to part two of my blog series on software architecture. The previous blog focused on an overview of software architecture in general. Part three will focus on software architecture that I have found to be beneficial. For now, let’s review four common software architecture pitfalls that I have encountered:
Software Architecture is a key component in developing a long term, successful embedded system device. However, the topic of what is included in software architecture is complex. Let’s take a look at an example of what software architecture is with an excerpt from Luke Hohmann in Beyond Software Architecture: Creating and Sustaining Winning Solutions:
“Software architecture is the sum of the nontrivial modules, processes, and data of the system, their structure and exact relationships to each other, how they can be and are expected to be extended and modified, and on which technologies they depend, from which one can deduce the exact capabilities and flexibilities of the system and from which one can form a plan for the implementation or modification of the system.”
While I was attending the Embedded Systems Conference this year in San Jose, there was one session that peaked my interest. The session was “Design Patterns for Embedded Systems in C” from Bruce Powel Douglass, Ph.D., Chief Evangelist from IBM IoT(Internet of Things).
According to Wikipedia, Agile software development is “a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.” While there can be some variability among Agile organizations, there are a few important definitions which generally hold true. A Potentially Shippable Increment (PSI) is a 2 month period of time in which the team will commit to delivering a set of features to a customer.