PhD Thesis - extended summary -

Transcription

1 Investeşte în oameni! Proiect cofinanţat din Fondul Social European prin Programul Operaţional Sectorial Dezvoltarea Resurselor Umane Dipl.-Ing. Cristian-Victor CODRE PhD Thesis - extended summary - CONTRIBUTIONS REGARDING LIFE CYCLE APPROACHES ON THE DEVELOPMENT OF PRODUCTS IN COLLABORATIVE ENVIRONMENTS Scientific advisor Prof.Univ.Dr.-Ing. Sorin POPESCU TECHNICAL UNIVERSITY OF CLUJ-NAPOCA FACULTY OF MACHINE BUILDING 2011

2 MINISTRY OF EDUCATION, RESEARCH, YOUTH AND SPORT TECHNICAL UNIVERSITY OF CLUJ-NAPOCA FACULTY OF MACHINE BUILDING Cluj-Napoca, Muncii Blvd. MEMBERS of the evaluation committee Assigned by the Technical University of Cluj-Napoca Rector s order no. 372 / PRESIDENT: SCIENTIFIC ADVISOR: REFERENTS: Prof.Dr.-Ing. Petru BERCE Dean, Faculty of Machine Building Technical University of Cluj-Napoca Prof.Dr.-Ing. Sorin POPESCU Faculty of Machine Building Technical University of Cluj-Napoca Prof.Dr.-Ing. Ion VIŞA Faculty of Product Design and Environment Transilvania University of Braşov Dr.-Ing. Carmen CONSTANTINESCU, MBA Institute of Industrial Manufacturing and Management University of Stuttgart Prof.Dr.-Ing. Stelian BRAD Faculty of Machine Building Technical University of Cluj-Napoca The date, time and place for the public presentation of the PhD thesis: September 12, 2011, starting from 09:30, Aula Domşa, 15 Constantin Daicoviciu Str.

3

4

5 Contributions regarding life cycle approaches on the development of products in collaborative environments CONTENTS INTRODUCTION...5 PART I: BIBLIOGRAPHICAL STUDY REGARDING THE DEVELOPMENT OF PRODUCTS FOR THEIR LIFE CYCLES...6 CHAPTER 1. STATE OF THE ART SYNTHESIS DESIGN FOR LIFE CYCLE A NEW PERSPECTIVE Arguments for life cycle approaches in design Arguments for implementing Product Lifecycle Management philosophy PRODUCT LIFE CYCLE General aspects (definitions, main phases) Examples of life cycle models Product life cycle stages. Particularities, goals and expected results STAKEHOLDERS OVER PRODUCT LIFE CYCLE Sources for stakeholders identification for an organization Requirements identification and analysis methods Stakeholders in collaborative environments CURRENT TRENDS IN PRODUCT DEVELOPMENT EXAMPLES OF PRODUCT DEVELOPMENT MODELS CHAPTER 2. RESEARCH NICHE IDENTIFICATION. RESEARCH PHILOSOPHY RESEARCH NICHE IDENTIFICATION RESEARCH PHILOSOPHY PART II: THEORETICAL CONTRIBUTIONS: KNOWLEDGE SYNTHESIS THROUGH A THEORETICAL PRODUCT DEVELOPMENT MODEL CHAPTER 3. THEORETICAL MODEL FOR PRODUCT DEVELOPMENT PREMISES MODEL OVERVIEW PRELIMINARY ANALYSIS STAGE CONSTRAINTS IDENTIFICATION STAGE PRODUCT PLANNING STAGE CONCEPT DEVELOPMENT STAGE CONCEPT ENHANCEMENT STAGE CONCEPT VALIDATION STAGE MODEL IMPLEMENTATION CHAPTER 4. COLLABORATIVE PRODUCT DEVELOPMENT PRELIMINARY ASPECTS (DEFINITIONS AND ARGUMENTS FOR COLLABORATIVE PRODUCT DEVELOPMENT) PRINCIPLES, CRITICAL SUCCESS FACTORS, RISKS AND LIMITATIONS OF COLLABORATIVE DEVELOPMENT Pag 3

6 Cristian-Victor Codre 4.3. TECHNICAL REQUIREMENTS FOR COLLABORATIVE DEVELOPMENT MODELS SYNTHESIS AND ANALYSIS OF REVIEWED COLLABORATIVE DEVELOPMENT MODELS PART III: PRACTICAL - COLLABORATIVE PRODUCT DEVELOPMENT PLATFORM CHAPTER - PLATFORM FOR COLLABORATIVE PRODUCT DEVELOPMENT REQUIREMENTS IDENTIFICATION AND ANALYSIS Identification of client s requirements Client requirements analysis and the implications on functional level and on data structures The deployment of client requirements up to logical components level TECHNICAL SOLUTION CONFIGURATION APPLICATION ARCHITECTURE Premises and representation Database architecture Main components of the application TECHNICAL IMPLEMENTATION Standard notations. UML diagrams Class diagrams Sequence diagrams Development of server application Application end points Business logic Data access layer Development of client application Execution sequence for an action BENEFITS AND ADVANTAGES 42 CHAPTER 6. ANALYSIS AND TESTING OF THE COLLABORATIVE PRODUCT DEVELOPMENT PLATFORM THE ANALYSIS OF THE PROPOSED TOOL WITH RESPECT TO THE TECHNICAL CHARACTERISTICS OF COLLABORATIVE PRODUCT DEVELOPMENT MODELS APPLICATION TESTING USING SPECIFIC TEST TOOLS CHAPTER 7. CONCLUSIONS, ORIGINAL CONTRIBUTIONS AND FUTURE DEVELOPMENTS SELECTIVE REFERENCES LIST OF FIGURES Pag 4

7 Introduction Contributions regarding life cycle approaches on the development of products in collaborative environments The research topic approached within this doctoral thesis is Contributions regarding life cycle approaches on the development of products in collaborative environments, a topic included in the research filed Engineering and Management. The opportunity and novelty of such an approach is highlighted by the presence of the topic among the current interests of the socio-economic environment. Two of the words which best characterize today s world are competitiveness and globalization. The fierce competition on the market and the need for being competitive in the conditions imposed by globalization and free trading have lead towards the need to master and manage all aspects related to a product along its entire life cycle. Moreover, the extension of the development chains and the geographical dispersion of the entities involved in product development are strong arguments for focusing research on a niche such as collaborative product development. The main objective of this research is to generate contributions, both at a conceptual level and at an operational one, in the field of life cycle approaches in collaborative product development. The subsequent research objectives were established in order to support this bidirectional development, according to the two levels of approach: conceptual level and operational level. At a conceptual level, as a main direction of intervention, the following has been set: the conception of a theoretical model for product development that can facilitate the design of products for their life cycle. The concept and development of a specific software tool, namely a platform for collaborative product development, has been considered as the operational level of this thesis. For supporting the abovementioned directions, the activities carried out within the doctoral programme were focused on fulfilling the following specific objectives: conducting bibliographical research on topics such as: product life cycle, stakeholders on life cycle stages, trends in product development, design for life cycle and Product Lifecycle Management; synthesizing knowledge as a theoretical model for product development that could support the design of products for their life cycle; critical analysis of some collaborative development models and the identification of common elements among these models; the development of a tool that can facilitate the development of products, based on stakeholders requirements, in a collaborative environment. As a starting point for this objective, the specific requirements for such a platform had to be identified and an analysis of the implications at functional and structural level had to be performed; the analysis of the proposed instrument against a set of common technical requirements for collaborative development tools. In the framework of the same objective, the proposed platform has to be tested using specific software performance testing tools. Pag 5

8 Cristian-Victor Codre Part I: Bibliographical study regarding the development of products for their life cycles Chapter 1. State of the art synthesis 1.1. Design for life cycle a new perspective Past years have brought a change in the way organizations consider the process of product development, leading towards a rediscovery of product s life cycle. Until recently, being competitive could be resumed at mainly four major objectives, namely: product quality improvement; manufacturing with minimum costs; reducing time-to-market; incorporating innovations. As a result of environmental awareness, a fifth objective could be now identified: considering the environmental impact of product throughout its entire life cycle. In other words, in order to reach long term competitiveness, sustainable development has to become a prerequisite of any organization Arguments for life cycle approaches in design Products are at the core of each organization, whether we refer to tangible (physical) ones, or intangible ones (services). The sustainability requirement for the organization migrates towards the sustainability requirements for its products. As a result, products are no longer developed to meet or to create a customer need or requirement, but from a stakeholders perspective. When several stakeholders on each life cycle stage are considered, the result would be a product which is designed for its entire life cycle. Among the arguments that lead towards the need to manage all aspects regarding product life cycle, the following can be mentioned: outsourcing the processes which are outside of the core competencies of the organization, having competitiveness as a driving axis; extending producers liability over all life cycle effects of the product; optimizing resources consumption on each life cycle stage; shift of perspective from customer-orientation towards stakeholders-orientation, each of them with particular requirements on each life cycle stage; the need to generate and run more product life cycle scenarios and the integration of the client in product customization; planning the support services associated with the product. Pag 6

9 Contributions regarding life cycle approaches on the development of products in collaborative environments Arguments for implementing Product Lifecycle Management philosophy Product Lifecycle Management represents a holistic business approach that facilitates the management of products throughout their life cycles, from the first idea of a product until their retirement from the market (Stark, 2005). Even if it requires considerable efforts, the benefits of such an implementation are considerable. (Stark, 2007) identifies four main areas in which the implementation of the PLM philosophy can bring improvements: financial performance using PLM concepts should result in an increase in incomes as a consequence of shorter time to market; efficient time management reducing development times; increased product quality using PLM concepts should lead to decreasing defects, scratch or reworks, and should decrease the number of customer complaints; improving overall business performance PLM could lead to increasing innovation rate, to increasing component reuse rate or to improving product traceability Product life cycle General aspects (definitions, main phases) (Brad, et al., 2006) defines product life cycle, similar to the biological life cycle, as the period in time between the launch of the product on the market and its retirement. Moreover, the same source refers to the extended life cycle of the product by considering the activities which occur before launching the product. When referring to a system, its life cycle begins with the conceptualization of a need for such a system, progresses through its realization, utilization and evolution, and ends in its retirement (ISO/IEC, 2008). Three major phases of a system s life cycle can be identified: beginning of life - BOL, which includes design and manufacturing; middle of life - MOL, which includes logistics, utilization, support and maintenance; end of life - EOL, which includes reverse logistics, remanufacturing, reutilization, recycling and elimination Examples of life cycle models Starting from the three aforementioned phases, depending on the context in which they are referred to, there are several life cycle stages configurations. The thesis emphasizes some of these approaches which are mentioned in scientific papers, such as: (Abramovici, et al., 2002), (Stark, 2007), (Yang, 2007), (Yang, et al., 2003) or in the ISO standard (ISO/IEC, 2008). (Westkämper, et al., 2006) extends the concept of product life cycle to the factory life cycle. In the paradigm Factory as Product, a factory is seen as a complex product with long life span. From this perspective, the concept of Product Lifecycle Management migrates to the one of Factory Lifecycle Management. Furthermore, Westkämper proposes a holistic reference model for factory engineering and design in which all phases of Factory Life Cycle, structured in clusters, are integrated continuously within the Digital Factory (Constantinescu, et al., 2009). Pag 7

10 Cristian-Victor Codre Product life cycle stages. Particularities, goals and expected results The life cycle model considered throughout the research period was the one given by the ISO standard (ISO/IEC, 2008). The life cycle stages according to this standard are: Concept, Development, Production, Utilization, Support and Retirement (Figure 1). Figure 1. System s life cycle stages according to [ISO/IEC 15288] 1.3. Stakeholders over product life cycle Sources for stakeholders identification for an organization According to (ISO/IEC, 2008), a stakeholder represents an interested party having a right, share or claim in the system or in its possession of qualities that meet their needs. It can be noted that these stakeholders can be both from within the organization, and especially from the external environment. Examples of stakeholders along the life cycle of the product are: users, developers, conceivers, manufacturers, maintainers, trainers, suppliers, regulatory bodies, retirers, community and society. (Courage, et al., 2005) identifies the following sources for requirements identification within the organization. Figure 2 depicts some of the requirements coming from several departments working together for developing a product. If the process of identifying stakeholders requirements within the organization seems somehow easier because of the direct access to these interested parties, the process of proper identification of stakeholders from the external environment, and their specific requirements, can be more difficult. Pag 8

11 Contributions regarding life cycle approaches on the development of products in collaborative environments Figure 2. Sources for stakeholders identification within the organization Requirements identification and analysis methods The key roles in product development and their interactions have to be well understood before advancing to the identification of needs and requirements for a specific target group. For the proper identification of actors and their interaction with the system, solutions such as UML (Unified Modeling Language) Use-case Scenarios can be deployed (Object Management Group, 2007). Papers, such as (Thabrew, et al., 2008) propose the integration of as many interested parties into the process of decision making. Works like (Brad, et al., 2006), (Brethauer, 2002) or (Courage, et al., 2005) propose the use of specific tools and techniques for requirements identification. Among these, a few can be mentioned: interviews, surveys, needs and requirements analysis, card sorting, group task analysis, focus groups, field studies, etc. Once these requirements are collected, they have to be processed and sorted (i.e. by using the Affinity Diagram - AFD) and furthermore they need to be prioritized (i.e. by using Analytic Hierarchy Process technique AHP or pair comparison matrixes). A model for requirements analysis is the Kano model which divides the requirements into three distinct categories: basic needs, performance needs and excitement needs. From a life cycle perspective, a correlation between stakeholders and life cycle stages can be observed. Having this in mind, the developers can propose the life cycle strategies with respect to the importance that each stakeholder has for the organization Stakeholders in collaborative environments The extension of the development chains, outsourcing and globalization have lead towards a higher dispersion of the actors involved in the process of product development. The integration of stakeholders in the development process can be nowadays achieved by the use of information and communications technology, namely by the use of collaborative development environments. The development of products for their life cycles raises issues regarding the Pag 9

12 Cristian-Victor Codre collection of data from the actors interacting with these products. Another challenge is in the management of information with time. Considering the factors that lead to collaborative development environments (globalization, outsourcing, internet development and ICT), the best solution for actively integrating all the stakeholders into the process of product development is by using web platforms. Figure 3. Stakeholders in collaborative environments (Codre, et al., 2011a) 1.4. Current trends in Product Development Figure 4 presents in a systematic manner the current trends in product development that were identified while reviewing the state of the art in the field. Figure 4. Current trends in Product Development (Codre, et al., 2010a) Pag 10

13 Contributions regarding life cycle approaches on the development of products in collaborative environments 1.5. Examples of Product Development models A product development model which is focused on a life cycle approach is Design for Six Sigma (DFSS). The inner objective of DFSS is to design it right from the beginning in order to prevent the negative effects that could occur downstream on the product s life cycle. The term of Six Sigma in the context of DFSS can be defined as the level at which the design vulnerabilities are minimum or not considerable anymore. (Yang, et al., 2003) identifies four major phases of DFSS, each of them having associated several stages. These phases are: Identify the requirements; Characterize the design; Optimize the design; Verify the design. This methodology, generically called ICOV by (Yang, et al., 2003) can be compared to the more usual Sig Sigma methodologies such as DMAIC (Define, Measure, Analyze, Improve, Control) for process improvement and DMADV (Define, Measure, Analyze, Design, Verify) for product design. In the PhD Thesis, two implementations of the DFSS methodology are analyzed, identifying both the stages and the sequence of steps in each of these stages. (Liu, et al., 2009) proposes a customer-driven product design model in the collaborative environment. The components of this model are: a model for requirements identification and sorting (gathering client requirements, formalizing functional requirements); a model for product architecture (design objectives decomposition, the deployment of objectives into activities and specifications); a model for product design (identification of feasible product design alternatives); a model for product design evaluation (evaluation of feasible concepts and selecting the best). (Courage, et al., 2005) proposes user-centred design as a product development approach that is focused on the end user of the product. According to this approach, the product has to be fit for the user and the user should not need to adjust to using this product. This aspect implies, for each life cycle stage, the use of tools and techniques which are focused on the consumer. Another product development model, organized in fourteen stages is the one proposed in (Brad, et al., 2006). Pag 11

14 Cristian-Victor Codre Chapter 2. Research niche identification. Research philosophy 2.1. Research niche identification Chapter 1.4 presented the context in which the process of product development takes place, identifying the main trends in the field and the pressures that the development teams now have to face. Furthermore, an essential element for an efficient development process has been identified, namely the development in the context of real-time collaboration between relevant actors for each life cycle stage. The use of tailored models can guide the development process by offering guidelines and recommendations that eliminate ambiguities. This will have as an effect a reduced time to market for the product. Therefore, a first direction of intervention can be identified, namely the conception of a theoretical model for product development, which, by pointing out the main stages and their interactions, could facilitate the design of products for their entire life cycle. Local development of a product is not a solution in the current market dynamics. There is a permanent need for tools which are capable of supporting real-time collaboration between geographically distributed entities. Starting from this desideratum, a second direction of intervention has been identified: the development of a software tool that will facilitate collaborative product development. This direction of intervention was considered as the operational orientation of the current thesis. Among the arguments that lead towards focusing the research on addressing a challenge such as collaboration in product development, the following can be noted: the integration of stakeholders within the same development environment has to be possible even in the case of their geographical distribution. For this reason, the application has to be web-based and to be accessed via web browsers. The research implications of this aspect were to study and manage the specific structure, particularities and technologies of web applications; starting from the capabilities of commercial PLM platforms, as a direction of intervention the following has been set: creating a tool with PLM platform capability that can be implemented even in small scale organizations, based on open source solutions. Moreover, a bridge between the facilities offered by managerial applications and the ones that assure the effective management of product s life cycle has been pursued; the ubiquitous challenge of time efficiency and the need to increase the user-friendliness of development methodologies have lead towards focusing on developing a tool that can facilitate the graphic representation of development algorithms and its integration within the web application; the management of continuously expanding data volume associated with a product throughout its life cycle and the management of complexity have lead towards the orientation of research into finding proper solutions for information and knowledge management in the context of a project / product and for effective and efficient know-how reutilization within the organization. Pag 12

15 Contributions regarding life cycle approaches on the development of products in collaborative environments 2.2. Research philosophy Figure 5. Research methodology Pag 13

16 Cristian-Victor Codre Part II: Theoretical contributions: Knowledge synthesis through a theoretical product development model Chapter 3. Theoretical model for product development 3.1. Premises Prior to the development of the theoretical model, the following aspects were considered: the model should facilitate the development of products for their entire life cycle; the model should facilitate the identification and integration of all major stakeholders; the model should allow for the integration of stakeholders requirements based on their relevance and importance for the organization; the model allows the deployment of the importance of each customer need up to the level of design elements; the model should facilitate multiple life cycle scenarios proposals and the selection of the best fitted by assessment against a set of predefined criteria; the model should be used as an interactive roadmap that will guide the process of product development; the model should refer to the documents which are necessary for fulfilling a task and to identify the steps in which existing know-how should be referred to Model overview The model comprises six main stages and a preliminary verification gate against a set of acceptability criteria. Figure 6 presents the algorithm overview and offers a short preview with their sequence and interactions. The six stages of the model are: Preliminary analysis, Constraints identification, Product planning, Concept development, Concept enhancement and Concept validation. Figure 6. Theoretical model overview Pag 14

17 Contributions regarding life cycle approaches on the development of products in collaborative environments 3.3. Preliminary analysis stage In this stage, the following activities are performed: customer needs and requirements identification, stakeholders identification, external environment analysis (competitors analysis, similar products, technical benchmarking), stakeholders prioritization and integrated product requirements prioritization. This step generates three major outputs, as follows: stakeholders hierarchy; product acceptability criteria; stakeholders requirements hierarchy. Figure 7. Preliminary analysis stage 3.4. Constraints identification stage Constraints identification is the stage in which the main decisions influencing the final solution are made. The potential life cycle strategies are advanced, the best of these strategies is selected after being analyzed against a set of criteria, the Design for X concepts applicable for the product are selected, the applicable Design for X guidelines are selected. Furthermore, a hierarchy of the DfX concepts and guidelines is obtained starting from the hierarchy of stakeholders from the previous stage. The correlation between stakeholders and DfX guidelines Pag 15

18 Cristian-Victor Codre has the purpose of optimizing the design in those areas that bring higher added value for the organization, from a stakeholder perspective. Figure 8. Constraints identification stage 3.5. Product planning stage The main output of this step is the list of modules and design elements based on their importance in fulfilling the functionality required by the customer. For achieving this result, the following activities are proposed. First, the critical-to-quality characteristics for the product are identified, assuring the translation of customer s voice into technical requirements. Further, considering the constraints identified in the previous stage, the functions of the product and the architecture of the product (modules, design elements) are defined. By means of several correlations, the importance that the stakeholders give to satisfying each of their requirements is transferred to the level of design elements. The correlations proposed in this model are based on the classic four-phase QFD and are as follows: correlation between stakeholder requirements and critical-to-quality (CTQ) characteristics, CTQs and product functions, product functions and design elements. Pag 16

19 Contributions regarding life cycle approaches on the development of products in collaborative environments Figure 9. Product planning stage 3.6. Concept development stage The fourth step of the model, Concept development, is dedicated to modelling the parts and the components of the product. The list of components by their importance, as resulted from the third stage and the Design for X recommendations, based on their hierarchy as resulted from the second stage, are the main inputs of this step. Figure 10. Concept development stage Pag 17

20 Cristian-Victor Codre Another potential input for this step is given by the change proposals resulted from the analysis performed within the Concept enhancement stage. The main output of this activity is the preliminary bill of materials and the CAD files of all modules and components Concept enhancement stage The evaluation of both CAD models and product modules is performed on two main directions: reliability and life cycle conformance. Firstly, the model is analyzed for its reliability using methods such as finite element analysis, or failure modes and effects analysis. Subsequently, a life cycle evaluation, both from economic and ecological perspectives, is performed. All these evaluations may result in proposals for changes in the design of the product. Figure 11. Concept enhancement stage 3.8. Concept validation stage The last step within the algorithm is the Validation stage and its main objective is to assure that what has been designed can be manufactured. Therefore, at this level, methods such as prototyping or rapid prototyping are advanced. Pag 18

21 Contributions regarding life cycle approaches on the development of products in collaborative environments Figure 12. Concept validation stage 3.9. Model implementation The theoretical model has not been developed to offer a generally applicable development algorithm for any organization. In developing this model, two distinct aspects were pursued: identifying and pointing out some key activities, which, once implemented could facilitate and contribute to the development of products for their life cycle; representing the theoretical model as an interactive roadmap which grants immediate access to the all the activities and the technical documentation required for performing these tasks. The philosophy implemented by this model was the right document for the right person at the right time. Starting from the assumption that within each organization that performs product development activities such algorithms are implemented, an analysis of the possibilities for implementing the theoretical model has been performed. Two implementations were considered and are shortly presented below: implementation based on commercial software (other than PLM platforms); implementation within an in-house software solution. The implementation based on commercial software has two interdependent components, namely: a file-server structure which is responsible for file and product data management; graphical representation of the development algorithm and the addition of interactivity elements. Even though it is a simple solution for implementing the concept of interactive roadmap, some limitations such as reduced flexibility, the necessity to manually create the folder structure and the file structure, and the lack of means for real-time interaction and communication between members, have lead to the orientation of research towards the second implementation solution. Pag 19

22 Cristian-Victor Codre Chapter 4. Collaborative product development 4.1. Preliminary aspects (definitions and arguments for collaborative product development) Collaborative product development represents a means by which problematic aspects of product development, such as complexity, involving as much expertise areas and knowledge as possible, shortening life span of products or rapidly changing technological challenges can be solved. A definition of the concept, from a software solution perspective, is given by (Rodriguez, et al., 2005). According to this reference, collaborative development is seen as information architecture based on the internet which allows information, knowledge and resources sharing among geographically distributed members, for supporting engineers in the process of decision making. Most of the benefits brought by collaboration can be subordinated either to the objective of business performance improvement, or to the one of increasing organization sustainability perspectives. Among the motivations that could lead towards embracing collaboration, the following can be mentioned: reducing costs; risk sharing among partners; acquiring technologies, knowledge or expertise from the partners; reducing time to market; gaining new market opportunities; achieving a competitive advantage; extending product portfolio; increasing the innovative potential; organizational culture Principles, critical success factors, risks and limitations of collaborative development Computer Sciences Corporation identifies among the basic principles of efficient and fruitful collaborations, the following (w11, 2011): eliminating duplicate efforts with respect to processes, technologies and human resource; assigning roles based on the best fit principle; creating multidisciplinary teams focused on process / product / project; extending regular communication channels; clear identification of communication protocols with the identification of processes, roles and measures; encouraging active involvement of all partners within the collaboration to improve performance, working times or to reduce costs; promoting equity among partnership members; promoting changes from the status quo within the collaboration; inspiring a collaboration culture for technological progress, tools and practices improvements. Pag 20

23 Contributions regarding life cycle approaches on the development of products in collaborative environments (Buyukozkan, et al., 2011) synthesizes the critical success factors which are most commonly mentioned within scientific articles focused on collaborative development: trust, fairness, reciprocity promoters of a long term collaboration; communication essential both at knowledge sharing level and at problem solving one; partners selection sensitive process within the collaborative entity which should not introduce any imbalance in the system. This topic is widely addressed in papers such as: (Emden, et al., 2006) or (Fraser, et al., 2003). the quality of products or services provided by each partner influences the quality of the aggregated product; commitment and involvement of each party integrated within the collaborative entity; flexibility and adaptability of the partners at the new conditions imposed by collaboration; the ability to learn from partners experience; experience in partnership management; leadership imposing, at least at an informal level, an entity with the characteristics of a leader within the collaboration; aligning at a common standard establishing a formal protocol according to which the collaborative process will take place; information sharing and security and sharing risks Technical requirements for collaborative development models The scientific literature addressed during this research proposes several collaborative development models which apply the collaboration principles mentioned in Chapter 4.2. (Rodriguez, et al., 2005) identifies the following technical requirements that, at a conceptual level, each collaborative development instrument should address: information system architecture; communication tools; virtual team management tools; product representation model; engineering applications; product geometric representation model; integration with commercial CAD/CAM/CAE software; knowledge representation model; project management tools. Figure 13 presents a synthesis of the above stated technical requirements introducing an original representation of the relationships and interactions between the enablers of collaborative product development. During the analysis, it has been noted that one way or another, each research initiative is focused on solving at a particular level different sets and configurations of these technical requirements. Some authors focus on improving engineering applications, some focus on improving product representation models while others focus on improving communication tools. Pag 21

24 Cristian-Victor Codre Figure 13. Dependencies between the nine technical characteristics of collaborative development models 4.4. Synthesis and analysis of reviewed collaborative development models (Buyukozkan, et al., 2011) performed a study, which considered 126 articles written in the past years, that are focused on collaborative product development. This analysis showed a trend in addressing mainly three major directions: the dynamics of collaborative product development; forming partnerships for collaborative product development; collaborative product development infrastructure. This part of the doctoral thesis is focused on studying and analyzing some scientific articles which propose solutions for the collaborative product development software infrastructure. The analyzed models are presented from the perspective of the nine technical requirements or enablers presented in Chapter 4.3. The purpose of synthesizing the models according to these requirements was not to create a hierarchy or a classification of them, but to study the way in which several authors solved these requirements. The detailed analysis of these models is presented in the doctoral thesis. Pag 22

25 Contributions regarding life cycle approaches on the development of products in collaborative environments Part III: Practical - collaborative product development platform Chapter - platform for collaborative product development 5.1. Requirements identification and analysis Identification of client s requirements Identifying client s requirements and technical specifications represents the result of a wide bibliographical study and the use of specific PLM platforms by the author, such as Parametric Technologies Corporation s Windchill PDMLink 9.0 (Parametric Technology Corporation, 2010) and Siemens Industry Software s Teamcenter 8 (Siemens Industry Software, 2010). The following requirements that the application should meet were identified: integration within a web application (client server application); user management capability create, edit, delete users, plus the possibility to assign roles within different projects; structuring data within a project; access should be granted only after authentication; different access levels within the application based on the user s role within the project; module for graphical representation of development algorithms; adding metadata for files and resources; document lifecycle management + identifying document s status; creating workflows for documents (responsible - approver); activity lifecycle management + identifying activity s status; uploading resources on a project and granting access to these resources only in the context of the project; check-out function for documents + document locking on the server; check-in function for the documents + document unlocking on the server; versioning system for the resources; information propagation within the application; error reporting mechanism, change proposals during development and responsible notification mechanisms; integrating a design advisor module; integrating data collection mechanisms for the downstream product life cycle stages; using open software solutions. Within the doctoral thesis all the above stated requirements are detailed and explained Client requirements analysis and the implications on functional level and on data structures The functional requirements describe the way in which the customer expects that his needs and requirements are fulfilled by the software application. The functional requirements will be the starting point in designing the application s architecture and database, influencing the type and Pag 23

26 Cristian-Victor Codre the relationships between data structures. In the doctoral thesis, each client requirement was translated into functional requirements, establishing at the same time its implication on the data structure level. For exemplification, one of the client requirements will be considered, namely the requirement for user management. The application has to be multi-user, meaning that it should allow for creating, editing or deleting users. This implies the need of creating the user interface (the web pages) that will allow the user to enter registering data. At the same time, the manager or the administrator of the platform should be granted with the possibility to delete previously registered users. At the data structure level, these requirements ask for an entity that could keep all this information. Moreover, the use of several roles within projects leads to the need of creating and saving roles in the platform. The application should grant access only for registered users based on their username and password. The functional implication of this requirement is to create the web page that will allow user s login The deployment of client requirements up to logical components level Because of the limited time available for the development of the platform, and mainly because of the increased difficulty of some customer requirements, the development methodology was guided by the deployment depicted in Figure 14. The use of this methodology offered a scientific support for focusing on those modules that have major impact in fulfilling customers requirements. The implementation of logical elements was made with consideration to the hierarchy obtained by the deployment of this methodology. In the current approach, among the logical components / elements are considered all the conceptual modules that will be integrated within the application. To be more precise, at a conceptual level, all the operations related to the management of resources within the application will be assigned to a Resources Management module. For fulfilling the functional requirements, a total of 15 logical modules were necessary. Figure 14. Methodology for the deployment of client requirements up to the logical components level Pag 24

27 Contributions regarding life cycle approaches on the development of products in collaborative environments Figure 15. Requirements analysis using AHP Figure 16. Correlations between client requirements and logical modules Pag 25

28 Cristian-Victor Codre The symmetrical matrix used in the AHP method, and the results of its application are depicted in Figure 15. The results of applying the QFD method for the correlations between each client requirement and each logical module are presented in Figure 16. By filling in the correlation matrix between client requirements and logical modules, in the end, the transfer of the importance given by the customer to the fulfilment of his requirements is transferred up to the level of logical components. The implementation of logical components was made with respect to the hierarchy obtained by using this methodology. Until the end of the doctoral stage, the implementation of each logical module has been achieved Technical solution configuration In order to facilitate collaboration between actors involved in product development, the application will be hosted on an application server (server side) and the access to this application will be made via web browsers (client side). The client-server communication will be single channel by which the server distributes requests to the modules that are responsible for their processing. After processing, the server will send the response to the client and based on this response, the client will generate the user interface. The basic structure of a client server application is given in Figure 17. Figure 17. Basic structure of client-server application The application is developed for Tomcat application server, using Java Servlet technology (Apache Software Foundation, 2011). Java Servlet is a Java program that extends the functionality of a web server, generating dynamic content and interacting with the web client via the request response mechanism. Concerning programming technologies and languages used, the Server is developed in Java programming language, while the client is developed using HTML 4 (Hypertext Markup Language), CSS 2 (Cascading Style Sheets) and JavaScript technologies to be supported by all major internet browsers available to the user. For storing data within the application, a MySQL database is used. The database will have the role of storing information regarding the current state of the application, data regarding users, information entered by the users or personal settings. Pag 26

29 Contributions regarding life cycle approaches on the development of products in collaborative environments 5.3. Application architecture Premises and representation The application architecture was designed as n-tier architecture, separating logic on three distinct layers (Figure 19): user tier or the Presentation tier. This level represents the top most level of the application, the level at which information is presented to the user within the web browser, ensuring user s communication with the application; business logic tier, which comprises, in this case, the Business tier and Data Access tier. It is the level at which the processing and the operations on data are made; data tier or the Persistence tier is the level at which database queries are performed, together with saving and modifying the data in the persistence. This level has the role to keep data neutral and independent from the business logic or the application server. By creating the data layer as an independent layer the scalability and the performances of the application are improved. In parallel with the design of application architecture, the database architecture had to be designed. The design of database architecture implies the identification of all data tables required for holding the information, together with establishing the relations and interactions between tables or their components Database architecture The database architecture was designed starting from the functional requirements for the platform, identified and detailed in Chapter 5.1. By analyzing functional requirements, the following were achieved: identification of tables necessary for supporting the application, the data types and information that these tables have to carry and the connections between components. The links between components were made using foreign keys (FK), fields of a relational table that link to the primary key (PK) of the element from the second table (W3 Consortium, 2010e). The database architecture is depicted in Figure Main components of the application Communication between client side and the application server is made via the user interface, component which is integrated into the user tier. Communication between client (user interface) and server (application server) is single channel. The entry point into the server is through the Application Controller which has the role to distribute requests to the Business Facade and to send proper responses to the user interface. Based on these responses, the content of the user interface will be generated. In the proposed architecture, the Business Facade will manage the subsystems Business Adapter and Business Controller. In the Business Adapter subsystem, the data sent in the request will be adapted to be used and processed into the Business Controller. Subsequently, the Controller will send the request to be executed by one of the Managers through the Data Access Object Facade. The application architecture components are represented in Figure 19. Pag 27

30 Cristian-Victor Codre Figure 18. Database architecture Pag 28

31 Contributions regarding life cycle approaches on the development of products in collaborative environments Figure 19. Application architecture Pag 29

32 Cristian-Victor Codre 5.4. Technical implementation Standard notations. UML diagrams For describing the implementation of application s architecture, a standardized solution in software industry was chosen, namely the Unified Modeling Language UML diagrams. UML represents an object oriented visual programming language, which describes the structural and the dynamic properties of a software system (Object Management Group, 2011). UML 2.0 defines thirteen types of diagrams, structured in three categories, as follows: structural diagrams: Class Diagram, Object Diagram, Component Diagram, Composite Structure Diagram, Package Diagram and Deployment Diagram; behaviour diagrams: Use-Case Diagram (used mainly in the needs and requirements identification process), Activity Diagram and State Machine Diagram; interaction diagrams: Sequence Diagram, Communication Diagram, Timing Diagram and Interaction Overview Diagram. For the modelling of web application structure, Class diagrams were deployed, while for modelling the interactions in time between subsystems, Sequence diagrams were used Class diagrams The class diagram is used for describing the static structure of an application, more precisely, the classes or entities of a system. Classes represent a set or a category of objects that have one or more properties in common which differentiate them from the rest of the objects. A class may have more instances, these instances representing the objects of this class. A class defines and describes the structure and the behaviour of all the objects within the class. The structure of a class comprises all the attributes of each member of the class (e.g. variables), while the behaviour includes the operations that can be performed by, or on that particular class. These operations are more widely referred to as methods Sequence diagrams The UML sequence diagrams are included in the interaction diagrams and are usually used for representing or modelling the messages, actions or events flow between several components or objects of a system. Time is represented vertically illustrating the sequence of interactions between the main elements of the system which are represented horizontally on the top of the diagram (w4, 2009). The sequence diagrams are mainly used for designing, documenting or validating the architecture, interfaces and system s logic by describing the sequence of activities that need to be performed for fulfilling a scenario. UML sequence diagrams prove to be very useful for understanding the dynamic behaviour of a system, behaviour which is difficult to foresee by analyzing static diagrams (i.e. class diagrams) Development of server application The entry point within the application, the equivalent of the Application Controller in Figure 19, is represented by the Controller Servlet. ManagerFactory class plays the role of Business Facade, managing all the Managers, Adapters and Controllers used for fulfilling the Pag 30

33 Contributions regarding life cycle approaches on the development of products in collaborative environments functionality of the application. Because of the high number of Managers, each having Adapters and Controllers associated, the high level interfaces IAdapter, IController and furthermore AController were created. Figure 20. Architecture implementation through Java classes Data Access Object Facade is represented by DAOManager which handle all Managers used in the application. It can be noticed from the attributes definition that these attributes are declared as interfaces in order to keep a high level of generalization (Figure 20) Application end points The main entry point in the application is the ControllerServlet which is the only communication point between the client and application s logic. This Java class extends the functionality of HttpServlet class for the package javax.servlet. The javax.servlet package offers to programmers the required classes and interfaces for creating servlets. The methods within HttpServlet class, which manage the interaction with the client, have two arguments: HttpServletRequest, which holds the request from the client; HttpServletResponse, which holds the response from the client. The life cycle of a request in ControllerServlet is: client raw data adapter adapted data controller result client Pag 31

34 Cristian-Victor Codre The proper functioning of the ControllerServlet is based on two command parameters which are extracted from the request, namely: manager and method. Each request from the client has to have at least these two parameters. Based on the manager parameter, the ManagerFactory class will call the appropriate Manager for performing the required action. Based on the method parameter, the appropriate method will be called to perform data processing. An exemplification of a client s request with the two parameters is given bellow: /proddev/controller?manager=flowmanager&method=1 Information send as multipart data is interpreted via two upload Servlets. The UploadServlet class is a Java class that extends the functionality of the HttpServlet class, overwriting the doget and dopost methods of this class. This Servlet has the following functions: it allows uploading resources on the project; it allows adding metadata for the uploaded resource; it allows downloading resources from the project; it manages the versioning control mechanism for the uploaded resources (by adding the version and the project id to the file name on the server not visible for user); it blocks the resource on the server in case that this resource was downloaded by a user. For those cases in which the upload of other types of files is required (e.g. attachments which come with customer complaints or suggestions, auxiliary documents), files that are not under versioning control mechanism and should not be available for the check-out check-in mechanism, another upload servlet will be used. In this case the CommonsFileUploadServlet will be deployed, a class that also extends HttpServlet class and allows for files to be uploaded in several locations within the application and to be downloaded where needed Business logic Each business module (logic element) within the application will be executed by a specific Manager. For the proper interpretation of the raw data, each Manager has associated one Adapter, while for the processing of data each Manager has associated one Controller. Based on the manager parameter, received from ControllerServlet, ManagerFactory instantiates that Adapter, and that Controller which are assigned to the Manager. All the Adapters and all the Controllers have to be registered within the ManagerFactory class. According to the Separation of Concerns principle, ManagerFactory has knowledge of all Manager types, but no further knowledge of their functionality. The business logic layer was designed based on a plugin architecture in order to support the extensibility and the scalability of the application. The plugin type of architecture is obtained by implementing the following principles: all Adapter and Controller logic implements the same interface; the parameters and the returned data have the most generic type of data (Object class); a business component does not know the functionality of other business components; each business component uses an API for accessing data. Pag 32

35 Contributions regarding life cycle approaches on the development of products in collaborative environments All the Adapters used in the application implement the IAdapter interface which defines the method: public interface IAdapter { } Object adapt(int command, Map<String, Object> dataobject); As for the Controllers used in the application, they all extend the AController class, which at the same time implements the IController interface. The IController interface defines the following method public interface IController { } Object execute(int command, Object data); which allows the execution of the business logic based on the method command parameter and on the adapted data received from the Adapter. The result returned by this method is of Object type. Both the return type and the argument received by the method are of type Object in order to extend the applicability of this method for any situation Data access layer Figure 21. Application Managers Pag 33

36 Cristian-Victor Codre This level comprises all the methods which manage the access to the data source of the application. In the current implementation, this layer supports the access to a relational database (a MySql one) by integrating the Hibernate framework which, based on a MySql connector, supports the access to the database. The access to the database is granted through the DAOManager class which offers the access to the implementations of all the objects that access the database. The access to these implementations is possible via interfaces. In these interfaces, the methods which operate on data stored into the database are declared (e.g. persist, query, edit, update, delete). The Manager structure of the application is depicted in Figure 21. It can be noted that all the Managers implement interfaces through which all the methods that access the database are declared Development of client application The client application was developed in Eclipse programming environment, using JSP (JavaServer Pages) technology. The JSP technology is a Java technology that allows the creation of dynamic web pages, based on HTML, and by adding scripts of Java and JavaScript. For improving the graphical aspect of elements, CSS is used. JSP technology uses XML-like tags which encapsulate the code responsible for generating the content of the web page. This technology is an extension of the JavaServlet technology and enables rapid development of web-based applications that are server- and platform-independent (Oracle, 2011b). For the development of client side, more than 100.jsp files were needed, together with styling files.css, personal JavaScripting files or JavaScript libraries. The files created by the author sum more than lines of coding. The following figures will selectively present the developed web pages available for the users platform. Figure 22. Platform login Pag 34

37 Contributions regarding life cycle approaches on the development of products in collaborative environments Figure 23. User s control window For registering users in the platform (Figure 22), two distinct options are proposed: the user is part of the product development team, or the user is only a guest within the platform and his access to information will be therefore limited. The access in the platform is granted only to registered users. The successful authentication of a user leads him to the user s control page (Figure 23). With the help of this page, the user has fast access to creating a new project, opening a project in which he is a member, or visualizing all projects in which he has a role, together with their timelines and his particular role within the project. Figure 24 presents the user interface for creating a new project, through which both information about the project and the project team are set. Figure 24. Creating a New project Pag 35

38 Cristian-Victor Codre Figure 25. User s access to his current projects If a project was previously created, the user has two options for accessing it (Figure 25): the Open project option, or the My projects option. For navigating through a project, a tab based menu was deployed. Each tab offers access to several functions or submenus of the application. The workspace for a project is presented in Figure 26. The upper part of the menu is tab based and it is structured in 12 main tabs which further grant access to contextual submenus. Figure 26. Tab menu of the application Pag 36

39 Contributions regarding life cycle approaches on the development of products in collaborative environments Figure 27. Graphical representation of the development algorithms Figure 27 presents the tool for graphical representation of the development algorithms. The page is divided into two distinct areas, namely the command zone and the canvas zone for representing the algorithm. Figure 28 present the page for the management of activities within a project, structured into two tables: a To do table with all the activities that the user is responsible for, and a To review table with all the activities that the user has to approve. Figure 28. Project activities tab Pag 37

40 Cristian-Victor Codre Figure 29. Examples of workspaces for the activity responsible Figure 30. Examples of workspaces for the activity approver Pag 38

41 Contributions regarding life cycle approaches on the development of products in collaborative environments Figure 31. Project resources administration and management Figure 29 and Figure 30 present examples of workspaces for the users responsible for one activity, respectively for the activity approvers. Figure 31 illustrates the menu through which the resources uploaded in the context of a project can be managed. Figure 32 depicts the development team information page through which the manager can reassign roles or can add or delete members on a project. Figure 32. Development team management Pag 39

42 Cristian-Victor Codre Figure 33. Synchronous communication through the OpenRoom tab The synchronous communication between team members is possible through the Open Room menu (Figure 33). This functionality was designed as an open space in which all team members can use the real-time communication facility. Two different communication options are provided by using this menu: real-time messages exchange (chat functionality); exchange of opinions based on the 3D object representation of a discussed part. This representation uses the VRLM (Virtual Reality Modeling Language) standard and for the correct visualization of these files into a web browser, a plugin is required (i.e. Cosmo Player VRML Plugin). Figure 34. Life cycle data management Pag 40

43 Contributions regarding life cycle approaches on the development of products in collaborative environments The platform supports life cycle approaches in product development. This implies that the information generated for and by the product throughout its life cycle has to be managed in the context of the same development project. With this respect, the platform proposes the use of the Product follow-up menu which allows for the management of information from life cycle stages such as Production, Utilization, Support or Retirement. For collecting real data from users, from the real usage environment of the product, the end user is integrated in the platform (Figure 35). The information provided by the user is immediately available for the development team by accessing the Product follow-up menu. Figure 35. Integration of field data within the application Pag 41

44 Cristian-Victor Codre Execution sequence for an action The application was designed in such a manner that all the actions follow the same pattern. The sequence of the instructions in time, together with their interactions, is represented using sequence diagrams, as described in Chapter For exemplification purposes, and for a better understanding of the client-server communication and of the sequence of instructions into the server application, the login command was chosen. The sequence diagram corresponding to this action is depicted in Figure 36. Figure 36. Sequence diagram for the login instruction 5.5. Benefits and advantages The platform is developed as a web application having integrated several tools specific to competitive engineering. This application runs on an application server and can be accessed via web browsers, eliminating the need to install auxiliary software on the users local machine. Being a platform that facilitates collaborative product development, among the major benefits that can be noted is the support of collaboration between geographically distributed team members, granting the access to all interested parties to the same versions of the documents. The immediate access to the relevant data is vital in the process of decision making. The application allows for the creation of mixed development teams. These teams can be crossdepartmental, cross-organizational, and especially geographically distributed, being focused on Pag 42