SF-SM: Towards a software factory simulation model

Eugenio Jacobo Hernández Valdelamar

Fundación Arturo Rosenblueth. Insurgentes Sur 670-3. Colonia del Valle. CP 03100.
México, D.F, México.
jack@mail.rosenblueth.mx ,jack_hv@yahoo.com

Abstract. There’s a lot of expectation about software production. However

there’s almost no chance of evaluating new initiatives that improve this process
until some money, time and resources have been invested. For this reason it
may be useful to define a simulation model that defines the main characteristics
of the software production process. This article contains a first approach to this
problem.

Key words: software production, software factory, software product line,

process modeling, agent based simulation.

1. The idea of a software factory

Software development has been a difficult process, because in the beginning (and even
today), coding was the only thing that matters [1]. However developers got aware that
building each application from scratch was a time-resource consuming effort. This lead
to the planning approach, where many analysis and design methods have been
proposed lo limit the software boundaries before coding any part of a system. But even
having a plan and a good development team assigned to a project, most software
products have unique features, because almost all the development effort is dedicated
to proprietary products.
So, why software couldn’t be produced as a car in a production line? This question
made that software industry tried to raise an analogy of the production or
manufacturing line in the software development process. The software factory concept
appears as an answer to improve the software development. The need for predictable
structure and practices have lead the software industry to the development of standards
and guidelines that let the producers have control of the software development [2][4].
At this point many questions arise:
• What does an active software company need to become a software factory?
• If a company implants all these practices, methods, tools and technologies, does it
becomes a software factory?
• Does the company understand the organizational processes involved in software
development?
• Does the company know its own software development performance level?
Programmers productivity improvement, Project management improvement, which
which implies the adoption of: implies the adoption of:
• Standard development methods • Standard planning methods
• Standard development tools • Standard management methods
• Graphical user interfaces • Financial and control databases and
systems
• Software reuse practices and technologies
(component oriented development) • Quality assurance methods
• Software configuration management • Knowledge managements methods and
methods and systems systems
• Employee training and evaluation
Table. 1 Main components of a software factory
These question doesn’t need to be answered the spending money and time. If
companies could reflect their organization and operation, and see its behavior from
“outside”, maybe they could improve their productivity and management, and take the
right decisions to become software factories. The proposal is that defining a simulation
model for software factories, to see and analyze the behavior of this kind of
organizations will help companies to understand what to do and what it takes to
become a software factory.

2. Modeling the software development process

Even when management and financial processes are very important, the software
development process is the kernel of a software factory. To proceed, the following
definitions need to be established:
• A software process is a set of activities, methods, practices, and transformations
that people use to develop and maintain software and the associated products (e.g.,
project plans, design documents, code, test cases, and user manuals) [6].
• Component-based development represents the 'industrialization' of software
development. When any manufacturing process evolves to the point where it can
be based on pre-built components and subassemblies, product quality, quantity,
and speed of delivery soar. This principle applies equally to software systems
development, allowing unprecedented quality, speed of development, and highly
effective change management [8].
• A software process simulation model focuses on some particular software
development / maintenance / evolution process. It can represent such a process as
currently implemented (as-is), or as planned for future implementation (to-be).
Since all models are abstractions, a model represents only some of the many
aspects of a software process that potentially could be modeled – namely the ones
believed by the model developer to be especially relevant to the issues and
questions the model is used to address [6].
The modeling of a software process has been treated in different ways, mainly
mathematical modeling [5] and process modeling. In this case, the proposed approach
is to use the discrete event [3] and agent simulation paradigm. The main goal of the
Software Factory Simulation Model (SF-SM) is to define the entities involved in the
software process that can represent an existing or a future process in order to
understand its behavior. Even when the scope of the model is very ambitious, the plan
is to integrate different view of the process to get a complete overview of a software
factory.

3. Views of the software process

All the perceptions of a software process are relevant to understand its behavior.
Based on the author’s experience, some of these views are:
• Software life cycle. The requirements engineering, analysis, design, coding, test
and maintenance are the typical task of the software engineering process. The
order in which these task are performed may be critical for a project success. There
are several approaches like waterfall or spiral life cycles, so the tasks order is one
of the main decisions of a software process definition.
• Project plan. In order to measure the development effort a work plan is needed,
and in addition an estimation of time and resources needed. Obviously the chosen
life cycle is related.
• Development team workflow. The team is typically formed of people with enough
skills to develop software, but how is the team organized? What kind of roles will
play a rookie and an experienced programmer? Who will be the project leader?
What work units are dependant from others? Is there some interaction with other
teams?
• Code integration. At the core is the software integration dynamics. In other words,
how the code grows, how the components are assembled, when a new component
is needed and how the application is deployed.
• Testing. Each time a product release is ready, a testing plan is needed, so the
testers can check each part of the software functionality. If there is something
wrong, it must be returned to the development team to be fixed.

4. SF-SM: code integration view

In this first version of the model, the chosen perception is the code integration view.
The reasons to begin at this level are the following:
• In a product line it seems obvious that having a stock of raw material and
machines a product can be shaped. In the case of software development, material
isn’t always available; maybe a component library provides this material, but in
practice programmers not just integrate existing parts; they built them when it’s
needed..
• Software module dependencies are not always obvious, so delays in delivery can
appear during the process. These can be provoked by the complexity of
development of the modules, not well defined interfaces or problems with the
development tools. Software development planning is not a simple job.
The Software Factory – code integration process system definition is given by:
System components:
1. Developer: the person in charge of coding the software design specification.
2. Software component: is the basic work unit; a piece of software functionality
capable of being integrated with other components to build a system..
3. Software component repository: a database that contains the developed software
components, version control and component documentation.
System narrative (fig. 1 left): Having a project work plan and a design specification for
the system, assignments are given to developers, so they can begin to assemble/produce
the necessary component to build the desired system. A developer consults the design
specification and search in the component repository for any component that match the
specs; if there’s a component that fits, it is integrated to the system; else, the developer
must code the component according to the specification and integrate it to the system;
additionally the component must be registered and stored in the repository. A
possibility is that a developer may use a component not registered in the repository.

Fig. 1 SF-SM v.0.1 component integration process and the agent simulation model of SF-SM
v.0.1 component integration process
In addition time or cost may be assigned to each developer action, so the model will
reflect the actual cost of the product development.
In this version all that developers must do is “filling the blanks”. Actually some
interactions can be added to the model. For example, component dependencies can be
established; communication between developers can be managed in a blackboard to
avoid work duplicity. This changes will be part of future versions.

5. SF-SM simulation

Simulation of the SF-SM has been implemented with an agent oriented simulation
tool named AgentSheets. With this tool is very easy to model all the entities related to
the system as agents, and their behavior is defined by rules and methods. An advantage
of this tool is that is possible to visualize the entire system dynamics, so the users can
see each part of the process, and configure other possible scenarios. However to
implement the model, several elements were added during the process, specially
positional references that let the agents describe paths related to each development task
(fig. 1 right). These elements were modeled as an agent called Plan, and its states are:
• Check Plan Point. A place were the developer consults the design model and gets a
requirement to work with.
• Search point. A place were the developer asks the repository manager to search for
an existing software component, and receives an answer (component available or
not available).
• Work place. A place where the developer programs a new component for the
system.
• Integration point. A place where the developer integrates an existing or new
component to the system; in the real world this may require some extra lines of
code.
• Turn. A reference to change direction when returning from component assembly.
With this model, is possible to see a development process that consists of the
following steps:
• Developers must go to a check plan point to get a design specification to start
working. Once a developer has an assignment, it must go to the search point to
consult the repository manager about the availability of the component required.
• Repository manager search for the desired component in the component space and
gives an answer to the developer (component exist or not). If component doesn’t
exist in repository, developer must go to its work space, and code the required
component; once finished developer must send the component to the repository
manager to store it.
• From its work place, developer must go to the integration point to add the
component to the system according to design specification.
• When component integration is finished, the developer can return to the start point,
and start all the process until no design requirement are left.
Adjusting the conditions of the simulation is possible to see consequences of:
assigning more work to one developer, limited storage space in the repository, a bad
design specification, assigning experienced developers and rookies (productivity) or
having a component repository and starting a new one.

6. Conclusion

To understand the dynamics of software production is very important for the

developers and project managers, because both must see that software planning
(analysis and design) is critical to improve development, and that many factors, as
human or software errors can slow down the productivity of the whole project. The
proposed simulation model at this point just covers some aspects of software process,
but it gives a perspective of the importance of infrastructure and organization needed to
produce software, as well as the people involved. The model definition method
proposed is an important contribution to those interested in defining this kind of
systems. It is more relevant if as suggested in [1], software development can be
automated, so if the company understands how their expert implement the system
requirements, it may be possible to catch these knowledge in a system capable of
interpreting high level specifications to do the work. In this scenario the simulation of
those rules can be the beginning of such systems. Some proposed improvements to the
simulation model are the following:
• It’s necessary to extend the model to allow more developers to collaborate in the
system construction and developer communication must be added in order to avoid
possible work duplicities (for example, 2 developers that have the same
assignment, and both produce a component).
• In this version, component behavior is passive; there are no errors during its
integration to the system, which is not so real. Component errors may cause that
developers (a) test the component before integrate it to the system, or (b) fix the
code error, that implies to store a new version of the component in the repository.
• In order to use data from a real development environment, it may be possible to
adjust the model with some of the software metrics that a method or a practice
establishes, and some guidelines from the Product Line Initiative [9] can be
adopted.

References

[1] The myth of code-centricity. Jack Harich. JavaWorld. 2001.

http://www.javaworld.com/javaworld/jw-08-2001/jw-0824-myth_p.html
[2] La oportunidad de la fábricas de software. E.J. Hernández Valdelamar. InterFAR. 2002.
http://www.rosenblueth.mx/InterFAR/Vol1Num3/doc/Vol1Num3-50.htm
[3] Discrete-event system simulation. J. Banks, et. Al. Third edition. Prentice Hall.
[4] Fábrica de software: Un modelo de negocio certificable basado en Estructura y Capacidades
Alberto Balderas Padrón & Arnoldo Díaz Olavarrieta. Certum. 2001.
[5] Forrester System Dynamics Modeling of Software Development Processes. Hans
Vangheluwe. December 2001.http://www.cs.mcgill.ca/~hv/classes/MS/assign.sd.html
[6] Software Process Modeling and Simulation: Why, What, How. Kellner, Madachy & Raffo,
Journal of Systems and Software, Vol. 46, No. 2/3 (15 April 1999).
[7] Getting the Benefits from Software Process Simulation. David M. Raffo. International
Conference on Software Engineering and Knowledge Engineering (SEKE’99), Kaiserlautern,
Germany, June 1999.
[8] Distributed Objects & Components: General Information. Cetus Links. 2002.
http://www.cetus-links.org/oo_distributed_objects.html
[9] The Product Line Practice (PLP) Initiative. The Software Engineering Institute (SEI).
Carnegie Mellon University. 2002. http://www.sei.cmu.edu/plp/plp_init.htm