Reducing Cycle Time

Abstract

Motorola continues to reduce the amount of time it takes to buildand deliver products. Our goal of 10X reduction in cycle time is attainable and now westrive for even greater reductions. Key to our strategy is reuse but even that is dependent uponnew technologies. This WISR paper is a continuation of the WISR 7 paper and maps Motorola'sprogress in cycle time reduction.

Keywords: reuse, cycle time, tool, environment, process

Workshop Goals: learning, networking, advance the state of theory and practice of reuse, sharing ideas with others

Working Groups: domain analysis/engineering, architectures, tools

1 Background

This is an update on the WISR 7 paper that discussed Motorola's 10X Cycle Time Reduction initiative. It presents a few of the ideas and a lot of the questions that we are addressing namely can today's technology support the improvements that we need? The position of this paper is that they will not and we must pursue other means.

2 Position

2.1 Better Than 10X

As discussed at WISR 7 Motorola has adopted a 10X Cycle Time improvement strategy to stay a vital, thriving company. That is, we want to reduce the amount of time from conception to delivery of our products by a factor of ten. We are confident that we know how to achieve this goal with the technologies that are available today.Institutionalization of case tools and a reuse-based process will enable us to deliver our products ten times faster. The introduction of Product Development Environment (as discussed last WISR) alone will provide at least a 4X improvement.

Anticipating our next goal the software reuse team at the Cellular Infrastructure Group is brainstorming the requirements for 100X improvement. Key to this effort is an environment that uses reusable assets to create new products.

But before we discuss what is and is not needed lets consider afictitious example that illustrates the ramifications of 100X cycle time improvement:

To produce a product in 15 months from the time of conception to delivery, the production schedule could be divided similar to:

requirements gathering: 2 months

design: 3 months

code: 5.5 months

test: 5 months

installation: 0.5 month

To achieve 100X improvement in cycle time the product will have to be developed in 15 divided by 100 months or 4.5 days. We could improve each phase by a factor of 100 giving a schedule of:

requirements gathering: 2 months *30 days/100 improvement = 14 hours

design: 3 months *30 days/100 improvement = 1 day

code: 5.5 months *30 days/100 improvement = 1.7 days

test: 5 months *30 days/100 improvement = 1.5 days

installation: 0.5 month *30 days/100 improvement = 4 hours

Imagine reducing the time to elicit requirements from 2 months to14 hours. How could this possibly be achieved?

Requirements elicitation as we know it today is not only inaccurate, it is much too slow. The customers need a more direct connection to their product. In fact they need a way to order products that is as easy as ordering pizza. And even if the customer could just call in their requirements, how would the requirements be:

* stored,

* verified,

* transferred to the production line,

* interpreted by the production engineers, and

* tested?

OK, so these are the same old problems that we have always had. Nothing new, we just have to do them 100 times faster and we barely get them done now.

2.2 Conventional Technology Is Inadequate

It is much too difficult to do and maintain analyses and designs by hand. Automation is essential. But what type of automation will achieve 100X improvement? Does it even exist?

2.2.1 For The Engineers

We are finding that the technology available today is inadequate to meet our needs today. Despite promises, the available methods do not support commercial size development by production engineers. Our products consist of millions of lines of code. Methods and prototypes that have been proven with 150,000 lines of well structured C code do not scale up well or at all. Current software tools do not support the entire life cycle and individual tools are incompatible, making transfer from tool to tool impossible. They do not scale up to support development of commercial size and complexity either.

Programming languages may become obsolete.; cranking out thousands of lines of code at a CRT is inefficient. We have other sense and there are other ways to communicate - sound, light, taste, and smell. Before I get too far into the future, consider the current work in holographics, motion suits, light and sound sensors. Most commercial applications are in the entertainment field but why can't product development be fun.

2.2.2 For The Customers

Have you ever gone to the cash machine, requested twenty dollars and got a hundred? That might be OK if the extra eighty dollars was free but, like all mistakes, they are not free. The point is that customers need an accurate, easy means to communicate their needs. Touch screens although convenient are not perfect and can be very confusing even to experienced users. Phone menus on the other hand are easy but are quite annoying and slow. So where does that leave technology - lacking.

Research efforts are concentrating on non-tactile interfaces likeholographics and virtual reality systems.

2.3 Where Is Reuse?

The key is to either be able to modify existing structures to meet the customers' specification or expand and instantiate a core element to the customers'specific needs. And this should be invisible to the customer.

The designer's role changes from working with the customers to anticipating the customers' needs. Designers will create the base or core structure from which products will be created.

Implementation and installation as we know it today will be a thing of the past. The time required to implement a product and then install it at the customer site will diminish as assets are created that easily plug and play or replace and adapt.

2.4 What are we doing

First of all we are changing the structure of our organization. We are dividing the work force into four groups: management, domain analysis, product development and asset development. This is similar to the STARS model and will allow our architects to be proactive rather than reactive to the market. To help our current customers we are extending the workwith PDE (WISR 7 paper). For future customers we are working on different techniques of eliciting requirements.

We are also working on techniques and tools for building reusable assets that will help us achieve >10X. This includes designing reusable architectures for current product lines and anticipating future architectures for new product lines. Our current transition strategy is:

* identify domains where the greatest opportunities exist to apply reuse techniques,

* focus on quality and reusability across domain,

* identify the assets to populate domain-specific architectures,

* develop reuse guidelines,

* establish criteria for deciding the ownership of reusable assets,

* integrate reuse into the overall system/software life-cycle,

* modify the current acquisition process to foster reuse,

* develop and apply new business models that incentivize CIG to practice reuse

* define a process to evaluate reuse success,

* pursue technology-based investments that support appropriate reuse-oriented process and product technologies, and

* define and implement a plan to transition technology to a reuse-based paradigm to include a strong education and training activity,

* provide support.

For the 100X we have several tasks forces working on the 10+Xproblem. We are also combining software and hardware technology to make communications for customers faster and easier to use. And, we are calling upon our university affiliates to help us.

3 Comparison

Universities (e.g., Illinois) and some commercial vendors have working holographic prototypes as well as virtual reality systems.

Several companies, e.g., Motorola, HP and Nokia, have announced products connecting voice, electronic, and web communications through pagers and cellularphones.

4 References

[1] Clark, M. "Frontiers in user interface design: wearable computers," Stereoscopic Displays and Virtual Reality Systems III Proceedings, SPIE, volume 2653, April1996.

[2] Greuel, C., Bolas, M. , Bolas, N., McDowall, I. "Sculpting 3D worlds with music: advanced texturing techniques," Stereoscopic Displays and Virtual RealitySystems III Proceedings, SPIE, volume 2653, April 1996.

[3] McDowell, I, Bolas, M."Stereo texture facades,"Stereoscopic Displays and Virtual Reality Systems III Proceedings, SPIE, volume 2653, April 1996.

[4] Zeltzer, D."Validation and verification of a virtual environment for training naval submarine officers," Stereoscopic Displays and Virtual Reality Systems IIIProceedings, SPIE, volume 2653, April 1996.

[5] Smith, J., Grimes, R. "Engineering applications of virtual reality," Stereoscopic Displays and Virtual Reality Systems III Proceedings, SPIE, volume 2653, April 1996.

5 Biography

Rebecca L. Joos is a Principal Staff Engineer/Scientist at the Motorola Cellular Infrastructure Group in Arlington Heights, IL. She continues to research asset development methods and techniques. Becky has been working on software reuse for the last ten years. She has campaigned for reuse in Motorola with training seminars, courses, and pilots. Her current work deals with developing methods for the creation of reusable assets in cellular development groups.

Anthony Kram is a Senior Staff Engineer at Motorola Cellular Infrastructure Group in Arlingtons Heights, IL. He has been creating reusable software for the last 10 years. For the last 2 years he has focused on improving reuse process, methods, techniques and tools. Presently he is doing domain analysis on requirements to develop a reuseable requirements tool.