From Lust to Dust: A Product Life Cycle
1 like2,102 views
The document discusses the product lifecycle in software engineering through an analogy with the human lifecycle, defining roles such as research, engineering, and support to address customer needs over time. It outlines the various stages of a product, from pre-conceptual to decay, and emphasizes the importance of adapting processes at each stage to ensure quality and efficiency. The paper highlights that balancing creativity and engineering is crucial for managing maintenance costs and overall product viability.
![6: Institutionalization Stage
As a product matures the users learn to trust it, and at one point it becomes
institutionalized into common use. The product has achieved, like some grown-ups,
maturity and reliability. During this stage most changes are enhancements that are not
difficult to implement and possibly some adjustments to environmental changes.
7: Decay Stage
The accumulation of changes over long periods of time, or new technological developments, finally take a toll on the design and the product ages rapidly. During the decay
stage, the product is progressively less reliable, it becomes harder and harder to
maintain, it cannot be adjusted to the new technology, and people tend to work around it,
instead of through it. Then, one day, someone pulls the plug and the product is gone,
possibly replaced by a newer one, which the demised one has partially supported during
its childhood. A pictorial view of the life cycle is presented in Figure 1.
Development Roles
The figure below depicts the relationship of customer needs to the engineering and
support environment. We prefer the names ‘engineering’ and ‘support’ to the traditional
‘development’ and ‘maintenance’, since we do not think of maintenance as a phase in
the development cycle, or as the environment that is created after delivery, which we call
support (the tiny arrows that show as quick fixes in the figure). Maintenance activities
take place either in the support environment or in a normal project environment.
We define maintenance here as the application to an existing product of any one of the
following four processes: “additions”, “fixes”, “adjustments”, or “migrations”. Additions are
extensions to the product. Fixes are changes done to the product to eliminate its defects.
Adjustments are changes done to the product to accommodate external changes (e.g.,
the basic tenets in the underlying discipline have changed.) Migrations are induced by
changes in the underlying technology platform. As a general rule, only fixes are done
during support, while for additions, adjustments, large clusters of fixes, and migrations,
new projects are created and they operate in the engineering mode. These activities are
therefore part of the normal development cycle for a subsequent version of a product
that has already been created. During the life cycle, the people that work with the
product operate in different “roles” to achieve their goals. We will use a model that
describes three different roles [Trab90].](https://image.slidesharecdn.com/01aproductlifecycle-140103132746-phpapp02/85/From-Lust-to-Dust-A-Product-Life-Cycle-3-320.jpg)
![Figure 1: Product Life Cycle vs. Project Life Cycle
Role 1: Research and Exploration
Ideas that end up in a product are often initially created by a group that is guided by
spontaneity and inspiration [Olso93]. This group works best following an evolutionary
model, that is, building bits and pieces and tying them together into a less than
completely coherent work product, often called a “proof of concept.” The emphasis of
such a group lies in innovation. Exploration (of new technologies and ways to apply it)
and redoing are encouraged. Control is lax, although these groups usually work under a
fixed budget. Whatever they turn out is usually well received. The goals are set in long
term visions. The costs incurred in research are sunken costs to the company, that is,
they are incurred without immediate accountability.
Role 2: Engineering
The economic viability of a software product lies in its quality and in its development
costs. If quality is low, the product is not viable (see role 3 for an explanation.) If the
development costs are too high, there might not be enough market to compensate these
costs. When people work in this role they should be less concerned about innovation
and more about quality. This role is best managed through a well defined process
model, in which a requirements-gathering phase precedes the design phase, that in turn
precedes the implementation phase. (Although this so-called “waterfall model” is strictly
sequential, it is seldom the case that the developers “run” the activities in such clear-cut
order. They usually go back and forth from requirements to design. They might even
move forward to implement a little, then back to gathering requirements. However, the
nature of each activity and where each belongs in a documentation scheme should be
kept clear at all times.) Exploration is discouraged and rework is considered a necessary
evil. Control is strict, and budgetary constraints are strongly tied to project management.
Goals are now midterm, counted in the order of months, not years. The costs of activities
performed in this role are fixed, but not sunken. A product is expected as an outcome,
and the costs of the product are indirectly (as we shall see when we look at Role 3)
dependent on the expenses of the phase.](https://image.slidesharecdn.com/01aproductlifecycle-140103132746-phpapp02/85/From-Lust-to-Dust-A-Product-Life-Cycle-4-320.jpg)
From Lust to Dust: A Product Life Cycle
- 1. From Lust to Dust: A Product’s Life Cycle And the Roles that Make it All Worth It Jorge Boria, M Eng SEI Authorized Lead Appraisers, Liveware Inc. jorge.boria@liveware.com Abstract: Traditional software engineering deals with two phases of a product lifecycle: Development and Maintenance. In this short paper we propose to take a different approach and look at the product’s lifecycle using an analogy with the human lifecycle. We use this analogy to define roles that we call ‘research’, ‘engineering’, and ‘support’ to accommodate all the required activities that will keep a product useful for the longest period possible, while at the same time giving rapid response to customer needs.. Introduction In his novel cum essay “Zen and the Art of Motorcycle Maintenance: An Inquiry into Values” Robert Pirsig defines quality not as an attribute but as a relation between the object in which quality is perceived and the person that perceives that quality. His point is that quality is elusive even if so simple, because it is so personal. Perhaps we could paraphrase the lyrics of ‘Happiness Is’ and say Quality is different things to different people! Even if they are discussing the same object they might have a completely different sense of its quality. In an in-depth tutorial on agile processes held during SEPG 2001 in New Orleans, Brian Nejmeh pointed out that our “one-size-fits-all” approach to strategy and processes does not meet the needs of organizations. His thesis, based on “Crossing the Chasm” is that at every stage of a product’s life different processes are required. For example, at Stage 1 innovation and speed are key elements to capture the innovators’ minds, therefore “quality” in this stage is measured in the bells and whistles; but moving on to the next stage entails a different approach, where quality switches from being measured in the number and diversity of features to reliability and availability of the product. Further down the lifecycle, support and maintenance activities are the paramount of quality. As the product ages, the needs of the customer change too. Hence, if we can see how a product ages throughout its life cycle and tie it to the emphasis on one or another type of engineering, we will be better off in dealing with the product’s (and hence, the customer’s) needs. The product life cycle If we break down the life cycle of a product from before its creation to the moment it is no longer supported, drawing from our own (human) life cycle as an analogy, we have the following stages:
- 2. 1: Pre-conceptual Stage Before a product is even conceived, a number of influences are already in place to support its launch into this world. We can distinguish amongst them environmental conditions, external to the organization that will use the product, including technological assets and market needs; internal conditions including training needs and cultural drives that make the product concept acceptable, personal skills of individuals, managers and line personnel, together with inclination to use the new system and a desire to achieve better results through technology. All these forces start acting together until some formal documents are assembled to start a project with the purpose of delivering a product. This is the pre-conceptual stage of a product. The moment the formal documents that define the product as a concept are created we call the conception moment. 2: Engineering Stage Once the product is envisioned, many roads are possibly explored, both inside and outside the organization, to help with its conception. In an ideal world, there should be a defined instant in which a project is created (budgeted and staffed) to engineer the product. We will call the time used in the execution of this project the engineering stage. A well-defined engineering stage has a well-defined process to describe it. Engineering is to a product like pre-natal stages are to a person: Everyone expects the newcomer, no one is sure what it will look like, many expectations surround it, and it almost sure that it is going to keep us sleepless for many weeks after it arrives! 3: Birth The engineering stage ends in deployment, also called “cut over”. This is not a stage, but an event. It is the “birth” of the product. 4: Deployment Stage Once a product is deployed, it usually suffers from many problems due to the dissonance between what was required and what was produced. This stage, of tentative use, is very much like early childhood: the product does not stand on its own, it babbles when it wants to speak, and, in general, has to be cleaned every few hours. Think of this as the Beta phase of the software product, usually extended well into the user’s first attempts to apply the product in a working environment. 5: Early Adoption Stage If the product survives its childhood, the next stage is not nice, but definitely better: it enters its inception stage, in which many things are overlooked with the expectancy that they will be solved in the future. A product is usually in this stage during its first two versions, which constantly act up, destroy your expectations, and need urgent corrective measures. Inception is a lot like adolescence.
- 3. 6: Institutionalization Stage As a product matures the users learn to trust it, and at one point it becomes institutionalized into common use. The product has achieved, like some grown-ups, maturity and reliability. During this stage most changes are enhancements that are not difficult to implement and possibly some adjustments to environmental changes. 7: Decay Stage The accumulation of changes over long periods of time, or new technological developments, finally take a toll on the design and the product ages rapidly. During the decay stage, the product is progressively less reliable, it becomes harder and harder to maintain, it cannot be adjusted to the new technology, and people tend to work around it, instead of through it. Then, one day, someone pulls the plug and the product is gone, possibly replaced by a newer one, which the demised one has partially supported during its childhood. A pictorial view of the life cycle is presented in Figure 1. Development Roles The figure below depicts the relationship of customer needs to the engineering and support environment. We prefer the names ‘engineering’ and ‘support’ to the traditional ‘development’ and ‘maintenance’, since we do not think of maintenance as a phase in the development cycle, or as the environment that is created after delivery, which we call support (the tiny arrows that show as quick fixes in the figure). Maintenance activities take place either in the support environment or in a normal project environment. We define maintenance here as the application to an existing product of any one of the following four processes: “additions”, “fixes”, “adjustments”, or “migrations”. Additions are extensions to the product. Fixes are changes done to the product to eliminate its defects. Adjustments are changes done to the product to accommodate external changes (e.g., the basic tenets in the underlying discipline have changed.) Migrations are induced by changes in the underlying technology platform. As a general rule, only fixes are done during support, while for additions, adjustments, large clusters of fixes, and migrations, new projects are created and they operate in the engineering mode. These activities are therefore part of the normal development cycle for a subsequent version of a product that has already been created. During the life cycle, the people that work with the product operate in different “roles” to achieve their goals. We will use a model that describes three different roles [Trab90].
- 4. Figure 1: Product Life Cycle vs. Project Life Cycle Role 1: Research and Exploration Ideas that end up in a product are often initially created by a group that is guided by spontaneity and inspiration [Olso93]. This group works best following an evolutionary model, that is, building bits and pieces and tying them together into a less than completely coherent work product, often called a “proof of concept.” The emphasis of such a group lies in innovation. Exploration (of new technologies and ways to apply it) and redoing are encouraged. Control is lax, although these groups usually work under a fixed budget. Whatever they turn out is usually well received. The goals are set in long term visions. The costs incurred in research are sunken costs to the company, that is, they are incurred without immediate accountability. Role 2: Engineering The economic viability of a software product lies in its quality and in its development costs. If quality is low, the product is not viable (see role 3 for an explanation.) If the development costs are too high, there might not be enough market to compensate these costs. When people work in this role they should be less concerned about innovation and more about quality. This role is best managed through a well defined process model, in which a requirements-gathering phase precedes the design phase, that in turn precedes the implementation phase. (Although this so-called “waterfall model” is strictly sequential, it is seldom the case that the developers “run” the activities in such clear-cut order. They usually go back and forth from requirements to design. They might even move forward to implement a little, then back to gathering requirements. However, the nature of each activity and where each belongs in a documentation scheme should be kept clear at all times.) Exploration is discouraged and rework is considered a necessary evil. Control is strict, and budgetary constraints are strongly tied to project management. Goals are now midterm, counted in the order of months, not years. The costs of activities performed in this role are fixed, but not sunken. A product is expected as an outcome, and the costs of the product are indirectly (as we shall see when we look at Role 3) dependent on the expenses of the phase.
- 5. Role 3: Quick Fixes Under this role, only urgent patches are tackled. Larger fixes and enhancements are then rewoven into the fabric of the product through newer versions developed in an iteration of role 2 (version n, n>1.0). In role 3, the process changes to “fix and ship,” the emphasis at this time residing in immediate response. Exploration and redoing are now punished, because otherwise control is even less attainable. The lack of control tied to this role is linked to the fact that the costs for the role are a function of the quality of the product. Products with poor quality are harder to maintain and enhance, incrementing the costs of repair. This is truly bad, since now these costs are variable costs, a function of both the number of problems found during operation and the number of corresponding calls received. CHARACTERISTIC Guiding Force Personnel Characteristics Ruling Principles Control Costs Working Paradigm Outcome RESEARCH AND EXPLORATION Spontaneity and Inspiration Creative (a solution in search of a problem) Individual exploration Lax Sunken Evolutionary Set of Inspirational Ideas ROLE ENGINEERING Quality and Personal Pride Problem Solver (applied creativity) Discipline Strict Fixed Sequential or Spiral Product Version IMPLEMENTATION AND SUPPORT Customer Satisfaction Problem Patcher (on-thefly fixes) Reaction Time Very Lax Variable Patch’n’go Customer Payments Table 1: Different Characteristics in the Roles of Operation This means that you have to set up a “project” approach for the engineering role, and that what you have not included in the project you cannot do later, unless you start a follow-up project (no quick fixes will help you.) This idea of follow-up projects to modify the product so as to comply with a set of requested changes and enhancements is central to a good maintenance structure. It is a big part of the solution, but not all of it. It is called ‘versioning’ and it allows for very good management practices for updates and fixes to the product. A simplified model of versioning can be stated as managing requests for changes by classifying them into two categories: ‘Done Immediately’ (by the ‘support’ role) and ‘Will be part of the next version release’ (and you start a follow-up project to do it, or incorporate the requirement to an existing project.) Conclusions Summing up, if you don’t have creativity (research), your product runs serious risk of not having a market, but if you don’t have engineering, the risk is that the cost of dealing with requests for changes from customers is going to be larger than your benefits. There is very little you can do to remedy poor quality when you are working in role 3. If you
- 6. want to control maintenance and support costs, since they are the only variable costs in all three modes, you must focus on the engineering role: Focus on quality increments the fixed costs of that role, but lowers the variable costs of the support role. Counter intuitively for some, focusing on quality will also help raise productivity, because it eliminates costly rework.