Software factory Introduction

Abstract: This section briefly describes the motivation for Microsoft to develop software factories. A software factory is used to support a specific application. Program And configure the development environment. The software factory is logically the next development phase of software development methods and practices. However, by introducing the industrialization model, the software factory is bound to change the current situation of the software industry. Expand the scale of Software Development

From the current situation, software development is slow, costly, and prone to errors, and many defective products are often produced, it causes serious problems in terms of availability, reliability, performance, security, and other service quality.

According to Standish Group [sta94], U.S. companies invest about 175,000 software development projects each year, with an investment of about $250 billion. Only 16% of these projects can be completed as planned within the budget. Another 31% of projects were canceled mainly due to quality problems, with an economic loss of about $81 billion. In addition, an average of 53% of projects exceeds the budget of 189%, and the economic loss is about $59 billion. On average, only 42% of the originally planned functions are implemented.

These figures objectively confirm our judgment based on experience that software development is a labor-intensive industry, the human capital it consumes to create every dollar of value exceeds our expectations for a modern industry.

Of course, in addition to these shortcomings, the results of software development clearly bring great value to consumers, as shown in the long-term trend of demand growth. But this does not mean that consumers are already very satisfied, whether it is the software we provide or the way we provide software. This only shows that they are optimistic about the prospects of the software and are willing to take on huge risks and losses, so as to obtain the benefits of the software. However, as software development outsourcing is increasingly popular, this is clearly not the best, as it does not seem to drive significant changes in software development methods and practices.

Over the past decade, productivity has only been limited, and the most important reason may be the adoption of byte encoding languages, patterns, and flexible methods. Apart from these advances, our software development methods are no different from those we did a decade ago. Our methods and practices have not actually changed much, and the corresponding costs and risks have not changed much.

However, this situation will be changed. It is predicted that the overall global demand for software will grow by an order of magnitude in the next decade, driven by the emerging forces in the global economy (such as the rise of China, and new application types (such as commercial integration and medical information science) and new platform technologies (such as Web Services, mobile devices, and smart products) the role of software in social infrastructure is growing.

If the software development capability does not grow correspondingly, the overall software development capability will inevitably fall below the overall demand in ten years. Of course, this will not happen if the market forces are able to operate freely, because inspired software providers will provide enough software to meet this demand for personal benefit.

Back to the top of the page to face new challenges

So how can we provide enough software development capabilities? Without too much analysis, we can see that the methods and practices of software development must be significantly changed.

Because the production capacity of the industry depends on the number of qualified developers and the efficiency of developers, the method to improve the production capacity of the industry is, you can also continue to use existing methods and practices to invest more developers, or maintain a considerable number of developers to adopt different methods and practices.

Although the apprenticeship developed over the past decade seems to have successfully increased the number of qualified developers and increased the average level of developers, however, there are at least two reasons to explain that apprenticeship is unlikely to make the production capacity of the software industry meet the expected demand level:

• Experience tells us that nothing is more important than having some outstanding programmers. Outstanding developers are one thousand times more efficient than poor developers, but the number of poor developers is almost one thousand times that of outstanding developers [boe81].

• Brooks [bro95] pointed out that increasing the number of projects will eventually lead to a reduction in marginal revenue. Production capacity will gradually decrease by recruiting and training new developers.

Therefore, the way out should be to change our methods and practices. We must improve the efficiency of developers in various ways.

Back to Top innovation curve and model transformation

As an industry, we have to face this situation from the very beginning. The history of software development is a process of struggling with complexity and changes, sometimes making profits and losing money. With the progress of the times, more needs are generated. Although we have achieved many brilliant achievements in just half a century, the road is not smooth. On the contrary, software development has been moving forward along the famous innovative curve model, as shown in 1 [chr97].

Figure 1 : Innovation Curve

A typical scenario is that a continuous innovation lays the foundation for a new technological age. The Development on the new foundation is fast at the beginning, but with the solid and mature Foundation, the development speed gradually slows down. Finally, this foundation has lost its ability to continue innovation and has reached its peak. At the same time, another Discontinuous innovation laid the foundation for the arrival of another new technology era, so the above models were repeated. Kuhn referred to the above as the basis for the transformation between them to the mode transformation [kuh70]. The pattern change occurs at the moment when the status quo needs to be changed to continue. We are now at such an intersection moment.

Back to Top to improve Abstraction

In history, the transformation of models has successfully improved the abstract level of developers, providing a powerful concept for gaining knowledge in platforms and languages and reusing knowledge. For example, in terms of platforms, we have experienced integration of terminals/hosts, clients/servers, personal computing, multi-layer systems, and enterprise applications since batch processing, to asynchronous and loosely coupled services. In terms of language, we have gone through the assembly language, structured language, object-oriented language, and byte encoding language and mode since the digital encoding language, this can be seen as a language-based abstraction. Smith and Stotts made a meaningful summary of this progress [ss02]:

The history of programming is an exercise in architectural abstraction. In each era, Language designers create structures by summing up the lessons learned from the previous generation, and then architecture designers use these structures to create more complex and powerful abstractions.

They also pointed out that new abstractions are generally first stored on the platform and then transplanted to the language. Our current situation is that language-based abstraction is far behind platform-based abstraction. In other words, tools are far behind platforms. We are currently using the latest platform technologies (for example, by using music to write services, we can now automate processes among multiple enterprises located anywhere on this planet ), but we are still writing every application manually, as if this is the preferred method. We start with a small concept (such as loop, string, and integer) to create a large abstract concept (such as insurance claims and securities trading ). We work diligently and meticulously, and will be related to millions of smallSource codeFragments and resources are combined to form a huge and complex structure. If the semiconductor industry adopts similar practices, they need to use hand-welded transistors to build a huge and complex processor that supports these applications. Instead, they use the tool shown in 2 to complete the implementation by assembling a predefined component called an ASIC.

Figure 2: ASIC-based design tool 7

Can't we automate software development in a similar way? Of course we can, and we are actually doing this. For example, the database management system automates data access through SQL and provides advantages such as data integration and independence, making data-driven applications easier to create and maintain. Similarly, the widget framework and WYSIWYG editor make it easier to create and maintain graphical user interfaces and provide advantages such as device independence and visual assembly. By carefully analyzing these practices, we can find a recurring pattern.

• After a large number of systems have been developed for a given problem domain, we define a set of reusable abstractions for the domain, and then we develop a set of patterns that define how to use these abstractions.

• Then, we develop a runtime (such as a framework or server) to extract the abstract and pattern.Code. In this way, we can create a system in this field by instantiating, adjusting, configuring, and assembling the components defined during runtime.

• Then we define a language and create tools (such as editors, compilers, and debuggers) that support the language to automate the assembly process. This helps us to quickly respond to changing requirements, because some implementations have been completed and can be easily modified.

This is the famous "language framework" model described by Robert and Johnson [96. A framework can reduce the cost of developing an application by an order of magnitude, but it is very difficult to use only one framework. A Framework defines a product with a typical architecture (such as an application or subsystem) that can be refined and specialized in various ways to meet different requirements. Ing the requirements of each product to the framework is by no means a small problem and usually requires the expertise of architecture designers or senior developers. Capture various requirements by using language expressions, and then generate the framework to complete the code. The language-based tool can automatically complete this process.

Back to Top to realize the industrialization of Software Development

In other industries, the way to improve production capacity is from manual operation to mechanical production. In the manual operation stage, all products are manufactured by individuals or groups from scratch, while in the mechanical production stage, various products are quickly produced by assembling reusable components produced by multiple suppliers. In this process, many trivial mechanical tasks are automatically completed by machines. These industries standardize the process, design, and packaging, use product lines to achieve systematic reuse, and share costs and risks through the supply chain. Currently, some industries can achieve large-scale customization and quickly and economically create various products as needed to meet specific requirements of different customers.

Can the software be industrialized?

People had a heated discussion on the analogy between software and physical objects. Can these industrialization models be applied to the software industry? Isn't the software industry more special than other industries because of its different product nature? Peter Wegner summarized the similarities and differences between them as follows [weg78]:

Software products have similarities in some aspects with tangible products (such as bridges, buildings and computers) in traditional engineering disciplines. However, there are also some important differences that make software development different. Because software is a logical concept rather than a physical object, the cost is concentrated in the development process rather than the production process. Because the software does not wear out, its reliability depends on the logical quality (such as correctness and robustness) rather than the physical quality (such as hardness and toughness ).

Some discussions compare physical production and software development to "Apple and orange ". The key to clarifying these troubles is to understand the differences between production and development, and the differences between economies of scale and economies of scope.

In order to get a return on investment, we must make full use of reusable components, not just to reduce development costs, whether directly by reducing costs, or indirectly by reducing risks, shortening the time to enter the market or improving the quality. From an investment perspective, reusable components are financial assets. Because the cost of reusable components is usually very high, and it is difficult to achieve profitable reuse, a systematic method is required to achieve reuse. This usually involves identifying a field for developing multiple systems, identifying the recurring problems in the field, and developing a set of integrated production assets to solve the problem, then, these assets are applied to the process of developing systems in this field.

Back to Top economies of scale and economies of scope

Systematic reuse can simultaneously produce economies of scale and economies of scope. These two effects are widely known in other industries. Although both products reduce time, reduce costs, and improve product quality by producing multiple products in a centralized manner, they have different ways to produce these advantages.

When multiple identical instances are centrally instead of independently produced, economies of scale are generated, as shown in figure 3. Economies of scale may occur in the production of machine screws and other products, in this production process, you can use machine tools and other production assets to produce multiple identical product instances. Engineers use a resource-intensive process (called development) to complete the design and initial instance (called prototype ). It then creates more instances (replicas) through another process completed by machines and/or low-cost labor to meet market needs.

Figure 3 Economies of Scale

Economies of scope are achieved through centralized rather than independently producing multiple similar but different designs and prototypes, as shown in figure 4. For example, in the automobile manufacturing industry, multiple similar but different automobile designs are usually developed through the existing design of combination child parts (such as chassis, car body, internal decoration and transmission device, different styles or models are usually produced by changing some features in the existing design (such as the engine and decorative level. In other words, you can use the same method, process, tool, and material to design multiple similar but different products and create similar but different prototypes. Similar to commercial buildings, it is rare to see multiple bridges or multiple skyscrapers adopt the same design. However, there is an interesting phenomenon in the field of commercial construction, that is, every successful design usually produces only one or two instances, so economies of scale have almost never really been realized. In the automobile manufacturing industry, many different instances are usually generated from successful design. By copying each prototype, economies of scope and economies of scale complement each other, as shown in figure 4.

Figure 4: economies of scope

Of course, there are important differences between software and automobile manufacturing and commercial buildings, but they are often similar.

• In markets such as user Desktop products, products such as operating systems and work efficiency applications are replicated to form mass production. The software industry presents economies of scale, just as in the automobile manufacturing industry.

• However, in markets such as enterprise user products, commercial applications developed to gain a competitive advantage are rarely able to produce in batch, and the software only shows a range of economic features, just like in commercial construction.

Now we can clearly see the difference between Apple and orange. It is naive to compare production and software development in the physical industry. Whether it is software or physical objects, it is meaningless to seek economies of scale in any type of development. However, we can expect that the industrialization of software development will bring about a range of economic results.

What are the results of industrialization?

If we can implement industrialization in the software industry, what will the result look like? Of course, we cannot know exactly before something happens. However, we can make reasonable speculation based on the development path of the software industry and the industrialization of other industries. Obviously, software development will never be as simple as the pure mechanization people wish. On the contrary, the key to meeting global needs is not to waste the time of outstanding developers on mechanical trivial tasks. We must make every effort to make better use of these rare resources, don't let them spend their time manually constructing the changes in industry demands due to the emergence of the next major platform version or changes in market conditions, which may lead to maintenance or replacement in just a few months or years..

One way to achieve this is to provide developers with various ways to turn their knowledge into assets that can be reused by others. Is this goal far from the future? Some models have demonstrated the effectiveness of reuse of knowledge, although the utilization is not high. The next step is to use languages, frameworks, and tools to automatically generate modeled applications, so as to achieve overflight from programming to automation.

Semiconductor Development provides rehearsals for software development after industrialization. This does not mean that software components will soon be as easy to assemble as ASIC. ASIC is a product developed after 20 years of innovation and standardization in the field of encapsulation and interface technology. On the other hand, software development may not take 20 years. The advantage of software development is that it only needs to process bits, while the semiconductor industry also needs to bear the extra burden of physical material engineering required for component implementation. At the same time, the inherent short-lived nature of BITs has also brought challenges such as digital intellectual property protection, as we have seen in the film and music industries.

Back to Top conclusion

This article describes the inability of the software industry to use existing methods and practices to meet the expected needs. Here we only briefly describe many issues, which will undoubtedly lead readers to seek evidence or discuss them in more detail. For more details, see the software factories: Applying ing applications with patterns, models, frameworks and tools book by greenjack field and Keith short, published by John Wiley and Sons. For more information, visit the http://msdn.microsoft.com/architecture/overview/softwarefactories and http://www.softwarefactories.com/, where variousArticleDescribes the long-term problems that prevent the transition from manual operations to mechanical production, major innovations that help the industry overcome these problems, and software factory methods that integrate major innovations.

Copyright Notice

Copyright: 2004 Jack Greenfield. Part of copyright: 2003 Jack greenfield and Keith short, which have been reactivated from Wiley Publishing Inc. All rights reserved.

References

2. [Boe81] B Boehm. Software Engineering economics. Prentice Hall PTR, 1981

4. [Bro95] f Brooks. The Mythical Man-Month.Addison-Wesley, 1995

6. [Chr97] C Christensen. The Innovator's dilemma, Harvard Business School Press, 1997

8. [Kuh70] T Kuhn. The structure of scientific revolutions. The University of Chicago Press, 1970

10. [96] D Robert TS and R. Johnson. Evolving frameworks: A pattern language for developing object-oriented frameworks. Proceedings of pattern classes ages of programs, Allerton Park, Illinois, September 1996

12. [Ss02] J. Smith and D Stotts. Elemental design patterns-a link between architecture and object semantics. Proceedings of oopsla 2002

14. This figure is generated using the movie Oso chip editor and movie Oso XL layout editor and is licensed by Cadence design Systems, Inc. Copyright: 2003 Cadence Design Systems, Inc .. All rights reserved. Cadence and kerberoso are registered trademarks of cadence Design Systems, Inc.

16. [Sta94] The Standish Group. The chaos report. http://www.standishgroup.com/sample_research/PDFpages/chaos1994.pdf

18. [weg78] P Wegner. research directions in software technology. Proceedings of the 3rd International Conference on software engineering. 1978