This article exposes the risks and hidden costs involved in the seemingly innocent decision of which third-party APIs to use to gather and report data, offload critical functionality, and save implementation time. It addresses some typical reasons the decision-making process over third-party use is overlooked, as well as how to make good choices confidently and consistently.
Change control exists to review and approve important modifications, but done wrong, you chance confusion, chaos, failures, and outages. Poorly run change control wastes everyone’s time, but far worse is the missed opportunity to assess and manage risk. Here, Bob Aiello gets you up to speed on the lost art of change control.
With open source components being used in more than 80 percent of commercial software developed today, ALM efforts must be altered to address them. Failing to do so may introduce unnecessary risks. This article outlines the potential risks associated with not managing open source as part of your ALM, and explains how these risks can be easily avoided.
Continuing to manage highly complex IT environments in a reactive mode leaves IT specialists vulnerable, when really they need to understand the actual causes and effects of what’s happening among the many technologies in use across the enterprise. Instead of constantly fighting fires, IT operations teams should aim to prevent the fires from starting.
In a previous column, George Schlitz proposed that process improvements, such as agile, require organizations to change process rules. Now George continues his review of agile in regards to compliance and auditing practices. What he's found is that changes to compliance and auditing rules may appear compatible, but the implementation process usually remains unchanged and conflicts with agile practices.
Implementing change can be a colossal challenge. People tend to prefer what's familiar, safe, and predictable to that which is new, unfamiliar, uncertain, confusing, or potentially risky. But the timing of a change effort can influence how readily people accept the change and adjust to it.
Traceability doesn't prevent errors and an audit trail does little to help me to recover from one. Does this mean they aren't valuable CM tools? On the contrary, audit trails and traceability are two of our most important CM tools for learning how to mitigate risk.
No matter how well we plan and execute software development, defects are generated and can escape to the customers. Failure to quickly resolve software problems leads to negative consequences for our customers and increases internal business costs. A quick deterministic
method to prioritize problems and implement their solution helps to reduce cycle time and costs. Achieving this goal requires several steps. The first is to determine a model that links problem resolution performance to institutional variables and problem characteristics. Statistical Design of
Experiments (DOE) is a tool that provides data requirements for estimating the impacts of these variables on problem resolution. Once data has been gathered, the results of statistical analysis can be input into a mathematical optimization model to guide the organization.
This paper describes such an analysis.
This presentation re-emphasizes that requirements are important. The difference between functional and nonfunctional requirements will be covered. Then, Product Risk Analysis will be described, along with the elements of the analysis and steps toward performing the analysis.
Including a testing/QA component early in a software project necessarily prolongs the schedule, right? Not so, according to Ross Collard. In this, the third of a three-part series, Collard explains how to anticipate risks and to aggressively manage the process to prevent disaster.