Agile methods are described as software development methods. Most introductory material, like the Agile Manifesto, describe how agile teams are organized and act but don’t describe some of the things that happen outside the development teams.

When your teams start using new methods, they will act in a drastically different way from the norm, especially in an organization that has not otherwise changed. There is bound to be some conflict.  When you bump into existing processes or rules that seem to get in the way of your agile teams, you will have an important choice to make: ignore the rule, follow the rule, or try to change it.
Click here to continue reading this article at Sticky Minds.

Unit Test has been around almost as long as software development itself. It just makes sense to take each application building block, build it in isolation, and execute it with test data to make sure that it does just what it should do without any confusing input from the remainder of the application.

In the past, the sting came from not being able to simply lift a software unit from its development environment, compile and run it ” let alone supply it with test data.
For that to happen, you need a harness program acting as a holding mechanism that calls the unit, details any included files, “stubs” written to handle any procedure calls by the unit, and offers any initialization sequences which prepare data structures for the unit under test to act upon.

Click here to continue reading this article at Embedded.com

Due to the increasing importance of solutions using embedded software and the relatively small numbers of skilled and experienced programmers, embedded systems development is being undertaken in a wide cross section of industries by the very same experts.
The availability of target-specific testing and development tools, and the desire to use standard development tools for the majority of the code work are the main reasons for these OS to be sought after.
According to the study “standards conformance and interoperability” and the “ease of porting code to new target platforms” seem to be less important to developers.
This might be because decisions concerning the choice of OS on which to build embedded applications, are more related to the device that will house the application than in other areas of software development.
Embedded system development is still a young area and likely to grow in importance. Click here to read the whole article at The Register.

The first multicore platforms have found their way into embedded systems for entertainment and communication, especially thanks to their greater computational power, flexibility, and energy efficiency. However, as we will show, mapping applications onto these systems remains a challenge that is costly, slow, and prone to errors.
Although the multicore programmable architectures have a huge potential to tackle present and future applications, a key issue is still open: how can developers map an application onto such a multicore platform fast and efficiently, while profiting from the potential benefits of parallel processing?

Click here to continue reading this article at Embedded.com

Can a large organization adopt agile approaches to software development when the organization holds the notion that not all projects should be agile? In other words, can there be a mix of waterfall-type projects and agile projects in the same organization? The short answer is yes, however there is a cost that must be paid for this coexistence.

In transitioning to agile, most companies gradually transition a few teams at a time, learning from their successes and mistakes and applying the new knowledge to the rollout of new agile teams. This process can take months or years, depending on the size of the organization and the stability of management and agile champions.

Click here to continue reading this article at Sticky Minds.

The question “what is embedded?” continues to plague many of us, even those who are deep in the throes of the technology. It’s sometimes easier to make a point using a negative. For example, could you imagine a world without embedded technology.  Probably not. If that were the case, we’d be without computers, vehicles as we know them today, any type of aircraf, cell phones, the Internet…
In fact, most of our industries would not be doing business the way they do it today without embedded technologies. And yet, a vast majority of the general population will have a perplexed look on their face when you ask them “what is embedded?”

Click here to continue reading this article at Embedded.com

Virtualization, a concept of the mainframe computing and business IT world, is no longer a technology restricted to large computing centers and business computing environments. Increasingly confronted with the requirement to communicate with business IT and to integrate complex processing environments, programmers and developers of embedded systems increasingly rely on virtualization techniques.

Click here to continue reading this article at Embedded Europe.

Requirements risks are among the most insidious risks threatening software projects. Whether it is having unclear requirements, lack of customer involvement in requirements development, or defective requirements, these troubles are a major culprit in projects that go awry. Project teams can make a difference by adopting and implementing agile practices. When implemented correctly, agile practices greatly mitigate the most common risks associated with requirements on software development projects.

Click here to continue reading this article at Sticky Minds.

When a software developer is acquiring a compiler, a primary consideration is the code quality produced by the compiler. But other features that are not required by the ANSI language description (that are tailored to embedded developer needs) can make the developer’s task simpler to maintain.

Click here to continue reading this article at  Embedded Computing Desing about some desirable features of compilers used in embedded application development, and some techniques for making use of these features.

The topic of coding standards is an emotive one among software developers, whose divergent opinions raise questions that range from “Why do we need such restrictions?” to “How could we possibly operate without them?”
Software engineering has always wrestled with standards, and the development of the C and C++ languages brought the issue into even sharper focus. These flexible and powerful languages are now deeply rooted in industrial and embedded environments. In the past decade, developers have accepted the need to control and restrict these languages for industrial, commercial, or other safety-conscious purposes.

Click here to continue reading this article at Embedded.com