Software is inherently error-prone and such errors can lead to failure of those systems of which the software is part. On the other hand, with software being only one of many components of a system, there are many choices in regard to attaining a particular level of system resiliency, not all of which are software-related. It is important to consider software resiliency in relation to the resiliency of the entire system, including the human and operational components. The goal of this article is to help those who develop, implement, and operate computer networks and systems in determining the factors to include when investing in software resiliency.

This article emphasizes the significance of knowledge management practices in the context of the software development industry. This also covers how knowledge conversion takes place in organizations, why organizations fail to utilize Knowledge Management in solving the business problems in long-term and how KM can be implemented effectively with best practices.

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?

Zach looks at building software as piling up grains of sand one at a time—and then managing the landslides when the sand piles get too steep.

Over the course of building out a number of large, distributed systems I've had the opportunity to observe (and implement) some worst practices. Most of these worst practices start innocently enough, but if neglected they will jeopardize the growth and scalability of a system. A number of articles focus on best practices to ensure an easily maintainable and scalable system, but in this article I'll highlight some worst practices to avoid.

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 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.

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.

This article discusses the advantages and challenges in application development using service-oriented architecture and cloud computing technologies.

Construct validity is about the question, how we know that we're measuring the attribute that we think we're measuring? This is discussed in formal, theoretical ways in the computing literature (in terms of the representational theory of measurement) but rarely in simpler ways that foster application by practitioners. Construct validity starts with a thorough analysis of the construct, the attribute we are attempting to measure. In the IEEE Standard 1061, direct measures need not be validated. "Direct" measurement of an attribute involves a metric that depends only on the value of the attribute, but few or no software engineering attributes or tasks are so simple that measures of them can be direct. Thus, all metrics should be validated. The paper continues with a framework for evaluating proposed metrics, and applies it to two uses of bug counts. Bug counts capture only a small part of the meaning of the attributes they are being used to measure. Multidimensional analyses of attributes appear promising as a means of capturing the quality of the attribute in question. Analysis fragments run throughout the paper, illustrating the breakdown of an attribute or task of interest into sub-attributes for grouped study.