. "Software-Related Offshoring--Alfred Z. Spector." The Offshoring of Engineering: Facts, Unknowns, and Potential Implications. Washington, DC: The National Academies Press, 2008.
The following HTML text is provided to enhance online
readability. Many aspects of typography translate only awkwardly to HTML.
Please use the page image
as the authoritative form to ensure accuracy.
The Offshoring of Engineering: Facts, Unknowns, and Potential Implications
FIGURE 1 The diversity of software activities.
but as requirements and designs are refined, every step might need to be revisited requiring cycles in development processes.
Interest in modular assembly (e.g., web service-based development or previously object-oriented techniques), with its greatly reduced emphasis on new coding, is increasing. The newest incarnations are “mash ups,” connected groupings of reusable components that provide a new function, often intended for a modest-sized audience. Simplicity of assembly is the focus, and success is based on the existence of a massive, society-wide capital plant of increasingly modular components, such as maps, calendars, group bulletin boards and editors, etc.
Open-source techniques have been remarkably effective for creating good software. To the amazement of some, volunteer groups in modest organizational structures, often using many preexisting software components, are proving adept at developing quality software.
There is no agreed-upon standard methodology for creating software (and there may never be); so software development is not amenable to rigid standardization. Creating software-development organizations is not like designing a semiconductor fab, for which one can create a design that can be cloned in whatever locations have the most favorable cost or regulatory structures. Software development is too variable for that.
Finally, the last cut attempts to capture the important interactions with the world around software including other items that go into the software life cycle. For example, one cannot undertake the automation of a medical procedure without understanding the impacts of failure, FDA requirements for proof of safety and efficacy, and much more. Automation strategies, the creation of business models for supporting software, an understanding of the management of holistic systems in which software will operate, and an increasing focus on risk and compliance management must all be considered part and parcel of the software field.
I suspect that with more time and thought we could fill out and enlarge this multidimensional matrix in each dimension.
We can conclude, however, that software is a very diverse field. Thus, when we consider offshoring, we must remember—and this is my second message—that there is greatvariability in software objectives, job types, and practicesaround the world. Thus, even if a population somewhere