Determining what architecture products are needed to support software development within a larger systems engineering process is a challenge. Existing documents such as the Department of Defense Architecture Framework provide some guidance, but no defined product identification process. The method proposed in this article provides a repeatable process for selecting the architecture products required to support a larger systems engineering effort, defines the content of each product, and identifies each product’s customer.

A successful implementation of a commercial off-the-shelf-intensive software system can save programs money if you have the right solution and understand the potential risks involved.

The developer world is divided into two camps. Language mavens wax rhapsodic about the power of higher-level programming — first-class functions, staged programming, AOP, MOPs, and reflection. Tool mavens are skilled at the use of integrated build and debug tools, integrated documentation, code completion, refactoring, and code comprehension. This article provides interesting thinkings on how tools and languages interract.

Recently we have heard a lot about Linux. Several discussions have been held in the professional circles, and the media is getting the message to the general public. It can be considered the major open source product, and the responsible for this public awareness. However, the concepts behind open source must also be explained, and - beyond this - the existence of open standards and protocols shall be understood. The comparison between "open" and proprietary software should not be limited to the cost, neither be influenced by the impression that open means free. What is the importance of this understanding for multimedia project managers?

A software system exists for one reason: to provide value to its users. All decisions should be made with this in mind. Before specifying a system requirement, before noting a piece of system functionality, before determining the hardware platforms or development processes, ask yourself questions such as: "Does this add real VALUE to the system?" If the answer is "no", don't do it. All other principles support this one.

Some ineffective development practices have been chosen so often, by so many people, with such predictable, bad results that they deserve to be called "classic mistakes."