Software is a Product...Not

Abstract
Much of our planning for software uses the hardware product model. While we're not perfect, we do a fairly good job of managing hardware engineering for required time, quality, and money. But software more often than not is late, doesn't do what we want it to do, and costs too much. And that's a problem. We can't see a solution to our problem-perhaps because we have made the solution invisible by thinking about it in the wrong terms. I propose a vocabulary change. We will better understand the process if we consider software as a service, not a product. Let me expand on this statement. I do not believe we must do any of the software-building activities differently. Instead, from the perspective of scheduling, budgeting, and delivering software, we should use the service paradigm rather than the product paradigm. Scheduling, Budgeting

This publication has 0 references indexed in Scilit: