A MODEL FOR DEFINING SOFTWARE FACTORY PROCESSES

19 th International Conference on Production Research A MODEL FOR DEFINING SOFTWARE FACTORY PROCESSES L. Nomura, M.M.Spínola, A.C. Tonini, O.K. Hikage (Luzia Nomura, Mauro de Mesquita Spínola, Antonio Carlos Tonini, Oswaldo Keiji Hikage) Production Engineering Department, Polytechnic School, University of São Paulo, Av. Prof. Almeida Prado, 531 1. andar, Cidade Universitária, São Paulo, São Paulo, Brasil Abstract A growing number of software producing companies has adopted the denomination Software factory, the organizational structure of which facilitates outsourcing by means of segmentation of activities and adoption of a more flexible and dynamic production system. In this environment, one of the main issues to be resolved is how to map processes, clearly identifying what, who and how each work has to be conducted, aligning activities to the company organizational structure. With this purpose, the paper presents a Model for Defining Software Factory Processes, applied in field by means of an action research concerning the process modeling of a system improvement project. The final result provided a clear and defined view of the process, allowing the identification and improvement of critical points, besides aiding the management of service demand, people, processes and outsourcing activities. Keywords: Software factory, software process, software reuse, outsourcing 1 INTRODUCTION Greenfield [1] mentions that the projection of the software global and total demand undergoes a great increase in order of magnitude, activated by the new powers in global economy, such as the emergence of China, the propulsion of software factories in India, and also the growing role of software in the social infrastructure, for new types of applications, and for the new platform technologies such as Web services, mobile devices and intelligent devices. One of the solutions companies have sought to meet these demands is the increasing popularity of outsourcing, which is an outsourced software development and maintenance operation with some factory operation attributes. With the advent of outsourcing, all project disciplines may be Software Factory (SF) products such as planning, business analysis, requirement elicitation, analysis and design, construction and tests. However, for the total production process of a SF to be effective, it is necessary to count on software development models based on clear and well defined processes, specialized professionals and productive reuse of software assets. This paper intends to contribute with these purposes by presenting a Process Definition Model oriented to a Reference Organizational Model of a Software Factory. The Process Definition Model is developed as from the analysis of fundamental element matrices composing the processes, such as functional areas attributions; roles and responsibilities; input and output artifacts; list of activities; rules and procedures, besides the establishment of the process definition stages and the production of a process modeling diagram. The action research was conducted in a company mixing Information Technology and Communication, with a Software Factory organizational structure, and which works for the Municipal public sector of São Paulo City Brazil. The practical application of the model showed how the mapping of system improvement project development process was conducted according to the parameters established. 2 SOFTWARE FACTORY The term Software factory emerged back in the 1960s and 70s, in the United States and Japan. Cusumano [2] was one of the main authors to disseminate the term, after his researches in the late 1980s, concerning software development practices. According to the author, the success of SF in Japan and in the United States is due to the inclusion of high reuse rate, modularization, use of tools, control and system management, thus increasing quality and flexibility. The SF designs developed showed that the gain in productivity in the Japanese industry could be overcome by the adoption of its work methods with simplification, conceptual integrity, adherence to standards and selective automation in the development process. According to Swanson [3], the information system literature does not contemplate the expression Software Factory, but concentrates on key-aspects concerning the concept, such as reuse. Applied reuse is understood as every set of activities proposed by Software Engineering and not merely centered on the code lines. In the change of paradigm in the software development, from a handcraft form to science, the following are comprehended: methods and standard tools, automated support for development, disciplined planning, analysis and processes control, as well as reusable codes and components. As stated by Basili et. al. [4], software objects and their relationships incorporate a great amount of past experiences and development activities. It is this reuse experience that needs to be fully incorporated in the software production process. Basili et. al. [4] proposed a reuse-oriented organizational framework defining two structures: a project-oriented organization and the other denominated experience factory. The experience factory is an approach to monitor and analyze the designs developed, to develop and to pack the reuse experiences from different types of experiences the organization has such as knowledge, processes, tools and products, always aiming at the reuse of these software components. Fernandes [5] presents a software factory framework classified into four different scopes according to the actuation along the development phases of software project. The project factory acts more comprehensively in the production process, encompassing phases such as conceptual project, logic specification, detailed solution project, conduction of integration and acceptance tests. The factory may be characterized by software projects or physical projects; however, its requirements and basic characteristics are very similar. In the case of software design factories, it is necessary to know the client s business. The program factory main aim is to codify and test programs. In its productive process, it encompasses

the construction and unitary phase tests. For the author, the basic attributes of a software factory are: Defined and standardized process; Controlled interaction with the client; Standardized service requests; Costs and time estimations; Strict control of the resources involved in each factory demand; Control and storage in software item libraries; Control of status and execution of all demands; Products generated according to standards established by the organization; Team trained and capacitated in the organizational and productive processes; Product quality control; Client service processes; Defined measurements and control of agreements at service level defined with the client. 3 SOFTWARE FACTORY REFERENCE MODEL The ambience of the study was based on a SF reference model, shown in Figure 1, developed as from a theoreticalconceptual base, as well as on the analysis and empirical observation of SF models practiced in the Information Technology market in Brazil. The concepts used refer to themes and authors: reuse of the Experience Factory by Basili et. al. [4]; operation management and SF organizational division by Fernandes [5]; application of the Software Engineering activities mentioned by Swanson [3]; work methods improvement mentioned by Cusumano [2]; simultaneous Engineering practices mentioned in PMBOK [6] and concepts and terminologies from the Rational Unified Process - RUP [7]. According to Vasconcellos [8], when two or more structure forms are simultaneously used on the members of an organization, the resulting structure is called matricial. While the functional organization favors specialization and knowledge accumulation, the organization by projects favors the orientation to some type of result or problem to be solved. The SF reference model infers in a Matricial Model and comprehends the following functional units: - Service to client: composed of managers and analysts mastering the business area, sales and relationship with the client, responsible for negotiation, contract elaboration and management according to clients needs. - Project office: According to PMBOK [6], a project office (Project Management Office) is an organizational unit that centralizes and coordinates project management under its control. A PMO can also be called a program management office", "project management "office", "support to project practices" or "program office". A PMO supervises project management, programs or a combination of both. PMO concentrates on planning, on prioritization and on the coordinated execution of projects and subprojects, bound to the headquarters or the client s general business goals. - Production Planning and Control (PPC): composed of area manager and planning analysts, responsible for generating, elaborating, programming, controlling and distributing service requests, allocating and making adequate efforts to meet the service requests and administrating the service distribution among the areas involved. - Business area: composed of project leaders and business analysts, responsible for modeling businesses processes, elaborating vision document, scope and project glossary, survey and specification of functional and non-functional requirements, screens and reports preliminary prototipation and elaboration of test plan. - Analysis and design area: composed of area manager and system analysts, responsible for generating the system architecture and integration, use case modeling and specification, detailing of screens and reports, generating data logic model. - Implementation area: composed of area manager, developers with knowledge in different technological platforms and programming languages, responsible for system and component codification. - Test and homologation area: composed of area manager and testers, responsible for integration tests, product quality guarantee and product final homologation. - Support area: composed of specialists, whose main function is to provide technical support to the different domain areas involved: architecture, engineering, codification, tests, data model, function points, standards, frameworks, components, technological platform, tools and techniques. This area maintains and develops technologies for the software factory. This support and knowledge dissemination are essential for establishing an Experience Database, fostering the reuse culture in the Software Factory environment. Depending on the company size, this area may be divided into specialization domains. - Infrastructure area: the Infrastructure area is responsible for supporting all hardware resources, software and services necessary for production processes execution. Depending the company size, this area may be divided into: change management, production management, telecommunication, network and safety management and service management. - Quality area: responsible for process quality, validation of delivered products, methodologies, norms, procedures, safety, measurements, and continuous process improvement. The production cells represent the multifunctional teams dynamically formed for executing service requests. The teams will follow a specific work process according to the service request category. At his point, it is important to remark that the workflow will follow the processes mapped by the model, object of this work proposal. The resources will be allocated and released according to the project planning needs. The production cells show a form of work organization corresponding to the Simultaneous Engineering concepts. According to Prasad [9], Simultaneous Engineering is a systematic approach for the integrated and parallel development of a product design and its related processes, incluing manufacturing and support. This philosophy is based on the synergy among its agents, who should work in multifunctional teams, formed by people from different areas of the company. This team should expand and shrink along its existence, always keeping the same core of people, who follow the development. During some activities, clients and suppliers sould join the team, when work is done on the supply chain concept. The whole of the team work must be supported by resources, methods and integrated techniques. It is important to stress that all the company elements involved in this Simultaneous Engineering definition (activities, information, organization

19 th International Conference on Production Research and resources) have to be considered in the software development process model. The organizations multifunctional and matricial organization, characteristics inherited from Simultaneous Engineering, allows companies the punctual allocation of their professionals, optimizing their works and better planning the activities necessary to projects execution. PMBOK [6] uses concepts from Simultaneous Engineering, proposing that a project should be multifunctionally conducted, by matricial allocation of people according to the time defined (project phases) and of each person s technical-professional specialization. The reuse artifacts and processes repositories represent one of the most important concepts emphasized in a SF context, to improve knowledge management as from experiences acquired and from new experiments. Reuse reduces time, improves quality and cuts costs. Prieto-Diaz [10] mentions three tendencies that may help solve reuse problems: analysis and domain engineering, processes reuse and megaprogramming. The author comments that the community is checking the possibility of creating collections of reusable processes that may be connected to calling for new and more complex processes; he also stresses that process reuse is a way of reusing experiences (practices) and knowledge. One of the purposes of the Process Definition Model is to allow the creation of reusable processes. Fiorini [11] defines process reuse as the use of a process model for creating another process. 4 SOFTWARE PROCESSES Davenport [12] defines process as a set of activities that must be conducted to serve a client; it is a specific structure of activities located in time and in space, with a beginning, an end, inputs and outputs clearly identified. In the software area, Humphrey [13] defines process as a set of software engineering tasks necessary to transform users requirements into software. For establishing the Model for Defining Software Factory Processes, concepts and terminologies from the Rational Unified Processs [7] are used, which shows two Figure 1: Software Factory Reference Model dimensions: the first is the dimension representing the process static structure, describing how the process elements are logically grouped into disciplines. Disciplines are logical groups of roles, activities, artifacts and other guides for describing a process, and are represented by a workflow. The second is the dynamic dimension represented by time and expresses the process by means of cycles, broken down into phases, which are divided into iterations with conclusion marks. The RUP [7] software development process is iterative; in it, iteration incorporates a set of activities in business modeling, requirements, analysis and project, implementation, tests and implementation, in different proportions, depending on where the iteration is located in the development cycle. 5 MODEL FOR DEFINING SOFTWARE FACTORY PROCESSES According to Humphrey [13], there is a set of fundamental elements that have to be incorporated to any defined processes, that is, who, what, how and when a certain activity as to be conducted. Who is defined by actors, their roles and responsibilities; actors, in the SF context, refer not only to people but also to the attributions and responsibilities of each functional area; What is defined by input and output artifacts; How is defined by the sequence of related activities; and When is defined by the life-cycle phases, associated to schedules. Other elements composing the process definition and aiding its automation are tools, techniques, standards, frameworks, norms, procedures and methodologies. With the use of Diagram IDEF0 - Integration DEFinition Language [14], the Model is represented, as shown in Figure 2, indicating inputs, outputs, rules and mechanisms involved. The inputs refer to the fundamental elements for SF process definition, which constitute: - Vision of the Software Factory Organizational Structure: To know the processes means to know how products and services are planned, produced and delivered. According to Cameira [15], an important point in process mapping refers to the functional vision issue (vertical vision) versus processual vision (horizontal). The horizontal vision allows breaking functional barriers, and treating information flows

as processes, promoting a company functions linking, conducting the activities link in relation to the processes. As stated by Davenport and Prusak [16], one of the relevant factors to have in mind when process survey and modeling processes are conducted is understanding the information transversal flows. established and ordinated behavior for conducting the activities; Standards, frameworks: models, techniques and architectures used to contribute to process automation. After they are officialized in the context as rules, they begin to contribute to software artifacts reuse; Methodologies: process models established as company policies. After they are officialized in the context as rules, they begin to contribute to software process reuse. - Mechanisms refer to techniques, tools, human resources, infrastructure, support, that is, software resources, hardware or peopleware used for operational support and formation of the technological environments necessary for software development and maintenance. - Model output is represented by the mapped process flow, containing its identification, description of its goal and its graphic representation, and textual specification. Process modeling follows the Diagram representation shown in Figure 3. Figure 2: Software Factory Process Definition Model - Functional areas attribution: refers to the definition of roles and responsibilities of the SF areas directly involved in the production process: service to client, project office, businesses, analysis and design, implementation, tests and homologation, production planning and control, infrastructure, support and quality. - Process categories: are the production process categories related to the service requests received by the SF such as : new project development or improvement projects, software component development, adaptive and corrective maintenance. - Roles and responsibilities: role defines an individual s or a group s behavior and responsibilities [7]. - Activities and sub-processes: roles have activities defining the work they execute. The activities have artifacts as input and produce artifacts as output [7]. The activities and sub-processes are conducted in a certain order by means of which resources are modified. - Input and output artifacts: artifact is what is generated or received, that is, any piece of information used, created or modified during the software development. RUP [7] supplies models (templates) for several artifacts, totally compatible with Unified Modeling Language (UML) [17], reinforcing standardization and reuse. Inputs are objects consumed or transformed (refined) in the process. Outputs are objects produced by the process as a result of input transformation, and may serve as input for another process. - Technological Platforms: a Software Factory serves different technological environments such as mainframe, low platform, web, client-server and integrated systems, which may lead to different processes. - Technical Profile: a Software Factory requires different technical profiles of the professionals with knowledge in business domain areas, technological platforms, programming languages. - Rules refer to company policies, define how the business has to be structured and how processes have to be related. The rules may be classified as administrative, procedural and technical, such as: Norms and procedures: manuals or directing guides ruling the organization and functional units, besides well Figure 3: Process Modeling Diagram The goal or reason of the process may be divided into subgoals associated to specific areas of the business. It corresponds to the resource status at the end of the process. In the diagram, the process domain or functional areas are distinguished by colors, facilitating visualization. The roles and responsibilities are indicated between brackets in the Figure describing the process or corresponding activity. 6 ACTION RESEARCH THIOLLENT [18] proposes that a research may be qualified as action research when there actually is an action on the part of the people or groups involved in the problem under observation, oriented in function of the problem resolution or of transformation purposes, seeking an interaction between the researcher and the participants of the situations researched. The action research was conducted in an Information Technology and Communication company, with Software Factory organizational structure, which serves mainly the Municipal Secretariats of the Municipality of São Paulo City - Brazil. The different nature of the clients requires the company to maintain a complex development environment and the direct involvement with the most varied technological platforms. The action research occurred after a request from the Board to define the system development methodology aligned to the new FS organizational model. One of the design stages refers to mapping the system improvement project development process. An improvement design according to PMBOK [6] is the implementation of new

19 th International Conference on Production Research functional and non-functional requirements for an existing system. The Model Definition stages were based on Slack et. al. [19] process definition concept which comprehend: Study on the work method The company previous organizational structure was formed by project teams, composed of managers, business analysts, system analysts and, in some projects,developers and testers, although the company counted on an implementation and test area. The work was organized in business domain management groups in which the system was conceived and developed according to each service area. In this context, by analyzing the improvement design process, it was verified that most of the times the implementation or updating was directly conducted by a professional that mastered the system, with no formal documentation record, many times after request by telephone or e-mail. This form of work did not allow adequate subsidies for assessing and following up the performance of products or of the clients requests, besides concentrating the business intelligence in some persons head. Work design The new organizational structure of the Software Factory is composed of the Service to Client, Project Office, Production Planning and Control, Businesses, Analysis and Design, Implementation and Tests, Quality, Support and Infra-structure areas. This change occurred mainly in Figure 4: Flow of the system improvement design process function of the need for costs management system implementation, prices, deadlines, processes, production control, outsourcing, better use of resources and meeting the clients increasing demand for services, aiming more and more at the focus on the client. In the new organizational model, the company board defined the functional areas attributions, as well as the role model and the functions degree of autonomy and responsibility. Work division The process design includes dividing a certain task into as many parts as are convenient for each individual to accomplish it correctly and efficaceously. For this, it takes into consideration personnel specialization, reuse practices and and also the best use of resources. The processes, sub-processes and activities were defined according to the Model proposed, taking into consideration the functional areas attributions, the role and responsibility model, the flow of activities, the input and output artifacts, rules and mechanisms involved in the process. Process design Specification of the process activity flow, considering the precedence and dependence rules, result in the process specific workflow. the improvement design process was mapped aligned to the organizational structure of the Software Factory Model, using as representation the Modeling Diagram proposed. The mapping shown in Figure 4 was validated by means of a series of meetings with

managers, analysts, and stakeholders, seeking the integration of all functional areas involved in the system improvement design process. 7 CONCLUSION This paper presented the conceptual characteristics of the Process Definition Model aligned to the Organizational Structure of a Software Factory. The action research describes the implementation of the Model proposed in an um improvement project process adequate to the FS organizational structure. The elicitation and analysis of the present process and of the elements defined in the Model resulted in the process workflow, clearly showing the flow of activities permeating the functional areas; the roles and responsibilities of the areas and people involved and the definition of input and output artifacts and templates to be used. The mapping provided greater transparency to the process, the visualization of the links between areas, allowing the identification of control points and process measurements, besides diagnoses of the process conflict zones and critical points. [15] Cameira, R., Caulliraux, H., Engenharia de Processos de Negócios: Considerações Metodológicas com Vistas à Análise e Integração de Processos, São Paulo, SIMPOI, 2000 [16] Davenport,T.H.,Prusak,L.,Conhecimento Empresarial: Como as organizações gerenciam o seu capital intelectual. Tradução: Lenke Peres, Rio de Janeiro, Ed. Campus, 1998. [17] UML Unified Modelling Language, available at: http://www.uml.org/ [18] Thiollent, M., Metodologia da Pesquisa-Ação. Brasil: Cortez. 1986. [19] Slack, N. et. al., Administração da Produção, São Paulo,Editora Atlas, 1996. Thus, this work expects to contribute to improvement and reuse, to avoid overwork by distributing activities, to establish the specialization and responsibilities of each area involved, to infer in the software assets reuse, gradually inserting them in the process definition, to facilitate activity outsourcing and, mainly, to guarantee the quality of the products and services supplied by the Software Factory. 8 REFERENCES [1] Greenfield, J., O caso das fábricas de software. Artigo Microsoft Corporation, julho 2004. [2] Cusumano, M. A., Japan s Software Factories. Oxford University Press, 1991. [3] Swason, K. et al., The application software factory: applying total quality techniques to systems development. MIS Quartely, Dec 1991. [4] Basili, V. R. A reference Architecture for the Componente Factory. Revista ACM, Jan,1992. [5] Fernandes, A. A., Teixeira D. S. Fábrica de Software: Implantação e Gestão de Operações. São Paulo, Editora Atlas, 2004. [6] PMBOK - Project Management Institute. A guide to the project management body o knowledge. Pennsylvania. Project Management Institute Inc., 2000 [7] RUP - Rational Unified Process, Version 2003.06.00.65, CD-ROM. Rational Software [8] Vasconcellos, E., Estrutura das Organizações. São Paulo, Pioneira, 1989, 2ed. [9] Prasad, B., Concurrent engineering fundamentals: integrated product and process development, USA, Prentice Hall, 1997. [10] Prieto-Diaz, R., Arango, G., Domain Analysis and software systems modeling. California: IEEE Computer Society Press Tutorial, 1991. [11] Fiorini, S. T., Arquitetura para Reutilização de Processos de Software, PUC-RIO, Tese de Doutorado, 2001. [12] Davenport, T. H., Reengenharia de Processos. Ed. Campus, 1994. [13] Humphrey, W. S., Managing the software process. Addison-Wesley, 1989. [14] IDEF - Integration DEFinition Language, Available at www.idef.com.