Software factory

This article includes a list of general references, but it lacks sufficient corresponding inline citations. Please help to improve this article by introducing more precise citations. (March 2022) (Learn how and when to remove this message)

A software factory is a structured collection of related software assets that aids in producing computer software applications or software components according to specific, externally defined end-user requirements through an assembly process.^[1] A software factory applies manufacturing techniques and principles to software development to mimic the benefits of traditional manufacturing. Software factories are generally involved with outsourced software creation.

In software engineering and enterprise software architecture, a software factory is a software product line that configures extensive tools, processes, and content using a template based on a schema to automate the development and maintenance of variants of an archetypical product by adapting, assembling, and configuring framework-based components.^[2]

Since coding requires a software engineer (or the parallel in traditional manufacturing, a skilled craftsman) it is eliminated from the process at the application layer, and the software is created by assembling predefined components instead of using traditional IDEs. Traditional coding is left only for creating new components or services. As with traditional manufacturing, the engineering is left to creation of the components and the requirements gathering for the system. The end result of manufacturing in a software factory is a composite application.

Software–factory–based application development addresses the problem of traditional application development where applications are developed and delivered without taking advantage of the knowledge gained and the assets produced from developing similar applications. Many approaches, such as training, documentation, and frameworks, are used to address this problem; however, using these approaches to consistently apply the valuable knowledge previously gained during development of multiple applications can be an inefficient and error-prone process.

Software factories address this problem by encoding proven practices for developing a specific style of application within a package of integrated guidance that is easy for project teams to adopt. Developing applications using a suitable software factory can provide many benefits, such as improved productivity, quality and evolution capability.^[1]

Software factories are unique and therefore contain a unique set of assets designed to help build a specific type of application. In general, most software factories contain interrelated assets of the following types:

• Factory Schema: A document that categorizes and summarizes the assets used to build and maintain a system (such as XML documents, models, etc.) in an orderly way, and defines relationships between them.^[2]
• Reference implementation: Provides an example of a realistic, finished product that the software factory helps developers build.
• Architecture guidance and patterns: Help explain application design choices and the motivation for those choices.
• How-to topics: Provide procedures and instructions for completing tasks.
• Recipes: Automate procedures in How-to topics, either entirely or in specific steps. They can help developers complete routine tasks with minimal input.
• Templates: Pre-made application elements with placeholders for arguments. They can be used for creating initial project items.
• Designers: Provide information that developers can use to model applications at a higher level of abstraction.
• Reusable code: Components that implement common functionality or mechanisms. Integration of reusable code in a software factory reduces the requirements for manually written code and encourages reuse across applications.^[1]

Building a product using a software factory involves the following activities:

• Problem analysis: Determines whether the product is in the scope of a software factory. The fit determines whether all or some of the product is built with the software factory.
• Product specification: Defines the product requirements by outlining the differences from the product line requirements using a range of product specification mechanisms.
• Product design: Maps the differences in requirements to differences in product line architecture and development process to produce a customized process.
• Product implementation: A range of mechanisms can be used to develop the implementation depending on the extent of the differences.
• Product deployment: Involves creating or reusing default deployment constraints and configuring the required resources necessary to install the executables being deployed.
• Product testing: Involves creating or reusing test assets (such as test cases, data sets, and scripts) and applying instrumentation and measurement tools.^[2]

Developing applications using a software factory can provide many benefits when compared to conventional software development approaches. These include the following:

• Consistency: Software factories can be used to build multiple instances of a software product line (a set of applications sharing similar features and architecture), making it easier to achieve consistency. This simplifies governance and also lowers training and maintenance costs.
• Quality: Using a software factory makes it easier for developers to learn and implement proven practices. Because of the integration of reusable code, developers are able to spend more time working on features that are unique to each application, reducing the likelihood of design flaws and code defects. Applications developed using a software factory can also be verified before deployment, ensuring that factory-specific best practices were followed during development.
• Productivity: Many application development activities can be streamlined and automated, such as reusing software assets and generating code from abstractions of the application elements and mechanisms.^[1]

These benefits can provide value to several different teams in the following ways:

Business tasks can be simplified which can significantly increase user productivity. This is achieved through using common and consistent user interfaces that reduce the need for end-user training. Easy deployment of new and updated functionality and flexible user interfaces also allows end users to perform tasks in a way that follows the business workflow. Data quality improvements reduce the need for data exchange between application parts through the ALT+TAB and copy and paste techniques.^[3]

Software factories can be used by architects to design applications and systems with improved quality and consistency. This is achieved through the ability to create a partial implementation of a solution that includes only the most critical mechanisms and shared elements. Known as the baseline architecture, this type of implementation can address design and development challenges, expose architectural decisions and mitigate risks early in the development cycle. Software factories also enable the ability to create a consistent and predictable way of developing, packaging, deploying and updating business components to enforce architectural standards independent of business logic.^[3]

Developers can use software factories to increase productivity and incur less ramp-up time. This is achieved through creating a high-quality starting point (baseline) for applications which includes code and patterns. This enables projects to begin with a higher level of maturity than traditionally developed applications. Reusable assets, guidance and examples help address common scenarios and challenges and automation of common tasks allows developers to easily apply guidance in consistent ways. Software factories provide a layer of abstraction that hides application complexity and separates concerns, allowing developers to focus on different areas such as business logic, the user interface (UI) or application services without in-depth knowledge of the infrastructure or baseline services. Abstraction of common developer tasks and increased reusability of infrastructure code can help boost productivity and maintainability.^[3]

Applications built with software factories result in a consolidation of operational efforts. This provides easier deployment of common business elements and modules, resulting in consistent configuration management across a suite of applications. Applications can be centrally managed with pluggable architecture which allows operations teams to control basic services.^[3]

There are several approaches that represent contrasting views on software factory concepts, ranging from tool oriented to process oriented initiatives. The following approaches cover Japanese, European, and North American initiatives.^[4]

Under this approach, software produced in the software factory is primarily used for control systems, nuclear reactors, turbines, etc. The main objectives of this approach are quality matched with productivity, ensuring that the increased costs do not weaken competitiveness. There is also the additional objective of creating an environment in which design, programming, testing, installation and maintenance can be performed in a unified manner.

The key in improving quality and productivity is the reuse of software. Dominant traits of the organizational design include a determined effort to make operating work routine, simple and repetitive and to standardize work processes.

A representative of this approach would be Toshiba's software factory concept, denoting the company's software division and procedures as they were in 1981 and 1987 respectively.

This approach was funded under the Eureka program and called the Eureka Software Factory. Participants in this project are large European companies, computer manufacturers, software houses, research institutes and universities. The aim of this approach is to provide the technology, standards, organizational support and other necessary infrastructures in order for software factories to be constructed and tailored from components marketed by independent suppliers.

The objective of this approach is to produce an architecture and framework for integrated development environments. The generic software factory develops components and production environments that are part of software factories together with standards and guidance for software components.

The experienced-based component factory is developed at the Software Engineering Laboratory at the NASA Goddard Space Flight Center. The goals of this approach are to "understand the software process in a production environment, determine the impact of available technologies and infuse identified/refined methods back into the development process". The approach has been to experiment with new technologies in a production environment, extract and apply experiences and data from experiments and to measure the impact with respect to cost, reliability and quality.

This approach puts a heavy emphasis on continuous improvement through understanding the relationship between certain process characteristics and product qualities. The software factory is used to collect data about strengths and weaknesses to set baselines for improvements and to collect experiences to be reused in new projects.

Defined by the Capability Maturity Model, this approach intended to create a framework to achieve a predictable, reliable, and self-improving software development process that produces software of high quality. The strategy consists of step-wise improvements in software organization, defining which processes are key in development. The software process and the software product quality are predictable because they are kept within measurable limits.

• The first company to adopt this term was Hitachi in 1969 with its Hitachi Software Works. Later, other companies such as System Development Corporation in 1975,^[5]
• NEC, Toshiba and Fujitsu in 1976 and 1977 followed the same organizational approach.^[6][7][4]

Cusumano^[8] suggests that there are six phases for software factories:

• Basic organization and management structure (mid-1960s to early 1970s)
• Technology tailoring and standardization (early 1970s to early 1980s)
• Process mechanization and support (late 1970s)
• Process refinement and extension (early 1980s)
• Integrated and flexible automation (mid-1980s)
• Incremental product / variety improvement (late 1980s)

• Software Product Line
• Software Lifecycle Processes
• Software engineering
• Systems engineering
• Software development process
• Automatic programming
• Domain-Specific Modeling (DSM)
• Model Driven Engineering (MDE)

• Harvard Business Review Wipro Technologies: The Factory Model
• Outsourcing Without Offshoring Is Aim of ‘Software Factory’ By P. J. Connolly