Software engineering is a term that has been heard more than Firmware engineering and they often are considered both as Software. The day that the most of the people involved in information technology and electronic environments will use these two terms separately will probably be the day in which we will have a significant improve-ment in the related products. Why should these two definitions be kept firmly sepa-rated? Well, in the previous paragraph the description of these two elements should be enough to understand that they are quite different things even if it is right to say that it is always a matter of writing program code. If this is not enough to justify the above sentence, the following paragraphs and chapters will show how these differ-ences are significant and how reducing these concepts as only one will result in a severe loss of functionalities and strategy oriented development. There are common elements between these two disciplines, similar techniques of algorithms implemen-tation can be used in both, also some programming languages can be used both for micro-controllers programming and software implementation. For example, the “C”
languages and “GNU C” compilers can be used with the same instructions on PCs and to build firmware applications, of course with differences in the performances, in the context of application and compilers targets. Taking as a reference international
standards, the design process of a program can be covered with the themes listed below, which are the subject of the chapters of the Software engineering body of knowledge (SWEBOK)[16] from IEEE Computer Society (one of the most impor-tant organizations in the world for information technology). Every chapter sums up the legacy of many experts in the field which have worked in the development of the information technology systems that are used today.
1. Software requirements: the process to understand and document the specific characteristics that a program has to satisfy.
2. Software design: the process of modeling and determining the architecture, logics and elements of the program.
3. Software construction: the effective implementation of the algorithms and log-ics that are needed to build the software.
4. Software testing: the process in which use cases are proven to be reliable, ac-cording to defined procedures, and the software “bugs” are removed.
5. Software maintenance: the process that follows the software during its lifecycle and grants the normal operating condition.
6. Software configuration management: the process of handling all the versioning and upgrade or customization of the product.
7. Software engineering management: the management of the various aspect of the design of the program.
8. Software engineering process: the supervision of the whole process.
9. Software engineering models and methods: the instruments which are used to build programs.
10. Software quality: the process that aim to grant a development which is able to satisfy general criteria which usually grant the achievement of a reliable product.
11. Software engineering professional practice, involves many aspects, also ethi-cal, related to the evolution of the software development.
12. Software engineering economics: the process which should follow the com-mercial aspects of the software products.
Knowing what these points are about and understanding the processes they rule is a good way to avoid problems and commit mistakes which have been already encoun-tered and on which someone has put a warning sign. That does not mean that one who does not follow exactly these guidelines will necessarily encounter problems; every-one can have their own strategy but if every-one is not familiar with the concepts of these points, they are more likely to encounter a lot of problems in the development of a useful software [17]. Often the development of a program does not follow all the provided guidelines, sometimes other strategies are preferable, like Agile or Rapid development which are forms of development which need less time, resources and experience in order to produce a complete software product. But generally, the struc-tured approach lead to better result and approaching complex program without it, could result in an unmanageable project. These are consolidated practices which are intended by experts of the discipline and have been followed in the past years due to the benefits that they introduce. Having an ordered approach to the handling of the program complexity, which is quite always a big challenge, can make the difference.
These practices which were affirmed in the software development are often used also in the firmware, but their application has often generated some misguidances.
“There exist various general strategies to help guide the design process. In con-trast with general strategies, methods are more specific in that they generally provide a set of notations to be used with the method, a description of the process to be used when following the method, and a set of guidelines for using the method. Such meth-ods are useful as a common framework for teams of software engineers.” [16]
As stated by the above sentence, from the IEEE SWEBOK, the general guidelines are useful to define the infrastructure and the guidelines to orient ourselves inside a
project, but what is referred as methods, strongly depends on the specific instruments that are used to develop the project and a general strategy should also consider them in the overall plan. Even if there are some common elements, software engineering has evolved in a discipline which is specific for the development of programs inside high-level OS. This kind of development is almost always driven by object oriented languages and paradigms. It will be discussed in detail in the chapter about the soft-ware development what are the characteristics of these methodologies, and will be explained the differences from the ones used in firmware programming. The devel-opment of a program need a set of instruments that are not only the programming languages and compilers to build the execution code, but there are also Integrated Development Environments (IDEs) which integrate a lot of instruments to support the entire process. The development is often sided by the modeling of the application components and behaviors through appropriate modelling languages, which are a set of symbols, notations and graphs which are studied to express the interested features and characteristics of a program in easily understandable schemes, like a sort of navi-gation maps to the program. Making a comparison with a building, these schemes are like the planimetry of a construction. The unified modeling language (UML) [18] is one of the most used and affirmed in environment which is made for object-oriented paradigms. During the last decades, Software development has created and consoli-dated specific methods and tools in order to handle the complexity of the incredible growth that programs have faced. The complexity of firmware programs was, in past years, more related to the implementation of digital algorithms and models rather than the growth of elements and components, but now they are facing a significant progress and a change in paradigms. Devices have now the possibility to have a sig-nificant computational power to implement complex logics and services, and they are becoming actors inside a network rather than only components. What is missing now, or at least what many feel missing in the firmware development is the consolidation of practices and methods proper for their field of application. There are a lot of inter-esting works that are proposing solutions and innovations, and this work hopefully will do the same. There are some attempts also on using methods that were involved in the software also in the firmware, as the usage of UML modelling also for
lan-guages that are not object-oriented. It can be done in some cases but, for example, using class diagrams to model a program in which the language does not use classes could be confusing. My personal opinion about that is is reflected in the sentence took from the SWEBOK, methods should be specific for the context and take into account the elements and instrument involved, then strategies should be able to give general guidelines for framework and architectures in which they are applied, cover-ing all the needed aspects, from design and construction to testcover-ing, documentcover-ing and maintenance of the code [19], [20], [21], [22].