This article proposes a process for managing risks associated in managing the distributed software projects.

This paper identifies risk patterns that reoccurred over the years as the author conducted risk assessments. These patterns lead to fifteen actions that practitioners should perform during the course of their projects to ward off the evil effects of current and future risks that seem to plague large software developments.

Effective operational test and evaluation (OT&E) is an essential part of successful systems and software engineering. But increased program dependencies, network-centric operations, and growing interoperability requirements have greatly complicated test and evaluation. This article examines the policy, process, and practice of the Air Force (AF) test and evaluation programs, such as Force Development Evaluations (FDEs), particularly during the sustainment of systems. Several observations are made regarding the current process and five areas are emphasized for improvement.

This article describes the use of a set of modeling and analysis techniques in an interoperability risk probe that found gaps in the ability of a North Atlantic Treaty Organization (NATO) modernization program to react to changing demands. The modeling and analysis techniques were used to create models of the people, processes, and technologies of the program and to represent the way demands were placed on this complex socio-technical system. Analysis of the models revealed interoperability risks that were manifested in the linkages between operational requirements of functional capabilities and the way in which those capabilities were being maintained. The risks identified in this probe were typed as mission, composition, and performance risks. The structural models produced by the techniques bring a welcome engineering rigor to the process of examining interoperability.

A solid risk management process can help to make a project run smoothly. By identifying and addressing a list of project risks as part of a larger project management system, many surprises and roadblocks can be eliminated. Learn more about the definition of a risk as well as the steps that should be a part of your business's risk management process and how you can incorporate such a process into all projects going forward.

After a security assessment has been performed as part of the web application development lifecycle, it is important to understand how to address and fix any application vulnerabilities that are uncovered. Learn more about the steps that should be taken during the remediation process, from categorization to testing and validation, and find out why collaboration among developers is critical for success.

It is important for a business to understand the fundamentals of running a vulnerability assessment in order to determine how one will be run and what can be expected from the results. A web application security scanner can automate the process, but a quality assessment may still require actual human eyes to catch specific issues. Learn more about the whys and hows of vulnerability assessments.

The U.S. Air Force's Software Technology Support Center offers an updated and condensed version of the "Guidelines for Successful Acquisition and Management of Software-Intensive Systems" (GSAM) on its Web site www.stsc.hill.af.mil/resources/tech_docs. This article is taken from Chapter 5 "Risk Management" of the GSAM (Version 4.0). We are pleased that all editions have been so well received and that many individuals and programs have worked hard to implement the principles contained therein. The latest edition provides a usable desk reference that gives a brief but effective overview of important software acquisition and development topics, provides checklists for rapid self-inspection, and provides pointers to additional information on the topics covered.

Systems of systems (SOS) present some unusual risk management challenges that often are not explicitly addressed, yet can impact the resulting degree of system effectiveness. Potential risks associated with integrating a diverse set of systems and associated hardware/hardware, hardware/software, and software/software often exist; these are made all the more difficult by individual systems at different levels of maturity and potential risks that do not exist at the individual system level. Established risk management processes may be in place for different systems, yet process steps and associated tools and techniques may not be compatible. This article briefly examines some key SOS risk management process issues together with methods for better implementing risk management on such programs.

Software program managers crave a silver bullet in the form of a comprehensive checklist of things to watch so the program does not suffer from bad surprises. Highlighted in this article are some prime examples from almost 15 years' experience acquiring software in Department of Defense programs, from identifying broad areas where software risks tend to hide to describing an eight-step risk management process. While there are no silver bullets to be found, there are a few golden nuggets if you make the focused effort to look!