Introduction

It is worth noting here that IBM Global Services has an offering based on organization that also satisfies much of what is discussed here. The Rapid Application Center will not be covered in this paper. Instead it will discuss the experiences of a specific customer that independently pioneered an organizational structure, and implemented specific tooling to support this effort.

This paper takes its inspiration from this pioneering effort, which proved that the concept of a Software Factory not only can work, but does so at a scale of efficiency far greater than today's current organizations. This original work has been expanded here to include suggested tooling, and additional thoughts on organizational efficiencies.

Throughout this paper there will references to the suite of products offered by the Rational Corporation. There are certainly other tools available that will produce similar results in any specific area. However, Rational offers a suite that covers the entire spectrum of need. As such, where a tool will facilitate a function, Rational's offering will be referenced.

The Software Factory

First, a definition. A 'Software Factory' is a concept, a metaphor if you will, for the virtual organization that supports the development of software for business needs. It is structured and staffed around the 5 logical components of software development: Analysis, Design, Code and Unit Test, Life Cycle Management and (Automated) Integration Test. This organization follows a prescribed development process, such as that detailed in Rational's Unified Process. In many cases, this Process will be customized with specific development cases to meet the needs of individual organizations. We use the term 'development case' here to represent the collection of the workflow documentation and associated guides.

Today, many businesses are moving toward component based software. The benefits of this are described in a variety of papers and documents, and need not be specified here. It is clear that this is the direction of the future, and companies are scrambling to be able to effectively engage in this form of software development. However, it is fair to say that many companies are struggling as to HOW to be effective in this arena.

Component based software development requires new ways of managing the process. It is difficult to be effective in moving to this new environment while saddled with existing business structures.

Business organization is typically vertical. Groups of employees with similar skills are placed under a manager in one part of an organization. Projects, on the other hand, are typically staffed horizontally, utilizing skills from several 'vertical' organizations.

By blending these structures, we can create a virtual organization, the Software Factory. This virtual organization possesses the advantages of each of these structures, but at the same time significantly enhances them.

From the business' perspective, the Software Factory is like any other manufacturing facility. An order is placed with the factory, where highly skilled, specialized 'work centers' use standard processes, reusable assets, and standard tools to produce the requested product. Once implemented the 'Software Factory' can help to assure consistent quality, reduce time to market, increase maintainability and manageability, and reduce costs.

 A typical software development organization will normally contain the following skills:

 A Software Factory is a collection of 50-170 professionals who, together, bring the skill set necessary to effectively produce quality software. Fifty is the minimum number to have a critical mass of the skills necessary, whereas over 170 would be large enough that the cohesion would be lost. Over 170 should be broken to create 2 or more Software Factories.

The members of the factory are grouped based on skill into the basic lifecycle categories: Analysis, Design, Coding & Unit Test, Lifecycle, and Automated Integration Test. Using standard processes, standard tools and standard methodologies, these specialized 'work centers' can produce their 'piece' of the product, passing it along to the next 'work center'. By having standards in place, and adhering to these standards, each subsequent 'work center' will have a specific definition and understanding of what artifacts to expect and of what artifacts to subsequently deliver.

Several 'Software Factories' may exist where there are discretely different runtime environments, but for the most part, the developers should be insulated from these differences.

The flow through a 'Software Factory' might be as follows:

A business entity identifies a business need for a development project. The requirements are submitted to the Software Factory or factories for 'bidding'.

The Analysis team then assesses the requirements and feasibility of the order. The specific requirements are documented in a standard tool, such as Rational's Requisite Pro. The requirements are stored in a Configuration Management tool, such as Rational's Clear Case, and the Design Team and the Automated Integration Team are notified of the documented requirements.

The Design Team takes the requirements and creates a model of the application, using another standard tool, such as Rational's Rose. The Design Team then reviews with the Analysis Team that the model meets the defined requirements. After acceptance, the model is passed to the Code and Unit Test Team for development. The design is also stored in Clear Case.

The Code and Unit Test Team uses the model, and standard tools and processes, to generate the code to address the requirements. As there will undoubtedly be interfaces to other systems, and possibly GUIs, emulators for these interfaces should be created fairly early. Standard generation tools should be used, such as IBM's Object Builder, or Visual Age for Java. Each discrete component should be coded and tested to the defined interfaces, as described in the component model.

The generated code is then passed to LifeCycle Management, where it is logged, versioned and documented. Using standard tools, such as Rational's Clear Case and Clear Quest assures consistency across runtimes, domains and iterations. The code components are then packaged and passed to Test.

The Integration Test team performs the final acceptance test prior to placing the code out for user testing. This team has already taken the original Requirements and written test routines to exercise each functional requirement. By creating automated test harnesses , each iteration of test is assured the same level of consistency and completeness. The automated test is validated against the original requirements, and is logged in the configuration management tool, Clear Case. Test results become, just like the original requirements and application model, an integrated part of the lifecycle management of this application. Automated testing is especially important. Testing represents a very large portion of the costs of all software development. However, in Component development, the number and variety of possible interactions require very formal and effective component testing. Automation is the only realistic way to consistently achieve the required level of testing effectiveness.

There is a traditional perspective in IT that the major cost in the software lifecycle is in the coding. Recent experience and evidence is mounting up to indicate that increased costs associated with the testing and validation of the application are a very significant portion of the true costs. Tools can effectively automate testing, providing substantial improvements in efficiency and effectiveness. The scripting function of Rational's Clear Case can automate the build process.At the end of the build the testing function can be automatically launched. Rational's Test Robot can be used to create the testing scenarios, including function test, reliability test and regression testing. Additionally, using Rational's Performance Studio can test the expected performance of an application.

An advantage to automated testing is the assurance that when, in the future, the application is maintained or enhanced, all the original function remains. With automation, regression testing is very straight forward.

Reuse

Creating a virtual software development organization offers many advantages over more traditional software organizations. With an organization of 50-170 people possessing a nucleus of skills in a tightly coupled, knowledge based environment, teamwork and creativity is enhanced significantly. Each person learns what to expect from the others, and what the others have come to expect from them. Collaboration and quality improve. This translates to improved time to market, improved management and maintainability, and reduced costs.

There is also another potential benefit that we can discuss: reuse, that elusive panacea that every organization strives to attain, but that none truly has.

An entire paper can be devoted to this subject, and in fact several have been. Here are some thoughts that can facilitate moving in the direction of reuse.

Creating the virtual organization of the Software Factory creates 'domains of knowledge' within the working group. These work centers in the software factory contain like skills in a tightly coupled team. If through no other method than familiarity, some level of reuse will be attained in this environment. However, it behooves the organization to put in place disciplines to facilitate a more formal environment, and the Software Factory construct provides the framework on which to support reuse.

At a minimum, a tool such as Clear Case should be used to store and document reusable artifacts. The actual organization can help to enhance this effort as well.

The Software Factory is a virtual organization that, through familiarity, can assist in identifying reusable assets, the physical organization can promote this as well. Should the physical organization be aligned such that like skills report to the same management (e.g. all architects in a unit), through regular team meetings artifacts can be identified. If in these meetings there is discussion as to the current projects needs from members of different Software Factories, there is opportunity to identify that a specific approach may have been used in the past. Archiving and documenting the function and interfaces of the component is fundamental, but the interaction in the formal structure of a Software Factory will assist in encouraging reuse.

As an organization matures, they may want to put in place an architecture review board in conjunction with the Software Factory. This review board should be staffed by the more senior architects, and they should play the role of reviewing ALL designs. By doing so they not only can assure that a design meets the enterprise standards, but also can help identify where an existing artifact might be reused, or where a new artifact may be a candidate for reuse. In the latter case they can also assist in the definition of interfaces for the reusable candidate.

Beyond the human oriented interaction that the Software Factory structure facilitates, there is also a formal life cycle for all of the information and artifacts of a project. Using effective tooling, the stated requirements of a project are captured in machine readable form in requirements documents, particularly Use Case Scenarios and the subsequent requirements derived from them. The life cycle management of requirements, linking them to designs, and actual developed code, and then following up with testing results, user acceptance issues, further refinements of the original requirements, and finally long term issues tracking allows an organization to hold and analyze a great deal of information about why a particular module was made, what business needs it is designed to fulfill, and what other modules it relates to, uses and affects. All of this information, if properly managed, can be used by the architecture and design teams in the Software Factory to search for and identify opportunities for reuse.

The capabilities that have evolved in recent years in search engines for the sifting of large amounts of information can be applied to the working artifacts of the Software Factory. This is one case where the added formality of this approach not only benefits development efforts directly, but the legacy of complete and accurate project collateral can benefit all future projects in an organization.

 

This information is provided by IBM Corporation

 © Copyright IBM Corporation 1999-2000

 

Display Rational Unified Process using frames

Rational Unified Process