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. firstname.lastname@example.org ,email@example.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 . 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 . 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 which implies the adoption of: • • • • • Standard development tools Graphical user interfaces
Project management improvement, which implies the adoption of: • • • • • • Standard planning methods Standard management methods Financial and control databases and systems Quality assurance methods Knowledge managements methods and systems Employee training and evaluation
Standard development methods
Software reuse practices and technologies (component oriented development) Software configuration methods and systems management
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) . 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 . 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 .
The modeling of a software process has been treated in different ways, mainly mathematical modeling  and process modeling. In this case, the proposed approach
is to use the discrete event  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. 2. 3. Developer: the person in charge of coding the software design specification. Software component: is the basic work unit; a piece of software functionality capable of being integrated with other components to build a system.. 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.
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 , 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  can be adopted.
 The myth of code-centricity. Jack Harich. JavaWorld. 2001. http://www.javaworld.com/javaworld/jw-08-2001/jw-0824-myth_p.html  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  Discrete-event system simulation. J. Banks, et. Al. Third edition. Prentice Hall.  Fábrica de software: Un modelo de negocio certificable basado en Estructura y Capacidades Alberto Balderas Padrón & Arnoldo Díaz Olavarrieta. Certum. 2001.  Forrester System Dynamics Modeling of Software Development Processes. Hans Vangheluwe. December 2001.http://www.cs.mcgill.ca/~hv/classes/MS/assign.sd.html  Software Process Modeling and Simulation: Why, What, How. Kellner, Madachy & Raffo, Journal of Systems and Software, Vol. 46, No. 2/3 (15 April 1999).  Getting the Benefits from Software Process Simulation. David M. Raffo. International Conference on Software Engineering and Knowledge Engineering (SEKE’99), Kaiserlautern, Germany, June 1999.  Distributed Objects & Components: General Information. Cetus Links. 2002. http://www.cetus-links.org/oo_distributed_objects.html  The Product Line Practice (PLP) Initiative. The Software Engineering Institute (SEI). Carnegie Mellon University. 2002. http://www.sei.cmu.edu/plp/plp_init.htm