The Software Factory - A Virtual Organization
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
|