3
these frameworks. One is that most Agile methods are optimized for software products,
not embedded systems that are comprised of both software and hardware. Also,
embedded systems are produced in order to carry out critical applications where general
purpose computers are not to be trusted to perform the tasks; therefore saving costs is
not the main objective of creating these systems.
In other words, most real-time systems are mainly designed to carry out control
functions with critical applications. The Agile methods give waste elimination the
highest priority, which could make us happy about the efficiency portion, but they fail
to put enough emphasis on the robustness of the product. A good example of this is the
Microsoft products that are developed through Agile methods. Their numerous after-
release software patches and their daily software updates are evident that robustness is
not high on their list. We are not to blame one product over its lack of quality. What we
want to say is that, when there is not enough emphasis on one aspect of product or there
is so much of it on another aspect, people who follow those methods blindly might not
be able to put things in perspective. In addition, since in the span of development time
and also product life cycle the technology and hardware components can change, it is
very important to plan carefully ahead. While an Agile method empowers the project to
deal with short-term changes, it might make it easier for its followers to abandon long-
term plans for the product. The real consequence of this approach is that the importance
of architecture in product development will be devalued. As you can see later, the
product architecture plays a vital role in developing the embedded systems.
A project manager, in any type of project, from construction to hi-tech needs to
put several hats on during the life of the project. In a real-time system development
project, a manager needs to interface with different stakeholders and internal and
external customers at different phases of a project and needs to follow various life cycles
including project, product, and software life cycles. However, a project manager is hardly
a product architect. This is because most project managers are trained and skillful in the
art of management rather than designing a real-time system. This book is intended to
find the common aspects of various life cycles and introduce an inclusive methodology
that would cover them all under one umbrella with an emphasis on the necessary
amount of documentation. We are hoping that by the end by reading this book, if not
anything, at least your outlook will change toward real-time systems development.
Furthermore, this book is for the embedded system project architects who are aware
of steps involving developing a real-time system and not just the project. The detail of
how to become aware of the design steps is through systematic use of a tool called the
Chapter 1 the history ofLayers arChiteCture