Keywords: Aide à la Décision, Gestion de Projet, Ingénierie Système

The ISI team stands in the context of design of complex systems, which can be components of bigger systems in embedded application in the fields of aeronautics, automotive and railway industry, and microsystems. The ISI team contributions aim to make easier the design of complex systems by improving development life-cycle processes, particularly requirement management, modeling, model integration, verification and validation, simulation and virtual prototyping, in a process, method and tool vision. This thesis was taken out in the background of requirement of integration of Systems Engineering (SE), Project Management (PM) and Decision Making (DM) in the context of Collaboration Engineering.

 define the project management team and the systems engineering technical team, some use the terms of project and product domains (Sharon, de Weck, et Dori 2011), but they all refer to the systems engineering and project management domains. With the growing scale of projects, the roles of the project managers and systems engineers became more critical. However, for many years, a cultural barrier has been growing between practitioners of systems engineering and of program management. While project management has overall project accountability and systems engineering has accountability for the technical and systems elements of the project, some systems engineers and project managers have developed the mindset that their work activities are separate from each other rather than part of an organic whole. Consequently, work often costs more, takes longer, and provides a suboptimal solution for the customer or end user.

) (Conforto et al. 2013) pointed out that there are barriers, or at least a lack of coordination, between the different stakeholders of the project, for example between the systems engineers and project managers. The bigger the enterprise is, the more difficult it is to collaborate. The situation thus seems to be easier on that point for small and medium enterprises (SMEs) where the

IV

Comparison of the PM references VI Assessment of the Project Progress et les managers et leur importance est décidée collaborativement à l'aide d'une méthode multicritère d'aide à la décision (AHP). Ensuite, sur la base des valeurs des indicateurs, les méthodes du chemin critique (CPM) et de gestion adaptative de la valeur acquise (EVM) sont utilisées pour évaluer l'avancement du projet et du développement du système. Quatre indices sont ainsi définis pour supporter le processus de prise de décision tout au long du projet afin de permettre la prise de décisions collaborative et de rendre celle-ci plus rationnelle.

my thesis, they not only guide my research but also help me when I have difficulties in life. They are like my parents in France. They not only help me on the research by their profound knowledge on research, but also show me the cautious attitude on how to do research. They are always there when I need helps. I also want to thank Daniel Esteve and Michel Malbert who both work on a project related to my thesis.

I would like to express my regards and gratitude to my colleges and my best friends at the LAAS.

They are Nadia Chaabane, Panwadee Tangpattanakul, Ning Ge, Pierre-Alain Bourdil, Yun He, Leticia Gloria Vargas Suarez, He Huang, Zukun Qu, Ran Zhao and NingYing He and so on. They are always available to share my happiness and trouble. They always give me their encourage and advises. I would like to thank my best secretary Christèle Mouclier. I always bring many problems to her and she is always so patient and responsible.

I would like to thank my colleges at LAAS: Romaric Guillerm, Vikas Shukla, Damien Foures, Li Zheng, Min Zhou, Jia Luo, Vincent Albert, Clement Foucher, Jean-Claude Pascal and Hamid Demmou.

You are always helpful.

I would like to thank the members of my jury of the defense: Professor Benoit Eynard, Professor Jian-Bo Yang and Professor Eric Bonjour for their valuable, recommendations, insights and feedbacks.

Their comments helped me to improve the quality of my thesis; they also gave me advises for the future research.

I would to thank to the CSC who provide me the opportunity for doing my thesis in France. I would like to thank all my chinese and french friends in Toulouse. They are always available when I need helps and when I want to share happiness. I got so many helps from them and I will never forget.

I want to thank LiNa Dang, my best friend and sister, she is always ready to listen and help me even she is in China and even I wake up her in the midnight.

Lastly, I would like to give my most gratitude to my parents; they always stand by me and give me the strongest support. They are always proud of me. Even they do not have more study; they always set a good example to show me the positive attitude towards life. I also want to thank to my husband Yu

Figure VI-1

The location of the AHP method in the scientific debate [START_REF] Brunelli | Fair Consistency Evaluation in Fuzzy Preference Relations and in AHP[END_REF] .

List of Figures

List of Tables

List of Tables

Table II- systems engineer often also plays the role of the project manager. However, SMEs have other difficulties such as having human resources or tools to manage projects efficiently. So how to remove the barriers between different teams, practices and knowledges is a critical factor to ensure the success of the project and improve the competitive ability of companies. This work aims at analyzing practices in SE and PM to better align them in order to promote the chances of success of projects. It presents a method and specifies a reasoned and objective decision-support mechanism, based on a better internal cooperation in the company between product and project considerations, to enable decisional stakeholders to track the execution and monitor the evolution of a systems engineering project.

This thesis lays at the intersection of many disciplines, SE, PM, and Decision Making (DM) support, to promote the collaborative development of multi-technologies systems. Our first focus addresses the harmonization of the descriptions of project management and systems engineering processes described in international standards or guides, to elaborate a framework of fundamental and aligned processes to support SE management that can be adapted to use by businesses with different profiles (SMEs, middle-market companies or large groups). For this, we compare the five important systems engineering standards and guides (ANSI/EIA 632, ISO/IEC 15288, IEEE 1220, INCOSE SE HANDBOOK and SEBoK) and the two significant project management standards and guides (PMBoK and ISO 21500) in order to evaluate the coherency of standards with regard to the processes they describe and that are involved through the whole project in order to facilitate the management of the projects and improve their chances of success. Beyond an integration of the practices by the use of this framework, we also intend to facilitate cooperation between systems engineers and project managers by offering them a set of core indicators that they could share and rely on for collaborative decision to monitor the projects. Indicators are valued both by the systems engineers and project managers by using the Analytic Hierarchy Process (AHP) method. Then based on the indicators' values, the Critical Path Method (CPM) and adaptive Earned Value Management (EVM) methods are used to evaluate the progress of both the project and the product development. Based on the EVM method, we define four indexes: PcEPI, PcAPI, PjEPI and PjAPI. All the four indexes analyze the progress of the processes and the projects by the collaborative views of systems engineers and project managers, and these values will be used to feed back into the decision-making process during the management and will help to make collaborative decision more rational.

Our proposal therefore aims at the research for an improved collaboration and coordination of decision-making from Systems Engineering and Project Management, and with three contributions 1) Using a framework of coherent processes from SE and PM standards and guides to align practices, 2) Defining a set of core indicators based on these processes from SE and PM domains, 3) Applying a This thesis is organized as follows: after an introduction given in this chapter, the context and problem formulation of our work will be introduced in the chapter II. Chapter II will also present the state of the art on this problem and introduce our objectives and how we proceed to research them.

Chapter III introduces and compares the five main systems engineering references and discusses what would be the different proposals to best align processes: a multi-standard approach or the choice of the most "alignable" reference, on the basis of the comparison of SE standards relatively to a set of PM criteria. Chapter IV introduces and compares the two main project management references, this analysis lead us to select two candidates, ISO/IEC 15288 for SE and PMBoK for PM, to pursue the study. Chapter V considers the alignment of these references and proposes a set of processes at the intersection of them. How to relay on these processes to define and manipulate indicators to support decision constitutes the proposal of Chapter VI. We synthetize our contributions and give some perspectives of our work in chapter VII. The organization of this thesis is as shown in Figure I-2. In this chapter, we would like to present the general context, state of the art and proposal methodology of this thesis, which can help to clarify the current states, locate the PhD thesis in the correct context and have a global view of our work. Section II.2 will introduce the context of the problem and our objectives in detailed. The state of the art of this thesis will be provided in section II.3. This section presents the recent related work of this thesis. The presentation of the domains and concepts involved of this thesis will be given in section II.4. Section II.5 will detail our proposal methodology. We will give a short conclusion of this chapter in section II.6.

II.2. Context

Nowadays in the highly competitive industrial environment, many companies find it difficult to meet new market requirements in terms of shortening design, manufacturing high quality products, fabricating with low costs, and delivering the product on time. In order to cope with competition, these companies are forced to manage their product development cycles and capitalize on their expertise. It is often found that company organization leads to segregation between PM and SE, with the result that decision-making is sometimes misguided and may compromise project execution, whereas, although they each have specific visions and targets, these disciplines are nonetheless intended to serve a common objective, which is to satisfy the customer (Conforto et al. 2013). These difficulties then impact the slow processing multitudes of requests for changes that characterize the creative activity which should lead to finding new solutions in constrained spaces while respecting the expected performance of the system. These performances are also a particular analysis of the collaborative decision making during the selection of design, industrialization and supervision systems.

With the increasing complexity of products and the generalization of extended enterprises, we note a growing difficulty for engineers, managers, towards more generalization for all project stakeholders, to work collaboratively. And in many companies and organizations, engineers and managers focus on a project just through their own views; they give the solutions just based on their own business domains.

In fact, the goal of SE and PM should be the same: to ensure the project's success. Intuitively, they also present similarities: managing all stakeholders' needs by designing a customized solution (e.g., schedule, financial plan, functional architecture, verification plan, and package), drawing up a plan or architecture to create the project or product, accounting for scope, time, risk, quality and human resources. Of course, SE focuses on the engineering of systems, considering the technical processes into details, together with the verification and validation processes and production processes, while PM focuses on the management of the project (planning, resources allocation, time control). The former requires sophisticated technical skills, and the latter outstanding managerial skills.

In practice, they are often treated separately (see However, obvious overlaps exist between domains, in particular between the scope of Systems Engineering, as described in the SEBoK Guide or CMMI [START_REF] Pyster | Systems Approach Applied to Engineered Systems[END_REF], and the scope of Project Management, as described in the PMBoK (PMI 2013). There are some barriers between the project manager and systems engineer when it comes to implementing the project because they understand the project from their own perspective and knowledge fields (Conforto et al. 2013) [START_REF] Langley | Toward a New Mindset: Bridging the Gap Between Program Management and Systems Engineering[END_REF]. As shown in Figure II-1, the program manager uses the project management processes and the systems engineer makes use of the systems engineering processes to achieve the goal during the whole project. But there are also some intersecting processes between both domains. For example, life cycle planning, business case analysis and quality assurances are considered in both SE and PM domains (see Figure . A first point to understand is that, in the SE approach, the project is a system that applies all the principles of SE: it has a purpose, interacts with an environment, represents a solution of stakeholders' requirements and this is often achieved by engineering a trade-off between requirements that may not always converge [START_REF] Fiorèse | Découvrir et comprendre l'ingénierie système[END_REF]. In summary, SE can be either applied to the system to be developed (technical system) or to the system that manages development (organizational system) (see Figure . Thus, as there is no standard or explicit connection between SE and PM, it is necessary for the systems engineers and project managers to realize the existence of close relationships between SE and PM domains and to integrate them during the assessment of project progress in order to achieve the success of the project.

SEBoK and PMBoK both describe the importance of understanding the scope of the work at hand, how to plan for critical activities, how to manage efforts while reducing risk, and how to successfully deliver value to a customer. The systems engineer working on a project will plan, monitor, address risk, and deliver the technical aspects of the project, while the project manager is concerned with the similar types of activities for the overall project. Because of these shared concerns, confusion and tension may arise from time to time between the roles of the project manager and the systems engineer on a given project. A recent survey tackled the question and pointed out the importance of aligning SE with PM, in order to reduce this unproductive tension (Conforto et al. 2013).

PM and SE practices and tools currently coexist uncomfortably in today's economic environment.

The coordination of practices in engineering projects is thus one way of improving the competitiveness of companies (Xue et al., 2014), on the basis of:

-The acceleration and optimization of the development process, from design to prototyping, and even beyond, in the exploitation phases (Jakjoud et al. 2014),

-The control of projects by a genuine coordination of stakeholders and of the processes deployed for this development (Jakjoud et al. 2014),

-Collective decision making, based on analyses and predictions, to improve operational efficiency, thus limiting the share of emotive elements in decisions, reducing errors and deviations, uniting and motivating the players, who better understand the meaning of each decision (Imoussaten, Montmain, et Mauris 2014).

The problem that we address in this thesis is that of collaborative management through all the project life cycle for developing multi-technological systems, thus involving several technical teams and integrating all the stakeholders in the project, to ensure that all are on track to produce the "right product", while controlling costs and respecting deadlines (Xue, Baron, et Esteban 2014). There is currently a range of approaches and standards and guides (SEBoK (BKCASE 2015) for SE and PMBoK (PMI 2013) for PM, among others), but these are often too abstract or too complex in their description to be easily applicable, especially by SMEs and middle-market companies [START_REF] Blanchard | Systems engineering and analysis[END_REF] An introduction to the related domains will be given in section II.4.

II.3. State of the art

In today's environment, there is an ever-increasing need to develop and produce systems that are robust, reliable, high quality, supportable, cost-effective, and that meets the needs of the end user. With the systems increasing complexity, it becomes ever more important to apply and to manage SE. In any project, it is critical that systems engineering be performed during all life cycle phases and half of all project failures could be prevented by more effective systems engineering (INCOSEUK 2009). In 2013, the Standish Group did research based on approximately 50,000 project references in Information Technology in the United States (60 percent), Europe (25 percent) and the rest of the world (15 percent). The results showed a project success rate in 2012 of 39 percent (delivered on time, on budget, with required features and functions); 43 percent of all projects were challenged (late, over budget, and/or with less than the required features and functions); while 18 percent were discontinued being delivered but never used (Standish Group International 2013). The success rate could be increased by a number of improved factors: methods, skills, optimization, teamwork and so on and so forth [START_REF] Boucher | Formalisation and use of competencies for industrial performance optimisation: A survey[END_REF]. Overall, the obvious conclusion is that practices have to be improved but efficiently managing the project is also critical for its success. Indeed, only 20 percent of all projects achieve the expected results in terms of quality, costs and deadlines due to faltering project management (Standish Group International 2013), while one-fifth of the world's GDP has been earmarked for project management each year in the decade 2010-2020 (McKinsey Global Institute 2013)! Regarding these figures, the implementation of SE and PM during the whole project is definitely necessary to meet the requirements of both system and project.

In a very empirical approach, companies, including the major groups, have each built various tools either for design or for project monitoring, which a gradually improved performance, but no tool offers an integrated vision of both sides. Thus, we find tools such as "Cockpit", dedicated to the management of requirements and of risk but not taking the project aspect into consideration, ENOVIA, which focuses on product and program planning in the context of a distributed company but does not offer any decision support, or "Unified Planning", which helps with the synchronization of all of the activities of a project involving various stakeholders, but does not include the product dimension [START_REF] Baron | Specifications of a method and tool to support the management of systems engineering projects[END_REF]. The concept of the Project Management Officer (PMO) does not include specific tools and, most of the time, leads to the suggestion of developing a specific adaptation based on the Enterprise Resource Planning (ERP) software. Indeed, if we look at the projects carried out in this area, most are dedicated to certain areas such as construction (COMIS, VBD, CANOPEE, MEFISTO) and digital engineering, especially networks (CBOD, DOKKA, OPIMPUC, COCORAM, MODECOL, Spacify, PI-NUTS). We note that there are few works concerning this integration of these two domains.

The engineering of technical systems and indeed these projects are concentrated on certain aspects such as performance in terms of security (BioPriv, IMOFIS, VACSIM), energy production (CHWWEPS, INTENSE, OMEGA) or even mechanics (IPPOP). Some studies have been carried out for the development or the combination of techniques for systems engineering, such as, the comparative studies of production factors between Germany and France (COMPNASTA project) or the LARIOPAC laboratory, to look at the issues regarding cutting techniques. However, we observe several studies on the development of design platforms of digital software (MyCitizSpace, FORMOSE) [START_REF] Sahraoui | Processes for Engineering a System an Introduction to Processes, Methods and Tools[END_REF]).

As a result, our industrial partners have underlined several shortcomings in their project management (Decways 2011):

-Difficulties in assessing the actual state of project progress, but especially in identifying, diagnosing or anticipating management weaknesses or errors which have led to deviations observed in the way the project proceeds, -A lack of responsiveness: deviations are only detected belatedly, meaning that they can only be dealt with after many discussions and meetings, whose number is proportional to the complexity of the product and can even lead to the blocking of the project itself, -A lack of coordination procedures, insufficient traceability of intermediate decisions, and of justifications that are classified and retrievable (Cleland-Huang, Chang et Christensen 2003),

-A problem of interoperability of methods and tools, both within the company and with outside organizations (consultants, suppliers, subcontractors, contracting authorities, partners).

However, in the development of complex systems, the challenge is to find the right balance between cost, time and performance, with performance including the economic, social and environmental aspects. The engineer is traditionally in charge of technical performance while the manager is responsible for costs, deadlines and the impact indicators that need to be monitored in the context of corporate social responsibility. It is essential that each understands the impact of his/her decisions on the other, in order to keep potential cost overruns under control, for example and, beyond this, to be able to optimize these costs. Considering that the costs are most strongly affected by system design and performance, there are many sources of conflicts of interest between the engineer and the manager, directly affecting the deadlines for delivery of the system and the project's profitability.

All these operational difficulties explain why important progress in project management performance and product quality can be achieved by improving these procedures. It will therefore require many innovations to fully implement all the recommendations of the engineering of systems and the relevant parts of the PMBoK (for instance), and to perfect their coordination: the reflection of this thesis is based on the observed need to harmonize the approaches, and especially to bring them closer together (which is an opinion increasingly shared by many even within the learned societies of the sectors mentioned), and by the identification of certain weak points already discussed extensively (requirements, indicators, diagnosis and decisions, interoperability). The situation can be very different in SMEs: technologies are more specialized and projects are less complex. Accordingly, the methodological requirements and the tools are more adapted to the compatibility needed for communicating with the environment, especially partners and customers, and to simplicity of use. This simplicity requirement is essential because it allows rapid assimilation of procedures and easier communication between all the actors.

Several arguments have been advanced to encourage new research on this topic (Frédéric Demoly et al. 2012a) [START_REF] Nowak | Towards a design process model enabling the integration of product, process and organization[END_REF]) [START_REF] Avila | Understanding and classifying information system alignment approaches[END_REF]. Today we benefit from feedback from various sources on the key factors for successfully carrying through a system engineering project (Vervier et al. 2015) (Coulibaly, Mutel, et Ait-Kadi 2007). These factors include the taking into account the expectations and requirements of the critical stakeholders, a commitment and regular participation by senior management, work organization that is collaborative, multidisciplinary and concurrent and decision-making based on evidence and on an estimate of the risk (Labrousse, Bernard et Véron 2003).

Integrating systems engineering and project management has only been paid more attention in the beginning of 21th Century. The point is that, depending on the environment and organization, the two disciplines can be disjoint, partially intersecting, or one can be seen as a subset of the other. Sharon put forward that systems engineering involves product domain and project management involves project domain (Sharon, de Weck, et Dori 2011). However these constitute two complementary facets of systems engineering management. Howard Eisner in (Howard 1997) not only defines and describes the essentials of project and systems engineering management but shows the critical relationship and interconnection between project management and systems engineering, to enable both engineers and project managers to understand their roles and to collaborate.

At the normative level, in order to help organizations overcome the resultant inefficiencies of noncollaborative practices, the Project Management Institute (PMI) and the International Council on Systems Engineering (INCOSE) both recognized the importance of integration of SE and PM and announced in 2011 a strategic alliance that will enhance overall program success through the improved integration of practices between their professional communities. This way, in January 2011, INCOSE and PMI agreed to take out a project to help the organizations to reduce project risk and improve the probability of project success. They pointed out that the integration of SE and PM can help the systems engineers and project managers to overcome barriers between them, because they usually just focus on their own domains, their work being generally separated from each other in the company.

In The fourth option integrates the roles of systems engineers and program managers (due to major overlaps between them) and promotes sharing responsibility for risk management, quality, and lifecycle planning and external suppliers. Indeed, between the project manager and the systems engineer the technical and managerial leadership of a project is fully covered, requiring thus that the company of each project manager and system engineer works out the particular details in their own context.

Based on the joint research of MIT, PMI and INCOSE Community of Practice on Lean in Program

Management between January 2011 and March 2012, a guide to help systems engineers and project managers improve the performance of their programs [START_REF] Oehmen | The guide to lean enablers for managing engineering programs[END_REF]) was published in May 2012. The third section deals with "integrating project management and systems engineering". It introduces some major definitions from both domains and indicates some directions for a better integration of PM and SE. Also proposed are 10 challenges for engineering program management and how to overcome the barriers between the SE and PM.

II.4. Domains and concepts involved

In this work, two main disciplines are involved: SE and PM. This section gives an overview of these domains and introduces the main related concepts: Systems Engineering and Systems

Engineering Management, Project Management, Project Assessment and Collaborative Engineering.

II.4.1. Systems Engineering and Systems Engineering Management

System

If we want to introduce systems engineering, let us first give the definition of a system. Among the large range of definitions that can be found in literature, for example, Bertalanffy defines a system as "a set of elements and a set of inter-relationships between the elements such that they form a bounded whole relative to the elements around them" [START_REF] Bertalanffy | General system theory: Foundations, development, applications[END_REF]). While many definitions of the word "system" exist, nowadays, the word "system" is more and more frequently used, in different domains, to refer to a software system, a physical system, a social system, an economic system, etc. The word "system" becomes a common word and has a very broad meaning. Many organizations give the different definitions of "system" according to the different focus of the standards. The ANSI/EIA 632 gave the earliest definition of system; this definition is very short, clear and informative. It points the components and the purpose of the system: a system is "An aggregation of end products and enabling products to achieve a given purpose" (ANSI/EIA 632). Let us mention here below three other definitions from SE standards and guides.

Definition: A set or arrangement of elements [people, products (hardware and software) and processes (facilities, equipment, material, and procedures)] that are related, and whose behavior satisfies operational needs and provides for the life cycle sustainment of the products (IEEE 1220).

Definition: Combination of interacting elements organized to achieve one or more stated purposes (ISO/IEC 15288).

Definition: An integrated set of elements, subsystems, or assemblies that accomplish a defined objective. These elements include products (hardware, software, and firmware), processes, people, information, techniques, facilities, services, and other support elements (INCOSE 2010).

As conclusion, even in the field of systems engineering, many definitions of what is a system can be found [ANSI/EIA 632, IEEE 1220, ISO/IEC 15288, INCOSE Systems Engineering HANDBOOK…]. In this context, the word 'system' is not only related to the notion of technical system; it is an integrated set of interacted and organized elements (people or human skills, resources and hardware and software products) and related processes [START_REF] Fiorèse | Découvrir et comprendre l'ingénierie système[END_REF]. The 'complex' nature of the systems is the result of their evolutionary functional features, of the large number of their constitutive elements, the multiple interactions they are involved in, a multifaceted environment they depend upon, their distribution in physical and conceptual space and so on (Leonard 1999).

Systems Engineering

Based on the emergence of the concept of system, Schlager [START_REF] Schlager | Systenas Engineering-Key to Modern Development[END_REF]

Software Engineering

The

Definition:

The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software (IEEE 1990).

There is no unique definition of software engineering, and we can find software engineering everywhere, for instance, in the aircrafts, bus, telephones and internet.

Systems Engineering Management

Todays, companies are given the responsibility for designing, building, operating and enhancing large complex and highly integrated systems. But many people note that projects have difficulties in delivering solutions on time, on budget and satisfying the end user needs. The greater the problem complexity, solution complexity, problem novelty, solution novelty and diversity of stakeholders, the greater the challenge has proven to be. As Leonard pointed out that the systems engineering management integrates three major activities: development phasing, systems engineering process and life cycle integration (see Figure II-7) (Leonard 1999). All three activities are necessary to achieve a proper management of the system development effort.

As Figure II-7 shows, managing SE not only means managing the SE processes but also managing the system life cycle and the project lifecycle. The systems engineering management aims to help companies plan, manage, control and support the development of acquisitions of any type of products.

This knowledge can not only be used by the project managers, but also by the project sponsors, systems engineers, engineering managers, etc. It stands at the intersection of systems engineering, project management, product lifecycle management and decision making.

II.4.2. Project Management

This section introduces the useful terminology about project management, program management, project life cycle and product lifecycle management (PLM) that are related with this thesis.

Project management

The emergence of project management is related with the civil engineering projects. Until 1900 civil engineering projects were generally managed by creative architects, engineers, and master builders themselves. It was in the 1950s that organizations started to systematically apply project management tools and techniques to complex engineering projects [START_REF] Kwak | A brief history of Project Management. The story of managing projects[END_REF]. Project Management thus became recognized as a distinct discipline arising from the management domain with engineering model [START_REF] Cleland | Global Project Management Handbook: Planning, Organizing and Controlling International Projects[END_REF]. In 1969, the Project Management Institute (PMI) was set up in the USA. Project management is thus defined as "the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements" (PMI 2103). It includes the processes and activities of planning, organizing, motivating, and controlling resources to achieve specific goals.

According to the PMBoK, "A project is defined as a temporary endeavor designed to produce a unique product, service or result with a defined beginning and end (usually time-constrained, and often constrained by funding or deliverables), undertaken to meet unique goals and objectives typically to bring about beneficial change or added value" (PMI 2013).

Project management thus covers all the activities of project guidance and administration for achieving the intended outcome and delivering the expected result, under constraints of quality, time and resources. Project guidance sets the goals of the project, the organization and the strategy to be implemented to achieve them, structures the processes and sets up the tools for guidance and collaboration. Project administration follows the operational progress of the project and reports on its progress to the project managers; it highlights discrepancies, analyses risks, issues alerts and requests decisions. Leading a complex project is therefore a highly interdisciplinary and difficult activity, which has led, among other things, to publication by the Project Management Institute (PMI) of the "Project Management Body of Knowledge" (PMBoK) guide, which identifies the phases and players, and suggests good project management practices. In the context of engineering projects for technical systems, project management attempts to manage, in a coordinated and quasi-optimal manner, all of the skills teams, whether in-house or sub-contracted, within a framework constrained by parameters relating not only to the management of the project but also to the technical system itself. In addition, to ensure that such a project is run correctly, it is essential to decompartmentalize the activities of the different business teams within the company, in particular the non-technical functions, related to project management, corporate strategy and promotion of the resulting product on the market, and the technical functions, related to system design and its implementation [START_REF] Hlaoittinun | A multidisciplinary team building method based on competency modelling in design project management[END_REF]. The goal is to allow sharing points of view, improving the decisions concerning project management and the elaboration of the technical solution.

As a synthesis, the first challenge of project management is to achieve all of the project goals and objectives while honoring the preconceived constraints: scope, time, quality and budget. The secondand more ambitious-challenge is to optimize the allocation of necessary inputs and integrate them to meet pre-defined objectives (PMI 2013) (INCOSEUK 2009). With the increasing scale of projects, it has been important to offer a set of best practices to project managers to improve the chance of success of project. It thus became a stake for institutions to provide companies with standards and guides to manage their projects. This way, the PMI first published "A Guide to the Project Management Body of Knowledge" (PMBoK), which described project management practices that were common to "most projects, most of the time" in 1996. The ISO also realized the importance of project management guide and published a project management standard ISO 21500 in 2012. Chapter IV introduces those standards and guides. There are many similar and related disciplines of project management, such as program management, project lifecycle management or product lifecycle and others.

Program management

With systems, products and projects expanding in scale, another word is used to describe a set of related project called "program". The PMI defines the program management as "a group of related projects managed in a coordinated way to secure benefits and control which could not be achieved individually" [START_REF] Phillips | PMP® Project Management Professional Study Guide[END_REF]. Program management corresponds to the centralized coordinated management of a program to achieve the program's strategic benefits and objectives. Comparing with project management, the main one is that project managers manage projects and program managers manage a portfolio of projects. Normally, a program spans longer time than a project; the project managers need not to responsible for delivering quarterly results, but the program managers need to do.

The main different tasks between the project managers and program managers are as shown in Table II-1. Another important program management reference is Prince 2 which is a process-driven method (PMI 2013). The ISO 21504:2015 is another program management standard which is being developed by the ISO right now. With respect to the definitions of project management and program management, the program management naturally complies with the project management, so we decided to align the project management with the systems engineering rather than program management in this thesis.

Project Life cycle

According to the PMBoK, "A project life cycle is the series of phases that a project passes through from its initiation to its closure". The phase is a set of activities that culminates in the completion of one or more deliverables" (PMI 2013).

A project can have a number of phases; it depends on its size and its complexity. But there is a There are many types of project lifecycle, the most popular ones are: phase to phase relationships, predictive life cycles, iterative and incremental life cycles and the adaptive life cycles.

-Phase to phase relationships: Normally one project has more than one phase, so the phases can be seen as part of a generally sequential process; there are two basic phase to phase -Iterative and incremental life cycle: Like a predictive life cycle, the project is split up into many phases which can be either sequential or overlapping. But the differences to the predictive life cycle is that the scope is not determined ahead of time at a detailed level, but only for the first iteration or phase of the project. Once that phase is completed, the detailed scope of the next phase is worked out, and so on (PMI 2013).

Product Lifecycle

In order to distinguish the differences from project lifecycle and product lifecycle, we will also introduce the product lifecycle definition. Firstly, we take the definitions of project and product from the PMBoK. We have given the definition of project in the section of introduction of project life cycle.

The PMBoK defines the product as "an artifact that is produced, in quantifiable, and can be either an end item in itself or a component item. Additional words for products are material and goods". At first sight it may seem to be that a product is a project, but it is not. We also take the definition of product lifecycle from PMBoK:

Definition: Product lifecycle are the series of phases that represent the evolution of a product, from concept through delivery, growth, maturity and to retirement (PMI 2013).

Product lifecycle and project lifecycle sound quite similar, but in fact, they are very different from each other. A marketing project can impact a product's life cycle, but otherwise these two concepts are essentially unrelated (Taylor et Media 2015). The project lifecycle is the link between product lifecycle and methodology used for creating the product. Koppensteiner gave an example of mapping the project lifecycle of a software project to the product lifecycle [START_REF] Koppensteiner | Process mapping and simulation for software projects[END_REF].

Product Lifecycle Management (PLM)

Due to a lack of formal management of project, there is another discipline called PLM. The conception of PLM came from the American Motors Corporation (AMC). Nowadays, there are many PLM definitions. For example, there are three definitions from CIMdata, PLM technology guide and Product Lifecycle Management.

Definition: PLM is a strategic business approach that applies a consistent set of business solutions in support of the collaborative creation, management, dissemination, and use of product definition information across the extended enterprise, and spanning from product concept to end of lifeintegrating people, processes, business systems, and information. PLM forms the product information backbone for a company and its extended enterprise (CIMdata).

Definition: Product life cycle management or PLM is an all-encompassing approach for innovation, new product development and introduction (NPDI) and product information management from ideation to end of life. PLM Systems as an enabling technology for PLM integrate people, data, processes, and business systems and provide a product information backbone for companies and their extended enterprise (PLM technology guide 2015).

Definition: Product life cycle management is the process of managing product-related design, production and maintenance information. PLM may also serve as the central repository for secondary information, such as vendor application notes, catalogs, customer feedback, marketing plans, archived project schedules, and other information acquired over the product's life" (Stark 2011).

In industry, PLM covers the process of managing the entire lifecycle of a product from inception, through engineering design and manufacture, to service and disposal of manufactured products [START_REF] Saaksvuori | Product lifecycle management. Product Lifecycle Management[END_REF]) (Frederic Demoly et al. 2010b) [START_REF] Matta | Traceability and structuring of cooperative knowledge in design using PLM[END_REF]. PLM integrates people, data, processes and business systems and provides a product information backbone for companies and their extended enterprise [START_REF] Mocan | Product life management system in digital manufacturing environement[END_REF] Implementing PLM method during the project development can reduce 30% of the time to market, 20% of the product development cost, 20% of the product cost, 20% of the cost of quality and 40% of the charge management cost [information technology in product development]. So how PLM is implemented is critical for the project. However, as PLM methods depend on the enterprises themselves, there is no project lifecycle management standard or guide [START_REF] Nayagam | Enquête sur les usages de solutions PLM en enterprise[END_REF]. But many famous tools are developed, such as the PTC Windchill and Catia (Computer Aided Three-dimensional Interactive Application). For example, both are PLM software, even if there are specialized functions.

The Windchill was developed by the PTC (Parametric Technology Corporation) company, which has more than 1.1 million users worldwide. The Catia was developed by the French company "Dassault Systèmes" [START_REF] Eynard | Aeronautics product development and certification workflow based on process modelling[END_REF], which is used in particular by Airbus to valid all the vendor's endorsements.

II.4.3. Project Assessment

The project assessment is critical during the implementation of project. The project managers can make decision after they assess the project. In order to assess the project, it is necessary to define the assessment indicators, including the Key Project Indicators (KPIs). So this section will briefly introduce the project indicator, project assessment and decision making.

Project indicator and assessment

Indicators are widely used to measure the success of any type of products or projects. For example, the total turnover is a performance indicator of a shop; the oil consumption and highest speed are two performance indicators of a car. Among all the indicators, there are some KPIs. They differ from the business domain; for example, the "new customer's acquisition" and "status of existing customers" are two KPIs of the marketing and sales [START_REF] Cotter | Taking the measure of e-marketing success[END_REF]. At the project level, many performances can be defined to assess the project progress. Keeble pointed out that the development and use of project indicators should be a dynamic process that informs decision making rather than being an end in itself [START_REF] Lin | Competition, policy burdens, and state-owned enterprise reform[END_REF]. He proposed to use indicators to measure sustainability performance at both the corporate and project level. The project managers can make more informed judgments about the risk management and decision making based on the measurement of performance at different levels.

Normally, main polices of project assessment can be distinguished: one type consists in assessing the success of project at the end of the project and can assume the practices of the finished project; it is named Summative Assessment (SA). Another type consists in assessing the project while it is undergoing in order to help the project manager to make decision; it is named Formative Assessment (FA) (Conforto et al. 2013). In the systems engineering discipline and the project management discipline, the assessment of the project is a process of the project that runs during all the project life cycle. In this thesis, we pay attention to quantifying and qualifying the assessment of the project progress based on the project performance indicators through the integration of systems engineering and project management indicators in a multi-indicator project performance evaluation approach.

Decision Making

Everyday life, people are concerned with a number of options to select and choices to make, wherever the domain. The project manager needs to make decisions all through the project life cycle.

We focused on two typical definitions for decision making:

Definition: Decision making is the study of identifying and choosing alternatives based on the values and preferences of the decision maker [START_REF] Pohekar | Application of multi-criteria decision making to sustainable energy planning-a review[END_REF].

Definition: Decision making is the process of reducing any hesitation or uncertainty about the available options in order to attain a practical and sensible choice [START_REF] Hammond | Smart choices: A practical guide to making better decisions[END_REF]. This way, the decision making can be considered as managerial decision making and technical decision making, or decision making under certainty, under risk or under uncertainty according to where is the focus (Yang et Singh 1994a). Nowadays, more researchers pay attention to the multicriteria decision making [START_REF] Sen | Multiple criteria decision support in engineering design[END_REF]. In the systems engineering and project management domains, the decision can be seen as a process; in the systems engineering discipline, decision making is more technical and in the project management domain, decision making is more managerial. Many decision making methods have been developed, such as the Pareto Analysis, Paired Comparison or Decision Trees. A more popular method to proceed to the multi-criteria decision is the Analytic Hierarchy Process (AHP) that was proposed by Thomas L. Saaty in the 1970s [START_REF] Saaty | What is the analytic hierarchy process?[END_REF] (Yang et Sen 1994b). An introduction to this method will be given in section VI.3.1.

II.4.4. Collaborative Engineering

Systems design has become a complex issue in the teams that are composed of engineers from different domains and cultures. So the need of collaborative engineering increased because of the global competition and consumer demand for the next great innovation. The international journal of collaborative engineering defines the collaborative engineering as a discipline that "studies the interactive process of engineering collaboration, whereby multiple interested stakeholders resolve conflicts, bargain for individual or collective advantages, agree upon courses of action, and/or attempt to craft joint outcomes which serve their mutual interests". It covers the development process in its organization, management and methodology, integrated with innovation development technologies. It is at the intersection of project management, engineering and collaboration and focuses on the joint practice of creating an engineering solution by a team. Effective collaborative engineering requires both guidance and best practice from team members when integrating in the team [START_REF] Belkadi | A situation model to support awareness in collaborative design[END_REF] (Park et Cutkosky 1999) [START_REF] Lu | A scientific foundation of collaborative engineering[END_REF]).

Figure II-16 Context of Collaborative Engineering

There are many approaches to support collaborative engineering, such as using collaboration support in engineering, integrating project management with engineering (the topic of this thesis), integrating collaboration and engineering and integrating project management and collaboration [START_REF] Nowak | Towards a design process model enabling the integration of product, process and organization[END_REF]) [START_REF] Eynard | Web-based collaborative engineering support system: applications in mechanical design and structural analysis[END_REF] [START_REF] Bonjour | Modelling interactions to support and manage collaborative decision-making processes in design situations[END_REF]). Many tools have been developed to support different teams in increasing collaboration [START_REF] Mallek | Enabling model checking for collaborative process analysis: from BPMN to 'Network of Timed Automata[END_REF]) [START_REF] Eynard | Web-based collaborative engineering support system: applications in mechanical design and structural analysis[END_REF].

Integrating SE and PM has been a critical issue of industry for a long time. As discussed previously, depending on the environment and organization, the two disciplines can be disjoint, partially intersect, or one can be seen as a subset of the other. Section II.5 will introduce our research objective and methodology.

II.5. Our proposal methodology

As we presented before, in this context, our research addresses the following hurdles:

1)Hurdle 1: The SE and PM approaches are complementary but practiced separately. Hurdle 1.1: There is no real approach capable of uniting SE and PM for carrying out engineering projects. The approaches taken by SE and PM are based on different standards, which are not necessarily applied. Despite recent efforts to bring them closer together, the approaches used are still very dependent on the business area, or target specific company profiles, and are currently neither conceptually unified, nor implemented in a consistent manner in business.

Hurdle 1.2: The indicators for PM only take into account the project parameters (deadline, workload, resources, etc.), and do not cover the operational, technological, organizational, human and social, or economic and environmental dimensions of an engineering project.

2)Hurdle 2: Using standards or guides in small or medium size company remains difficult. Hurdle 2.1: Methodological guidelines to deploy must be adapted to the needs and the size of the company, and proposed approach tailored to each profile. Hurdle 2.2: Project monitoring tools are available, but they only track the projects indicators and not those of the product. There is no project monitoring framework or method that also guides decision-making with the help of analyses and forecasts.

This thesis proposes to align the processes practices of Systems Engineering and those of Project Management. The option taken to reach this goal is to make their processes interoperable at best. A set of integrated process will be proposed, together with an approach for adapting it to different business activities and types of company, with the intention of making it applicable by SMEs (ISO 2011). Based on these collaborative processes, we wish to define the shared indicators and decision-support mechanisms that help decision-makers (technical and managerial) to supervise and manage both the project and the development of the technical system.

A first objective is thus to work towards the harmonization of the PM and SE processes. A comparative analysis of these processes will identify the principal differences between their descriptions or the roles of those participating in one and/or the other, and will propose adjustments to make these processes more operational by making them cooperative in practice, seeking and defining the connections to be established between them. This is a prior stage and a condition of success in the search for a solution for integrating SE and PM, and one of the means suggested by Conforto (Conforto et al. 2013). On the basis of a survey on the current academic and normative situation and of industrial practices, one option had already been identified in an earlier work (ANR ATLAS project (ATLAS 2011)); this consisted of a parallel and recursive description of systems into sub-systems and the corresponding tasks, coordinating product structure and project activities via a decisional model associating the managers from both disciplines. One possible routes currently being considered involves distributing overall responsibility for the project according to three groups of processes to the complementary objectives, planning/executing/controlling (Pl/Ex/Co), which depend on an identical representation of the project [START_REF] Baron | Specifications of a method and tool to support the management of systems engineering projects[END_REF]. The managers then proceed by discussion before any decisions are taken, which are then disseminated and can also be capitalized for later reference in the event of similar cases, in order to reduce the risk of errors and improve future decisions.

Associating to these three key types of activity organizes and formalizes the cooperation: at each step, with the help of indicators, managers can characterize any deviation from the initial objectives (representing the risks or opportunities) and only authorize pursuit of the project if the three roles, Pl/Ex/Co, are in agreement. If any discrepancies are identified, each of the managers, under the terms of his/her mission, can undertake an upstream analysis of any requirements that have not been fulfilled and find the reasons within or not within their area of responsibility, and discuss them with their opposite numbers. Our research work also proposes decision-support items but leaves open the choice of mechanism for decision-making: it can be discussed until a consensus is reached, or managed directly by a manager.

The second objective, in this attempt to harmonize processes as it appears on Figure II-17, is to consider indicators. Indicators can be seen as elements of a common language shared by the two areas they are intended for: the project on the one hand and the technical solution on the other. For example, they can characterize the performance or the state of maturity of a view of the project or of the technical solution (Bouleau 2007). Before and during the design phase, companies need to define and assess indicators for both the performance and the suitability of the product or service to be designed with the needs of customers and with its own constraints (Rio, Reyes, et Roucoules 2014). They must therefore also have methods and tools to enable them subsequently to exploit and substantiate their decisions, whether regarding the management of the project and of company resources, or the technical or technological choices necessary to converge on a satisfactory product or service. Furthermore, design studies, even in major industrial groups or SMEs, involve multiple processes, which require complicated management [START_REF] Langley | Toward a New Mindset: Bridging the Gap Between Program Management and Systems Engineering[END_REF]. It is important to simplify the procedures, to define the "merely useful" processes. This research work brings two methodological contributions, major one at processes' level, another lighter one on performance indicators to support evaluation and decision in a context of collaborative engineering projects. A similar research work related to integration of processes from systems engineering and project management domains has been previously done in our research group in a RNTL project named ATLAS. However, the ATLAS project (ATLAS 2011) only investigated the formal coupling between the design process and the planning process within the framework of a Work Breakdown Structure (WBS) representation of the project. Since then, the hypotheses advanced by the project have been reviewed to broaden the scope of the study to include the harmonization of all SE and PM processes.

We consider that the purpose of project management is to control and monitor the project, to structure and specify the quantified objectives to define indicators, which may be common or separate, for engineering (requirements of the system to be developed) and for the management of the project (requirements of the system for developing it). This structure can be further used as input data in traditional planning software to schedule project tasks, identify the critical path, determine the use of resources, etc. The methodology defined in this thesis will thus interface with tools such as planning or discrepancies between expectations and results in order to identify deviations. These expectations can concern both the system to be developed (product) and the system for developing it (performance, stability and integrity of the organization supporting the project).

While a given task is under way, this thesis proposes to follow its execution in such a way as to monitor changes to each indicator. By comparing them with the objectives it will be possible to detect deviations (in scheduling, performance, quality, budget, etc.). Indicators can have several functions and be of several types: Monitoring (the state of health of the project), Observing (discrepancies), Analyzing (possible solutions), Synchronizing (activities), Anticipating (risks and opportunities), Facilitating (decision-making), and Characterizing project progress in a summarized form. In a word, the ultimate objective of this thesis is to propose a proof of concept for the previous work packages the deliverables from Contributions 1 and 2. As a support for the integrated process, the mechanism of this thesis capitalizes and traces the project management activities performed by different players, according to their roles, and is also helpful for making decision collaboratively. This thesis is as a part of project "PROGEST" that has been submitted to ANR in 2015, and this project has three parts of research work: integration of the processes from SE and PM, definition of the dashboard in the context of industries' project and support of the decision making in the enterprise.

II.6. Conclusion

Previously, we have presented the problem context and the state of the art of our research work.

The related problem focuses and research objectives were also provided in this chapter. Although we presented the related focuses in four independent small parts: systems engineering and management, project management, project assessment and collaborative engineering, there are certain relationships between all of them. The identified problem is linked to every related focus presented before. The project could not be successful without any effective implementation of knowledge area. So we focus our research work in the intersection of SE, PM and DM in the general CE context. The knowledge and practices of SE, PM and DM are not only critical through the whole product life cycle, but it is also interesting to note that the decision making should be under the integrated views of systems engineers and project managers to improve the chance of project success.

Chapter III. Comparison of the Systems Engineering References

As we have introduced the context, problem formulation and state of art of this thesis in section II, this section will explore the first step of the proposal methodology. The organization of this chapter is as follows: Section III.1 introduces the state of the art of systems engineering. The evolution of systems engineering will be given in section III.2. Then we introduce the five main systems engineering references ANSI/EIA 632, IEEE 1220, ISO/IEC 15288, INCOSE SE HANDBOOK and SEBoK in detail in section III.3. In Section III.4, we will discuss the differences and similarities between the five references and propose a multi-standard approach for the systems engineering project.

Considering the normal project, we also compare the five references based on some common criteria integrating the SE with PM domains to choose a reference in order to integrate with the one selected from project management domain. The conclusion will be drawn in section III.5.

III.1. Introduction

Nowadays, as the systems become more and more complex and the scopes of project tend to be larger, being able to select the right references of systems engineering and project management is extremely important to enable companies to be successful in their projects [START_REF] Johnson | A comparison of the IEEE and IEC standards processes[END_REF]) [START_REF] Bekker | Defining a project life-cycle for implementing a high-tech project in rural Southern Africa-a case study[END_REF]) [START_REF] Dahmann | Implications of systems of systems on system design and engineering[END_REF] and SEBoK (Pyster et Olwell 2013), each one providing different implicit systems life cycle, levels of details and scopes for a system. They play the most important roles [START_REF] Roedler | What is ISO/IEC 15288 and Why Should I Care?[END_REF]. So it is useful not to say critical for the project manager to choose between several standards and guides the one which is the best fit for this company (in terms of processes, practices…) and projects. To do so, he/she needs in depth knowledge of all standards and guides. A preliminary goal of this chapter is to provide project managers with a detailed analysis and a comparison of SE standards and guides to make this choice easier. At the same time, this analysis will also help to evaluate how "alignable" these references can be with project management references.

Beyond this issue of selecting the right SE reference lies another one, that of applying good and referenced processes to lead the design such that the delivered product meets the customer needs but not sufficient however to have a successful project. Indeed, applying standard technical recommendations must be supported by a sound management of these processes, at the project level.

For example, when we use technical processes related to requirement definition process, solution definition process or validation process in a project, a planning process is required to schedule all the steps needed to implement the previous technical processes. Indeed, industrial practices show that engineers fully master processes (requirements, validation and verification) and tools (DOORS, WALL) used in their field of expertise but still cannot prevent project failures despite a strict application of technical processes owing to an incorrect implementation of project management processes.

In order to improve industrial performance and help reduce the cost of intellectual work, managing engineering processes is necessary. Thus this chapter not only aims at analyzing and comparing the SE standards and guides, but also what is proposed to manage SE processes.

III.2. Evolution of the Systems Engineering references

The first SE standard appeared in 1969. Over the years, many SE standards and guides have been derived from it. Figure III-1 shows the timeline and relationships between the various SE standards and guides. Reality is much more complex however. Indeed, SE standards and guides have been released

and impacted by other available standards or guides, particularly those in the software community. System" is still in use and focuses on the requirements and processes for engineering an enterprise-based system [START_REF] Martin | Evolution of EIA 632 from an Interim Standard to a Full Standard[END_REF]) [START_REF] Swarz | A framework for enterprise systems engineering processes[END_REF]. Because of its medium level of details and wide coverage of the systems life cycle, it has been widely used. and EIA (Electronic Industries Alliance). It provides a systematic approach to engineering and reengineering a system. The standard is intended to provide a set of fundamental processes to guide developers in engineering or re-engineering a system (ANSI/EIA 1998). It focuses on the SE of enterprise-based systems [START_REF] Martin | Evolution of EIA 632 from an Interim Standard to a Full Standard[END_REF]) [START_REF] Swarz | A framework for enterprise systems engineering processes[END_REF], versus military systems as in the MIL-STD-499 standard. Implementation of the requirements of ANSI/EIA 632 standard is intended to be through the establishment of enterprise policies and procedures that define the requirements for application and improvement of the adopted processes from the standard [START_REF] Martin | Evolution of EIA 632 from an Interim Standard to a Full Standard[END_REF]. The latest version defines 13 processes, 34 requirements (as the sub-process) in total. One of the most useful features is the close connection between processes; they are coordinated throughout the project. For each process, it defines the purpose and the requirements related to the process (34 requirements are identified for the whole set of processes). For each requirement, it provides the tasks, activities and expected outcomes. So this standard defines the processes at an intermediate level. It includes the whole systems' life cycle, but focuses on conception, development, production, utilization and support, with a brief mention of retirement. It also offers some PMPs, such as planning process, assessment process and controlling process.

This standard sets out some key concepts for SE. One of the most useful features of it is the close connection between processes; in each process there is a part that indicates the processes that are related to its outcomes; it allows coordination between them throughout the project, even if it makes the allocation of responsibility to the different processes more difficult. It also aims to describe activities and tasks at a high level of abstraction. However, its goal is not to specify the details of "how to" implement process requirements for engineering a system, nor does it specify the methods or tools a developer would use to implement the process requirements (ANSI/EIA 1998). The high abstraction level of tasks gives more flexibility to the developer for engineering a system, because constraints on tasks are less detailed. Thus, it offers a wide range of applications (commercial or non-commercial systems, government projects, aerospace systems, etc.).The first version was developed in 1994, as EIA/IS 632, updated in 1998 and used by enterprises to improve competitiveness. Although it defines some processes about project management, these processes hardly involve PM so they are not sufficient for the project managers to manage the project.

Although this standard provides processes for engineering systems, it does not define the tool or method needed to implement the processes throughout the project.

III.3.2. IEEE 1220

The and provides an approach to product development in a system context. In the 1999 revision (IEEE 1999), there were five important changes: increased emphasis on engineering the system for humans;

partitioning functional analysis into context analysis and functional decomposition to provide a clearer depiction of the functional analysis process in support of requirements analysis and synthesis;

improved clauses to make conformance statements clearer; simplified systems breakdown structure;

and increased emphasis on software [START_REF] Sheard | Systems engineering standards and models compared[END_REF]. It was updated in 2002 and again in 2005. In this version, there are some key differences: between the definitions of areas such as terminology, terms and structure, clarifications of the distinction between requirements, and recommendations of the standard. It also updates the conformance clause for alignment with the rules of IEEE standards (IEEE 2005). The purpose of this standard is to manage a system from initial concept through development, operations, and disposal. The inclusion of computers and associated software in today's products has intensified the need to engineer each of those products as a total system (IEEE 2005). The last version extended the scope to the entire system life cycle, while nonetheless focusing more on product development than on life cycle definition and implementation.

In this respect, it was more detailed than the ANSI/EIA 632 and ISO/IEC 15288 standards, but this very detailed description makes the standard less versatile. agreement processes, organizational project-enabling processes, project processes and technical processes, 25 processes in all. It describes systems engineering at the process level [START_REF] Roedler | What is ISO/IEC 15288 and Why Should I Care?[END_REF]. For each process, it gives the purpose and the outcomes that result from the successful execution of the activity tasks, activities and expected outcomes are defined in a less detailed manner than in ANSI/EIA 632. It also gives the key concepts and application of this standard, such as: system concepts, life cycle concepts and process concepts. This standard covers the system's entire lifecycle, from conception through to retirement of the system. But it does not prescribe, provide or specify systems engineering methods or procedures to address detailed process requirements for the application of this standard.

Like ANSI/EIA 632, it also offers some PMPs, such as configuration management, information management and controlling process. This guide clearly points out the two domains of systems engineering: systems engineering (ie, technical processes mentioned before) and systems engineering management (referred to in this thesis as project management processes). It describes the processes for both domains at the same level of details. As it recognizes the importance of the implementation of management processes during systems engineering, it increases the number of management processes.

III.4. Discussion and definition of an appropriate choice

Section III.3 presented the most important standards, ANSI/EIA 632, ISO/IEC 15288 and IEEE 1220, and two guides, INCOSE SE HANDBOOK and SEBoK. Of course, many differences can be found between these five standards and guides. For developers, the coverage of the systems life cycle is one of the most important aspects when selecting a reference. The level of details of processes or activities is another important metrics because it influences the flexibility and expandability of the reference; and abstraction is inversely proportional to the flexibility and expandability of the reference.

The different focuses on the standard or guide also influence the choice of standard. For example, if the company wants to develop a small hardware system, it may choose the IEEE 1220 standard, because it focuses on the development stage of systems engineering. But if the company intends to develop large software system that may last for ten years, the maintenance and the retirement of the system will also be very important for the re-engineering of system, it may opt for the ISO/IEC 15288 standard.

The ANSI/EIA 632 standard is more suitable for engineering enterprise-based systems; it focuses more on the technical management, validation and verification aspects. The ISO/IEC 15288 standard is more suitable for engineering complex systems, especially projects that cover an entire system life cycle. The IEEE 1220 standard focuses on the development stage rather than the whole system life cycle or the technical management aspects. Table III-1 presents the most important differences between standards, according to comparison criteria defined in [START_REF] Sheard | Systems engineering standards and models compared[END_REF]. extend a SE with PM processes or select the most "alignable" SE standard considering its PM ability.

This section considers both.

III.4.1. Proposal of a multi-Systems Engineering standard approach

This section will consider the options to extend a standard. The point is to select the most suitable one at the basis then to define how to extend it. Because we propose a multi-standard approach, we only consider the three SE standards except the SE guides. The SE standard we want to elaborate have to satisfy several specific criteria. Our needs according to one project called Decways of LAAS-CNRS are listed below:

-We need the standard to cover the entire system life cycle, from conception to retirement.

-With increasing project complexity, V&V (validation and verification) becomes more and more important; the standard should provide a detailed view of the V&V processes.

-The objective of our research was to find the best tools for coordinating processes and simulating project progress; as a result, the relationships between processes are key points for the comparison of standards.

From these needs, we derive certain criteria for refining the comparison of standards. The extent of coverage and the level of abstraction criteria have already been discussed. We add three new criteria.

The first two are validation and verification, each with their respective level of detail. In order to ensure that the simulation of project progress is reliable, we need to know and model the relationships between the processes clearly. It is therefore necessary to study a third criterion, the degree of internal consistency of each standard, to enable an evaluation of the possibilities of cooperation between the processes. The resulting analysis is shown in Table III-2. The V&V processes of the ANSI/EIA 632 are the most detailed and the relationships between the processes are the clearest of the three standards. From Table III-1 and Table III-2, we conclude that ANSI/EIA 632 satisfies our needs; it focuses on the enterprise-based system and the level of abstraction leaves the user of the standard sufficient flexibility. It also offers more details about the V&V processes. However, the ANSI/EIA 632 does not meet all the criteria. For example, it does not completely cover the system life cycle, and it does not consider the tailoring process to deal with the development of system complexity.

So in this case, our proposal is to use a multi-standard. Of the standards, ANSI/EIA 632 seems the most appropriate. However, no standard fully satisfies all the criteria; we therefore study the possibility of extending the ANSI/EIA 632 by the addition of some elements to better satisfy our criteria.

We choose ISO/IEC 15288 to complete the EIA-632. We add the maintenance process and the disposal process to ANSI/EIA 632 to cover the entire system life cycle. Our proposal is thus to choose ANSI/EIA 632 as the major standard because it satisfies most of our research criteria, but regarding the system life cycle (such as the maintenance and disposal processes), the integration process, the human resource management process and the tailoring At this stage of the study, we obtain a multi-standard SE standard that satisfies general and specific criteria. However, considering the processes of this reference and their relationships in detail, it is necessary to verify the following:

-That the processes extracted from ANSI/EIA 632 and ISO/IEC 15288 are mutually compatible.

-That the processes extracted from the two standards offer a similar level of abstraction.

-That the processes extracted from ISO/IEC 15288 can be subdivided into the 5 groups of the ANSI/EIA 632 standard.

-That the processes extracted from ANSI/EIA 632 and ISO/IEC 15288 share the same vocabulary and that tasks and activities are not duplicated.

We first have to consider the compatibility of processes. As in the ANSI/EIA 632 standard that there is no process that is identical to any process we selected from the ISO/IEC 15288, this eliminates the principal risk of inconsistency. Second, these processes involve only a few activities. When we execute tasks that correspond to the processes from ISO/IEC 15288, we only need to execute these processes instead of the tasks in the ANSI/EIA 632. We conclude that the processes concerned are mutually compatible.

A second problem concerns the abstraction level. Although the abstraction level of the ANSI/EIA 632 is higher than that of the ISO/IEC 15288, the processes from the two standards have the same architecture. Both standards give the definition, purpose, tasks, activities and the outcomes of each process. So the processes from the two standards can be used in the same way.

A third problem is how to classify the processes from the ISO/IEC 15288 into the five groups of the ANSI/EIA 632. As we showed in Figure III-6, the integration process, maintenance process and disposal process are clearly in the product realization group, while the tailoring process is in the technical support group.

A fourth problem concerns the definitions used in the three standards. We compared the definitions in the three standards and found that the brief definitions are identical or similar. For example, in the ANSI/EIA 632, the definition of "process" is "the process is a set of interrelated tasks that, together, transform inputs into outputs"; in the ISO/IEC 15288, the definition of "process" is "the process is a set of interrelated or interacting activities which transforms inputs into outputs". Definitions of "process" in both standards have the same meaning.

After analyzing the four risks defined above, we conclude that they present no real danger for the multi-standard approach and can be avoided easily. As a result, the processes from the different standards can work together very well.

Besides, our proposal is not the first multi-standard initiative; many standards exist in multistandard form. One of the most popular standards is the INCOSE SE HANDBOOK (version 2.0) (INCOSE 2010). The purpose of this reference is to provide a set of the key activities during SE; it is in conformance with the ANSI/EIA 632 but proposes some adaptations to it. It also provides some methods and tools for SE. We did not adopt the INCOSE SE HANDBOOK because, although it meets all the criteria in Table III-3, it is excessively detailed and lacks flexibility. Another example is the IEEE 1220. Its authors thought that it could be used in conjunction with the ISO/IEC 15288 because of the different focus of the standards. The IEEE 1220 describes the development stage of the system life cycle in greater detail, and the ISO/IEC 15288 describes all the activities throughout system life cycle.

Although the abstraction levels of the two standards are different, the authors of the IEEE 1220 proposed using the more detailed systems engineering process and the management requirements to complete the ISO/IEC 15288 (ISO/IEC 2008). We did not adopt IEEE 1220 either because it is only suggested for use in conjunction with the ISO/IEC 15288. The multi-standard approach that we propose for systems engineering has the same logic as the INCOSE SE HANDBOOK, using two standards together, and also gives greater flexibility for development.

III.4.2. Choice of a reference among the main standard references: ISO/IEC 15288

The second option is to consider selecting the "most alignable" standard or guide considering its PM ability. This section thus analyzes in detail SE standards and guide according to basic criteria and specific criteria related to PM. Sheard and Lake (Sheard et Lake 1998) already discussed similarities and SEM (Systems Engineering Management) -process ratio: the proportion of SEMprocesses with respect to their number can be found in each reference. In today's environment, there is an ever-increasing need to develop and produce systems that are robust, reliable, high quality, supportable, and cost-effective while meeting the needs of the customer or user. With systems being more and more complex, Systems Engineering references also become more detailed. The latest guide, SEBoK, is more than 800 pages long and includes a host of disciplines about systems engineering. The more recent SE references are mainly based on ISO/IEC 15288.

Additionally, as industrial organizations have been paying more attention to project management processes, almost half of all processes in ISO/IEC 15288 relate to PM.

So if we consider selecting a standard or references from SE domain, the ISO/IEC 15288 is the most suitable, we will give the reasons below:

-According to the "content of standard" criteria, we can find that the IEEE 1220 only has 8

processes, so it does not have enough processes to integrate with the PM reference, so the rest four references are more suitable than it.

-According to the "focus on systems' life cycle" criteria, the ANSI/EIA 632 focuses more

III.5. Conclusion

This chapter presented a survey on systems engineering standards and guides. We defined a set of criteria to compare the five major references and provided an analysis of them Section IV.2 presents the evolution of the project management in detail. The introduction to the two main project management references is given in section IV.3. Section IV.4 compares the two references based on their structures and their contents. Section IV.5 discusses and chooses one reference on behalf of project management domain, it also derives the conclusion that the PMBoK is the most suitable reference to be used to integrate with the systems engineering. The conclusion of this chapter will be given in section IV.6.

IV.2. Evolution of the Project Management references

The Great Pyramid of Giza, the Colosseum in Rome and the Great Wall of China are testimonies of successful construction projects. In the 2570's BC, the ancient records show that there were managers for each of the four faces for the Great Pyramid when they were built. Even if, at that time, project management was certainly not considered as a discipline, however, according to historical data, the labor force was organized into three groups: soldiers, common people and criminals when the Great Wall of China was built [START_REF] Kwak | A brief history of Project Management. The story of managing projects[END_REF]. The origins of the theory of project management correspond with the development of the Gantt chart, named this way by its creator Henry Gantt, in 1917. He is the forefather of project management discipline. In the 1950s, the Navy employed the modern project management methodologies in their Polaris project. During the 1960s and 1970s, many methods or tools were developed, for instance, the Critical Path Method (CPM), the Program Evaluation Review Technique (PERT) and Work Breakdown Structure (WBS). At the same time, a lot of organizations were built to promote methodologies for project management, such as the American Association of Cost Engineers (AACE), the International Project Management Association (IPMA) and the Project Management Institute (PMI). Indeed, PM covers a wide field of applications where associations historically played and still play an important role [START_REF] Kwak | A brief history of Project Management. The story of managing projects[END_REF].

Each organization defines with its own words and visions what project management is. The PMI states that "Project management is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements" (PMI 2013). The ISO 21500 defines the PM this way:

"Project Management is the application of methods, tools, techniques and competencies to a project" [START_REF] Iso | Software Engineering -Lifecycle Profiles for Very Small Entities (VSEs)[END_REF]. The definition of PMI emphasizes the purpose of PM is to meet the project requirements.

The application of project management can meet the requirements better, short the cost and time to finish the project (PMI 2013).

Many standards or guides were developed by the different organizations from the 1987's. PMBoK was first published as a white paper by PMI in 1987; it was an attempt to document and standardize project management practices (Xue et al. 2014). The first edition appeared in 1996, the second edition in 2000, a third in 2004, a fourth in 2009 and the last version in 2013. In 2012, the International Organization for Standardization (ISO) recognized the importance of formalizing the practices of project management; they published the standard ISO 21500 in 2012 [START_REF] Munns | The role of project management in achieving project success[END_REF].

IV.3. Introductions to the two main Project Management references

PM standards and guides were developed some time after SE standards but greater emphasis has been laid on project management lately. Two major PM references have been drawn up. The first international PM reference is the PMBoK Guide; the second is the famous ISO 21500 norm that was issued for the first time in 2012 by [START_REF] Iso | Software Engineering -Lifecycle Profiles for Very Small Entities (VSEs)[END_REF]. This section briefly introduces these two main PM references.

IV.3.1. PMBoK

With the development of project management, the PMBoK has been released many times from 1996 to now. PMBoK is published by PMI. The methodology put forward by it is now the most commonly used in the world owing to its genericity and broad coverage of good practices in project management. It arose from the need to standardize project management practices, supported by the PMBoK. This guide aims at providing knowledge, processes, skills, tools and techniques that have a significant impact on the project success (Xue et al. 2014). The first part of this guide provides the subset of the project management body of knowledge that is generally recognized as good practices.

The first edition was developed in 1996, and was updated in 2000, 2004, 2008 and 2013. The latest version defines five process groups according to the project phases (Initiating, Planning, Executing, Monitoring and Controlling, Closing) and 10 knowledge areas (see Figure . Each phase contains a set of processes. The latter are defined at the process level, as methods that transform input data into output data (deliverables, results, documents and so on). This reference not only defines processes for PM, but also provides the tools and methods needed to implement processes which cover the systems' entire life cycle, from conception to the retirement of systems.

It defines 47 processes in the first part of this guide organized into 10 Knowledge Areas (KA) related to the professional field, project management field or area of specialization, such as the project scope management and project cost management. In the second part, this guide re-groups the processes to form a project management standard. It defines the five process groups based on the five stages of the project implementation: initiating process group, planning process group, executing process group, monitoring and controlling process groups and closing process groups (Xue et al. 2014) This reference provides all processes and disciplines about PM. It is a famous project management guide for project managers.

IV.3.2. ISO 21500

Like the PMI, the ISO organization also recognized the importance of improving the performance of project management in order to enhance the competition of companies, and published the ISO 21500

Guidance on project management in 2012 [START_REF] Iso | Software Engineering -Lifecycle Profiles for Very Small Entities (VSEs)[END_REF]. So far, this standard has not been updated. It is an international standard on project management. The ISO started to edit this standard from 2007 and finished in 2012 [START_REF] Stellingwerf | ISO 21500 Guidance on project management-A Pocket Guide[END_REF]. The purpose of this standard is to provide generic guidance on concepts and processes of project management that are important for the successful completion of projects (ISO 2013). It refers to many standards or guides, such as PMBoK and some standards of IPMA (International Project Management Association).

It defines five process groups and ten subjects (similar to the knowledge areas in PMBoK). In ISO 21500, owing to its page limitation, the tools and techniques needed for each PM process are not given.

It is more abstract than PMBoK. The latter is much more detailed than ISO 21500. It also pools together 39 processes into 5 process groups (initiating, planning, implement, controlling and closing).

IV.4. Comparison of project management references

The two references introduced above are the most famous standards or guides for project management. After a brief introduction to them, the purpose of this section is to compare them generally (section IV.4.1) and in details (IV. 4.2 and IV.4.3). A detailed comparison of processes in the two references will be addressed in this section where processes from each reference will be identified,

IV.4.1. General Comparison of the two references

This section compares the two references according to a set of general criteria: the number of processes of references, the target audience, level of details, proposition on tools and techniques, year of publication and the revision frequency.

The PMBoK has the largest number of project management processes, the ISO 21500 has 39 processes. Both of them are intended to be used by any scale company, although there are some studies pointing out that the VSEs have the difficulties to relate themselves with the international standards.

The PMBoK almost has 600 pages, it is the most detailed PM reference; it not only provides the purpose, inputs and outputs of each process, and it also presents some PM tools and techniques. The ISO 21500 is a standard without suggestion on tools and techniques. The two references are all very new, there are all published recently and the PMBoK is the fifth edition because the wide use of this guide. The Table IV-1 gives a quick overview on the result of this general comparison.

IV.4.2. Detailed Comparison based on the structure level of two references

This section compares the process groups of the PMBoK Guide and ISO 21500 standard, and analyzes the PM objectives and activities to align the two references at the structure level.

PMBoK; the "define project plan process" instead of "develop project management plan process ". The ISO 21500 rewrite the "estimate activity resource process", "acquire project team" and "develop project team" of PMBoK with the "establish project team process", "estimate resource process", "define organization process" and "develop project team process", "plan scope management process", "plan schedule management process", "plan cost management process", "plan human resource management process" and "plan risk management process".

The result of the comparison on the two references at the process level is shown in Table IV-3.

IV.5. Discussion and choice of a reference: PMBoK

After this comparison of the two project management references, we come to the conclusion that the PMBoK is suitable for the large scale projects, even if it can be used at any time and at any level of projects. Regarding the profile of the VSEs, the implementation of the PMBoK would cost too much time and money; this does not suit the required flexibility of VSEs. The ISO 21500 almost has the same PM processes as the PMBoK, but it does not provide the tools and techniques for the project manager to manage projects. If the project managers do not consider the suggestion on PM tools and techniques, they can choose any one of the PMBoK and ISO 21500 as the reference.

IV.6. Conclusion

This chapter firstly introduced the history of project management and the state of the art of the project management standards and guides development. We chose two main PM references: PMBoK, and ISO 21500. We presented them briefly in section IV.3. Then in order to integrate with ISO/IEC 15288, the one we selected in the Chapter III, we compare the two PM references on their structures and their contents in this section. After the comparison and analysis of the two PM references, we come to the conclusion that the PMBoK is the "most alignable" reference on behalf of PM domain. We will show the methodologies on how to align and integrate the two references: ISO/IEC 15288 and PMBoK in the next chapter.

Chapter V. Comparison and Alignment of the ISO/IEC 15288 and PMBoK

In this chapter, we first introduce the concept and utility of standards and guides. Then, we briefly remain the positions of the ISO/IEC 15288 standard and the PMBoK in terms of history, evolution and purpose, and compare both references at two levels.

With the increasing globalization of markets, international standards and guides have become essential in project, ensuring the product and services meet internationally recognized levels of performance and safety. So companies are encouraged to use international standards or guides.

A standard is a document that provides requirements, specifications or guidelines to ensure that products, processes and services fit their purpose (ISO/IEC 2008). However it does not give details on "how to" implement process requirements for engineering a system, nor does it specify the methods or tools a developer should use to implement the process requirements. It facilitates communication between stakeholders, suppliers and buyers who can use a common language (PMI 2013). It can also be employed as a strategic tool by organizations or companies to reduce production costs. The products and services are safe, reliable and of good quality if they have been developed by companies following the standards. They also help them access new markets and facilitate trade. Moreover, they result in other benefits, such as enhancing customer satisfaction, increasing sales and protecting the environment by reducing negative impacts on it (ISO/IEC 2008).

Usually, a guide features more content than a standard. A standard does not contain the tools and methods that can be used, but the guide sometimes contains the practices, tools and methods that can be used. For example, the PMBoK (A Guide to the Project Management Body of Knowledge) is a guide; in the first part, it provides some good practices about project management including the tools and methods, and Annex A1 is the standard for project management. It details the processes and the processes' inputs and outputs.

Several organizations are involved in the development of international standards and guides [START_REF] Morley | The Standards Department and Its Relationships to the IEEE Standards Process[END_REF]. For example, one may cite ISO (International Organization for Standardization), IEEE (Institute of Electrical and Electronics Engineers), IEC (International Electrotechnical Commission)

and the PMI (Project Management Institute). IEC develops international standards related to electrotechnology and conformity assessment, whereas ISO has over 195,000 international standards covering nearly all other technical fields, a number of service sectors, management systems and conformity assessment (ISO/IEC 2008) [START_REF] Johnson | A comparison of the IEEE and IEC standards processes[END_REF]. So a great deal of standards and guides are used by companies as reference. Among them are many popular standards, such as ISO 9000 about quality management, ISO 14000 about environmental management and ISO 31000 about risk management. The PMI only focuses on drawing up the guides or standards related to management.

There are so many international standards or guides; they can be sub-divided into three categories (see

V.1. General structure analysis

In this section, it is shown how both references are organized with the aim of comparing them from the general structure viewpoint. Then we compare them at the process group level and at the processes and activities level. Lastly a conclusion will be given on the two comparison levels.

V.1.1. Introduction to ISO/IEC 15288 structure

ISO/IEC 15288 standard is broken down into three levels of processes. The first level features four process groups; there are 25 processes in total in the four process groups at the second level. Each process is presented in terms of purpose, outcomes and activities at the third level as shown in Figure

V-1.

V.1.2. Introduction to PMBoK structure

The PMBoK is also broken down into 3 levels; there exists 10 Knowledge Areas at the first level.

To these 10 areas correspond 5 process groups at the second level; relationships between the three levels of PMBoK are depicted in Figure V-2. These five Process Groups have clear dependencies and are typically performed in each project and interact with one another. They are independent of application areas. Each process is characterized by its inputs, the tools & techniques that can be applied and the resulting outputs (PMI 2013).

V.2. Comparing ISO/IEC 15288 and PMBoK on their structure V.2.1. Comparison on ISO/IEC 15288 and PMBoK with respect to first level of decomposition

In this section, ISO/IEC 15288 and PMBoK are compared with respect to the first level of decomposition.

After analyzing the processes of the 10 knowledge areas in PMBoK, we will find that almost in each Knowledge Area (KA) there are two similar processes: the planning process and the controlling process. There are nine Knowledge Areas (KAs) that have the planning processes and eight KAs have the processes in the monitoring and controlling process groups, as shown in The following table lists the matching processes of ISO/IEC 15288 and knowledge areas of PMBoK. Process" match the 5 knowledge areas: Integration, Scope, Time, Cost and Quality. The knowledge areas "Stakeholder" and "Integration" are only partially covered by the process "Decision Management

Process". Then, some parts of these two knowledge areas are not covered by ISO/IEC 15288. As the PMBoK organization is explained in the previous section, each knowledge area is composed of 5

processes and each process is also composed of several outputs. Some of these outputs (especially the "project document updates") deal with configuration management. Thus, the 10 knowledge areas cover the sub-process "Configuration Management process".

V.2.2. Comparison on ISO/IEC 15288 and PMBoK with respect to second level of decomposition

Let us now consider the relationships between the tasks and activities of ISO/IEC 15288 and the 5 process groups of the PMBoK. We analyze all processes of the ISO/IEC 15288, we extract and classify the verbs that are used to describe the tasks and activities of the processes. A distinct classification can be found, and they can be classified into five groups as shown in the left column of Table V-6. It is worth noting that the five verb groups exactly correspond to the names of the five process groups of PMBoK. This corresponding relationship between the two references is shown as Table V-6. Words in the left row are most often used in ISO/IEC 15288. In PMBoK, there are mostly five processes but it can also vary between 4 and 6. In ISO/IEC 15288, there may be between 2 to 6 tasks and activities but mostly 3. Table V-

V.3. Comparing ISO/IEC 15288 and PMBoK on their contents

After comparing both structures it is worthwhile having a look at the contents of both references.

Analyzing the content of each standard allows us to point out some interesting remarks which will be detailed in this section.

V.3.1. Focus on different systems in both standards

The two references focus on different systems. Indeed, the PMBoK's system of interest is a project whereas ISO/IEC 15288's system of interest is a product or a service. This point occurs in each knowledge area and in each process.

For example, "risk management process" in ISO/IEC 15288 deals with a product or service as shown in the following definition: "The risk management process is a continuous process for systematically addressing risk throughout the life cycle of a system product or service". Likewise, "project risk management" in the PMBoK deals with a project as shown in the following definition:

"Project risk management includes the processes of conducting risk management planning, identification, analysis, response planning, and controlling risk on a project".

Nevertheless, "approaches", "processes" and "steps" in ISO/IEC 15288 and PMBoK are still the same means. For example, every tasks and activities of the process "risk management process"

(ISO/IEC 15288) matches almost every process of the knowledge area "project risk management" as shown in Table V-7:

V.3.2. Chronologically versus concurrently

How to execute simultaneously or chronologically is a point to examine when looking at references.

For the PMBoK, the 10 knowledge areas can be executed concurrently. Indeed, each knowledge area is an important project management field, and information about cost or time must always be available. All the knowledge areas will not begin and end at the same time but they are all independent.

Conversely, the five processes of the ISO/IEC 15288 must be executed one after the other. For ISO/IEC 15288, the four process groups: "Agreement Processes", "Technical Processes", "Project Processes" and "Organizational project enabling Processes" can be executed concurrently. For processes, some of them can run simultaneously while the others must be executed in a chronological order. For example, the two processes "Acquisition Process" and "Supply Process" (pertaining to the "Agreement Processes") can run simultaneously. However, almost all processes which belong to the "Technical processes" must be executed one after the other. Finally, all "Tasks and Activities" in each processes have to be executed in a chronological order.

V.3.3. Conclusion on the comparison of the ISO/IEC 15288 and PMBoK on their contents

The first general remark that can be made is that the degree of explanations differs in both references because of the different level of details. The PMBoK is more detailed than ISO/IEC 15288.

This can be easily verified by the number of pages even if this indicator can be discussed on its significance. ISO/IEC 15288 is 84 pages long whereas PMBoK is 616 pages long. Moreover, the manner in which both documents are decomposed also accounts for these differences. On the one hand, in ISO/IEC 15288, there are just chapters for the 4 main categories of processes and one small part for each process; on the other hand, in PMBoK, one chapter is devoted to each knowledge area and a small portion in each chapter is devoted to each process.

Secondly, it has been stated that in the decomposition of the 5 processes of PMBoK, there are some introductions about the tools and methods corresponding to the processes. It is really useful to know those tools or methods allowing the processes to be implemented effectively. However, the ISO/IEC 15288 standard does not mention the tools and methods that can be used during the implementation of the processes. Thirdly, one has to check whether words convey the same meaning in both standards.

Indeed, after reviewing the words used in both references, it appears that there are no real differences on the technical side, for example, the word "specification" or "risk" has the same meaning in both references. The only thing worth noticing is that the word "system" has a different meaning.

V.4. Proposal of integrated processes

The first three parts of harmonizing the processes from systems engineering and project management have been done in the chapter II, III and IV. To achieve this alignment remains three difficulties: 1) analyzing whether the descriptions of processes in both references are at the same level of details, 2) which means preliminary regrouping processes with the same objective and removing the potential overlaps between them, 3) structuring processes into three process groups aiming at planning, executing and controlling. So section V.4.1 analyzes whether the descriptions of processes in both references are at the same level of details. Then we explain how to integrate processes with the same objective and remove the potential overlaps in section V.4.2. In section V. Before the regrouping processes, PMBoK has 47 processes; after integrating the processes into aggregated processes, the PMBoK has 18 processes as the ones underlined in Table V-8 below.

Because the ISO/IEC 15288 also has some systems engineering management activities and processes, some overlaps exist between the two references. So we need to analyze ISO/IEC 15288 and PMBoK processes into details to identify and if possible remove the detected overlap.

Because we focus on the integration of systems engineering and project management, the managerial processes are selected from the PMBoK, and 10 technical processes from the ISO/IEC 15288; duplicated activities are deleted. The 10 processes are the ones that are not underlined in Table V-8. We regroup the processes selected from PMBoK into 18 processes as shown in Table V-8. After the selection of processes, we need to structure the processes.

V.4.3. Structure the processes into three integrated process groups

At the end of this step, we propose to structure the integrated processes from both references in order to facilitate the next steps. We will structure all the process referenced to the PMBoK because we choose the PMBoK as the reference. It has five process groups: initiating process group, planning process group, executing process group, monitoring and controlling process group and closing process group. As our method focuses more on the development stage of a project, we structure all the integrated processes from both references into three process groups: Planning Process group, Executing Process group and Controlling Process group. The result of the combination is shown in As shown in Table V-8, there are 28 processes in total after the harmonization of the PM and SE processes. In the contents of all the 28 processes, we retain the input, output of these processes as the important elements for chapter VI is shown in this example.

V.5. Comparing our proposal with ISO/IEC 29110

The objective of our proposal is to integrate SE and PM, so we need to pay attention to another standard: ISO/IEC 29110 that intends to integrate the SE and PM domains. In this section, we compare our proposal with this standard. The introduction of the ISO/IEC 29110 will be given in section V.5.1.

In the section V.5.2, we will compare the ISO/IEC 29110 with our proposal from two aspects.

V.5.1. Introduction to ISO/IEC 29110

With today's large scale projects, it is compulsory for companies to buy elements of large and complex systems from suppliers, often small companies, so many small companies were created quickly to meet this requirement. Because the Small and Medium Enterprises (SMEs) having up to 25 people have difficulty to apply systems engineering and project management guides and standards in their projects due to the lacking of resources For ensuring the quality of projects or systems, it is necessary to help the very small entities (VSEs) develop high quality products. Considering this, another international standard is the ISO/IEC 29110 elaborated by the sub-committee 7 of Joint Technical Committee 1 of the ISO and IEC (International Electrotechnical Commission) and dedicated to the very small entities (ISO 2011), and it allows the VSEs to adapt themselves to the guide by adding some elements from their own. The ISO organization developed a guide named "Software engineering -Lifecycle profiles for very small entities" [START_REF] Iso | Software Engineering -Lifecycle Profiles for Very Small Entities (VSEs)[END_REF]. This guide considers VSEs as entities with less than 25 employees (ISO 2011). There are five parts of this guide: The first part of this guide aims at introducing the guide briefly, such as the processes, lifecycle and some other concepts. The purpose of the second part of this guide is to introduce the concepts for software engineering standardized profiles for VSEs and defines the terms common to the documents of the VSE profile set. The third part provides the definitions of the process assessment guidelines and the compliance requirements that are used to meet the purpose of the defined VSEs profiles. It defines the specification for all the profiles of the Generic Profile Group (GPG) in the fourth part. In the last part, it gives an implementation management and engineering guide for the entry profile of the GPG.

According to the purpose of this work, we focus on the fifth part of this guide. The next section we will introduce this part of ISO/IEC 29110 in order to compare with proposal detailed.

The ISO/IEC 29110 is the least detailed guide among the three references because it focuses on the VSEs. Indeed, considering the scale, budget, number of employees of the VSEs, it just defines some example process or activities of project management to give the references to the VSEs.

V.5.2. Comparing our proposal with ISO/IEC 29110

In fact, the ISO/IEC 29110 series of standards and technical reports has been developed to improve system or software or service quality and process performance. The process of ISO/IEC 29110 has a completely different way from other standards and guides to present the processes. Each part of ISO/IEC 29110 series has the same method to present and structure the processes, so we take the ISO/IEC 29110-5-1-1 as an example here. The name of this part is "Software engineering -Lifecycle profiles for Very Small Entities (VSEs) -Part 5-1-1: Management and engineering guide: Generic profile group Entry profile". It defines 2 processes: Project Management (PM) process and Software Implementation (SI) process. The PM process aims to establish and carry out in a systematic way the tasks of the software implementation project (ISO 2011); the purpose of the SI process is the systematic performance of the analysis, software component identification, construction, integration and tests [START_REF] Iso | Software Engineering -Lifecycle Profiles for Very Small Entities (VSEs)[END_REF]. Each process has the descriptions of purpose, objectives, input products, output products, internal products, roles involved and diagram.

According to the reports and studies, it is obvious that the VSEs have difficulties to use the international standard during their projects because of the scale, the time and the resource of the VSEs (ISO 2011). For those reasons, this guide defines lee processes than the other standards and guides, in this part, two processes: the project management (PM) process and the software implementation (SI) process has been defined. But this guide allows the VSEs to adapt themselves to this guide by adding their processes and tailoring the activities or processes. The structure of ISO/IEC 29110 is shown in However, after aligning the structures and level of detail of the other references, we can say that this guide defines two process groups: the project management process group and the software implementation process group.

The PM process presents four process groups (named PM activities in the guide): project planning, project plan execution, project assessment and control and project closure. But at the same time, it also defines 7 PM objectives: project plan, progress of the project, changes requests, review meeting, risk, items of software configuration and software quality assurance. In each PM objectives, it suggests to use some processes from the ISO/IEC 12207. So after analyzing the elements of the processes in the 7

PM objectives in the PM process of ISO/IEC 29110-5-1-1, we find that there are 9 processes selected from the ISO/IEC 12207: project planning process, measurement process, project assessment and control process, software acceptance support process, software requirements analysis process, software review process, risk management process, software configuration management process and software quality assurance process. We can say that the 4 PM activities are corresponding to the process groups in the PMBoK. The 7 PM objectives are corresponding to the KAs of PMBoK.

The SI process of the ISO/IEC 29110-5-1-1 has 7 objectives, 2 input products, 1 input products, 4

internal products, 3 roles involved and 6 activities. If we take a look at the activities of the SI process, we can find that they are very similar to the systems engineering processes. For instance, the software implementation initiation, software requirements analysis and product delivery are three important processes in the other systems engineering standards and guides. The SI process also takes the ISO/IEC 12207:2008 as a reference as the PM process.

The brief differences between this standard and our proposal are shown in the table below:

Our proposal ISO/IEC 29110-5-1-1 Scope 28 processes 2 processes The target audience Any company (including SMEs) VSEs Level of details Our proposal not only uses the processes from ISO/IEC 15288 and PMBoK, but also aligns them at the same level of detail and integrates them. The ISO/IEC 29110 uses some processes from ISO/IEC 12207:2008 as a reference and does not specify the process in details. Our proposal integrates the systems engineering and project management domains, the ISO/IEC 29110 dedicated to software engineering, not the systems engineering.

V.6. Conclusion

Based on the research work of Chapter III and Chapter IV, we selected the ISO/IEC 15288 in the SE domain and the PMBoK in the PM domain. In order to integrate the SE and PM practices, our proposal is to integrate the processes selected from these standard and guide. This chapter analyzed the similarities and differences between these two references. We compared them at two different levels: their structures and their content. Based on the comparison, we concluded that they can be aligned. We proposed to regroup the processes from PMBoK to have the same level of details as the activities from ISO/IEC 15288. We eliminated some redundant activities in order to avoid an overlap of references.

We then proposed to structure the remaining processes into three process groups: aiming at planning, executing and controlling. Based on these integrated processes, next chapter defines a set of core indicators to assess the project performance . performance, quality, budget, etc.). In our proposal, we define five project indicators: entry criteria, cost, duration, resource and expected criteria of the process [START_REF] Lévárdy | An adaptive process model to support product development project management[END_REF]. The cost, duration and scope are always called "project management triangle". According to the definition of processes, we consider the "entry criteria" and "expected criteria" as the scope of the processes. With the increasing attention to human resource management, we also define the "resource of process" as another criterion. So we define a set of five core indicators for our assessment method. According to the EVM method, a popular project management technique for measuring project performance and progress [START_REF] Anbari | Earned value project management method and extensions[END_REF] [START_REF] Fleming | Earned value project management[END_REF] The planned values of each indicator for each process should be given at the beginning of project.

After WBS (Work Breakdown Structure) has been finished, all the planned values should be attributed.

In other words, for the initialization of project, only the planned value is set. Other indicators values will be updated during the realization of the process. The actual value and earned value are given by both systems engineers and project managers at the moment when they want to evaluate the project progress. The detail steps of this combined methodology will be explained in Figure VI-4. Each process is associated with these five indicators. They are described here below.

VI.2.1. Entry criteria of the process

The indicator "Entry criteria" is defined as . It indicates the minimally acceptable inputs in order to perform the process. The planned value, actual value and earned value of the EVM method of this indicator are defined as: For example, the "Human Resource Plan Process" of PMBoK has four inputs: "project management plan", "activity resource requirements", "enterprise environmental factors" and "organizational process assets". If at the calculating moment, four inputs should be finished but only "project management plan" is finished, and the number of the budgeted inputs performed is 2. Then the three values are .

VI.2.2. Cost of the process

The indicator "Cost" is defined as . It corresponds to the money allocated to the process. It will be used to evaluate if the process is over or under budget. The planned value, actual value and earned value of the EVM method of this indicator are defined as:

= the planned value of the cost of this process

Let us take a process where cost allocated to this process is 10,000 dollars. If the cost that has been spent for the current moment is 5,000 dollars and the budgeted cost of the finished work of this process is 3,000 dollars, then the three values are , , 3,000.

VI.2.3. Duration of the process

The indicator "Duration" is defined as . It indicates the duration of the project. It will be used to evaluate whether the project is behind or ahead of schedule. The planned value, actual value and earned value of the EVM method of this indicator are defined as:

= the planned value of the time required of this process

For example, for a process requiring 400 hours of work, the time spent at the current moment is 200 hours and the budgeted time of the finished work is 300 hours. Then we have , , 300.

VI.2.4. Resource of the process

The indicator "Resource" is defined as . It corresponds to the resources that couldn't be calculated by money generally, such as the human resource. It will be used to evaluate whether the resource of project is over or under the enterprise capacity. The planned value, actual value and earned value of the EVM method of this indicator are defined as: operation research. Among them, AHP (Analytic Hierarchy Process) is a useful method for analyzing complex decisions. It was first put forward by Thomas L. Saaty in the 1970s and has been extensively studied and refined since then [START_REF] Saaty | What is the analytic hierarchy process?[END_REF]. At first, Saaty proposed to use the AHP method to rank a set of cities from the most to the least livable. He considered some cities in the US. He defined that the livability can be decomposed into satisfaction of some criteria, such as environment, services, and security. Each criterion can have its own subcriteria. The survey of AHP method was given to six decision makers. They need to give the differences of preferences between them. Indeed, the AHP method has something in common with the value theory. In both methods, there is a set of alternative which are eventually matched with real numbers. The AHP method has many different application domains, for instance, the city evaluation and planning [START_REF] Saaty | What is the analytic hierarchy process?[END_REF], country ranking, mobile value services, organ transplant, chess predication, facility location and so on. Matteo locates the AHP method in the context as Figure VI-1 [START_REF] Brunelli | Fair Consistency Evaluation in Fuzzy Preference Relations and in AHP[END_REF].

Figure VI-1 The location of the AHP method in the scientific debate [START_REF] Brunelli | Fair Consistency Evaluation in Fuzzy Preference Relations and in AHP[END_REF] In order to explain the AHP method and how to calculate the weight of the criteria, we will give an example later to explain the integrated method based on the AHP, CPM and EVM methods.

VI.3.2. The introduction to the CPM method

The CPM (Critical Path Method) was developed in the 1953s by the US Navy [START_REF] Shaffer | The critical-path method[END_REF]. At the beginning, this method was only used to consider logical dependencies between terminal elements. Since then, it has been expanded to allow for the inclusion of resources related to each activity, through processes called activity-based resource assignments and resource leveling [START_REF] Kelley | The critical-path method: Resources planning and scheduling[END_REF]). The CPM is a mathematical algorithm for scheduling a set of project activities. It is very useful to manage projects effectively. It is commonly used with all forms of projects, including construction, software development, research projects, product development, engineering, and plant maintenance, among others [START_REF] Santiago | Critical Path Method[END_REF]. If we want to use the CPM method to manage the project, there are three critical elements: 1) a list of all activities or processes to complete the project; 2) the duration of each activity or process should be given; 3) the dependencies between the activities or processes should be identified.

VI.4. Evaluation of the project progress with an integrated view

In order to evaluate the project progress, we define four indexes: the PcEPI, PcAPI, PjEPI and PjAPI based on the EVM method. The significances of these indexes will be explained in section VI.4.3. If we want to evaluate the project performance by those indexes, we go down into the level of project phases; it means that we need to assess the project progress at least at the beginning of each phase of the project. So at the beginning of each project phase, we go deep into the process level, and we calculate the project value based on the process value. In order to calculate the process value, we go deep into the indicator level. We detail the steps of the implementation of our proposal; it is as shown in Figure VI-4. It is obvious that not all the processes of the project have same importance. For example, the "transition process" is less important than the "architecture design process". Their impacts on the decision-making are proportional to their importance. Thus we decide to use the process weights on behalf of the importance of processes. The weight of process is calculated based on the CPM method.

In this section, we will introduce how to use the CPM method to calculate the process weight. In order to use the CPM method, at the beginning of each phase of the project, it is necessary to initiate the processes related to the phase. After the initiation of the processes, based on the start time and duration of processes, we can find the processes that are on the critical path of this phase, in the other word, the processes must be started and finished on time. We define this process weight as which means that it is the CPM weight value of the process of the process group as we define in Table V-8.

The steps about how to calculate the weight values of the processes based on the CPM method are as follows:

1) Calculate the earlier time of the process:

2) Calculate the latest time the process can be implemented 3) Calculate the difference between the earliest time and the latest time of each process The V1 is the moment when the project starts, the processes "A" and "B" do not have any previous process, the duration of process "A" is 2 days and the duration of "B" is 2 days. The process "C" is the previous process of "A" and its duration is 1 day. The process "D" is the previous process of "B" and its duration is 2 days. After calculating the values above, we can get the four weight value of the processes as:

VI.4.2. Calculate the indicators' weights with the AHP method

As we known, indicators can evaluate the success of an organization or a particular activity. How to choose indicators always depends on the department measuring the performance. In our proposal methodology, we focus on the formal integrated processes from SE and PM domains. So we define a set of five core indicators to assess the project progress, but the systems engineers and project managers can define additional indicators for a special type of project. It is very clear that the indicators do not have the same impact on a project through all the product life cycle. For example the "Duration" is less important at the end of the product life cycle than the middle of the product life cycle. We change the impact of indicators on project assessment by the AHP method at each milestone of the project, so we can not only use the indicator weights to evaluate the advancement of the project, but also integrate the views of systems engineers and project managers. In other words, we consider the systems engineers' and project managers' experiences as an important impact to the project progress evaluation by using the AHP method.

As we have defined the project assessment value above, this section will present how to calculate So at M3, a pairwise comparison matrix ( ) of SE1, SE2 and PM1 ( ) will be given by PM2 in order to calculate their weights on the evaluation and three pairwise comparison matrixes will be given by the three related roles: SE1, SE2 and PM1 to calculate the indicator weights.

For example, those matrixes are as shown in below.

So based on the matrix A, we can have a vector , so the roles weigts on the indicators are:

The following three matrixes, given by respectively SE1, SE2 and PM1 are:

It can be calculated that its maximum eigenvalue is . Using the formula for , we obtain . So the , is less than 0.1, so we consider this matrix is consistent. Thus we get the . The other two As shown in Table VI-4, the first possibility of indexes, we can see even the process A has very high performance evaluation; however the project performance evaluation is not very good because the process B has bigger weight. So from the comparison of the two project index possibilities, we can come to the conclusion that the process weight is very important to evaluate the project progress performance.

By the four performance indexes, we can not only evaluate the process progress, but also can evaluate the project progress. Based on the evaluated result, we can also forecast the trend of the project by simulating the values of the project based on the assumed values of the project by the developed software.

VI.5. Conclusion

This chapter defined indicators and calculated the indicator values with the views of both systems engineers and project managers based on the AHP method (note that stakeholders are free to defining additional indicator). We defined the project assessment values based on the CPM and EVM methods;

we also provide the indexes (PcEPI, PcAPI, PjEPI and PjAPI) on the basis of the adaptive EVM method to help the project managers to gain insight from the project progress easily. These contributions can help integrate not only the general practices from systems engineering and project management by the alignment of standards and guides, but also the systems engineers' and project managers' views of a certain project based on their own practices and knowledge. We provide the four indexes to assess the process and project progress more easily. The assessment of a project by our proposal improves the coverage of the system of indicators and extends it by incorporating specific knowledge from both the project management and the systems engineering sides, to give it the ability to assist in the detection and the anticipation of project deviations. deviations with regard to objective and in taking decisions in order to reorient the project (decisions being taken on the basis of both product and project considerations), to extend project monitoring by management initiatives (Bonjour et Dulmet 2006). If it is necessary to reorient a project, the approach will thus consist in considering several optional scenarios and assessing them, in order that the decision-maker may take corrective measures. The decisions would be substantiated and capitalized in a knowledge base for subsequent use as a reference in similar situations [START_REF] Montmain | Multi-criteria improvement of complex systems[END_REF].

Mechanisms and functions for project risk assessment will be developed for this purpose, to facilitate the assessment and the choice of alternative project management scenarios as well as the expected product architecture. The decision-making process will incorporate knowledge (about the business sector and company) concerning previous products and projects, and will take into account both the maturity and any uncertainty regarding the adequacy of the outcome of the design project compared with client needs and the company's operational, tactical and strategic constraints (Cabannes et al.

2014).

Another open operational perspective is to define a decision-support software tool for managing engineering projects, whose originality will be in that it applies the combined principles of Systems Engineering (SE) and Project Management (PM). The specifications of this tool will be based on surveys of manufacturing companies and conducted with support from the Aerospace Valley competitiveness cluster and the LAAS-CNRS Affiliates Club for the identification of participants and potential interviewees. This tool will incorporate a dashboard for the detection and analysis of discrepancies from objectives, based on capitalized knowledge; it will thus propose assistance for project monitoring and control. l'accélération et l'optimisation du processus de développement, de la conception au prototypage, et même au-delà, dans les phases d'exploitation [START_REF] Jakjoud | SysPEM: Toward a consistent and unified System Process Engineering Metamodel[END_REF] la maîtrise des projets par une réelle coordination des parties prenantes et des processus déployés pour ce développement [START_REF] Bonjour | Modeling interactions to support and manage collaborative decision-making processes in design situations[END_REF],

la prise de décision collective, basée sur des analyses et des prédictions, pour améliorer l'efficacité opérationnelle, limitant ainsi la part d'émotionnel dans les décisions, réduisant les erreurs et dérives, fédérant et motivant les acteurs qui comprennent le sens donné à la décision [5].

Cette thèse s'intéresse au cas des systèmes techniques multi-technologies et considère les étapes de leur cycle de développement. La problématique que nous adressons est un pilotage collaboratif dès les premières étapes, impliquant plusieurs équipes techniques et intégrant toutes les parties prenantes du projet, pour s'acheminer à coup sûr vers le 'bon produit', en maîtrisant les coûts et en respectant les délais [START_REF] Xue | Integrating Systems Engineering with Project Management: a Current Challenge[END_REF]. Des approches et des standards existent (SEBoK [START_REF] Sebok | The Guide to the Systems Engineering Body of Knowledge[END_REF] pour l'IS, PMBoK [START_REF] Pmi | A Guide to the Project Management Body of Knowledge: PMBOK® Guide[END_REF] pour la CP, pour ne citer qu'eux) voire des bonnes pratiques, mais restent souvent trop abstraits ou trop complexes dans leur description pour être facilement applicables, notamment par les ETI et PME [START_REF] Blanchard | Systems Engineering and analysis[END_REF]10,[START_REF]E) -Systems and software engineering -Systems Engineering Lifecycle Profiles for Very Small Entities (VSEs[END_REF][START_REF] Bonjour | Pilotage des activités de conception par l'Ingénierie Système[END_REF].

une insuffisance des procédures de coordination, de traçabilité des décisions intermédiaires,

III. Contributions scientifiques et technologiques de la thèse

La thèse propose de lier les visions et les pratiques de l'Ingénierie Système (IS) et celles de la Conduite de Projet (CP). Le moyen considéré pour cela est de rendre interopérables les processus. Un processus intégré sera proposé, ainsi qu'une démarche pour l'adapter aux différents métiers et types d'entreprises dans un souci que les démarches soient applicables par des ETI et des PME [START_REF]E) -Systems and software engineering -Systems Engineering Lifecycle Profiles for Very Small Entities (VSEs[END_REF]. Sur L'IS propose un ensemble de processus collaboratifs impliquant un grand nombre de métiers et de personnes devant mener à bien des actions concertées et prendre des décisions conjointes et cohérentes [START_REF] Fiorèse | Découvrir et Comprendre l'Ingénierie Système[END_REF]; l'accent est plutôt mis sur les processus techniques et les processus support de l'ingénierie. La CP a pour objectif spécifique de définir la mission et l'organisation, le budget et le planning prévisionnels puis d'assurer la maîtrise opérationnelle du projet [START_REF] Pmi | A Guide to the Project Management Body of Knowledge: PMBOK® Guide[END_REF]. Dans la plupart des cas, même si CP et IS ont l'objectif commun de satisfaire au final le client, la CP est menée en parallèle de l'IS, par des acteurs, avec des indicateurs et des outils différents [START_REF] Blanchard | Systems Engineering and analysis[END_REF][START_REF]INCOSE Systems engineering handbook V3.2: A "How to" Guide for all engineers[END_REF]. L'évidence, pour accroître la compétitivité, est de rapprocher les deux démarches [START_REF] Xue | Integrating Systems Engineering with Project Management: a Current Challenge[END_REF]. La prise de conscience de cet état de fait est récente [13] et la réflexion stratégique en cours sur le plan normatif international pour unifier les deux approches constitue une dynamique porteuse de laquelle se positionne ce travail [START_REF] Sharon | Project management vs. systems engineering management: A practitioners' view on integrating the project and product domains[END_REF]. Le défi est de globale du projet selon trois groupes de processus aux objectifs complémentaires, planifier/exécuter/contrôler (Pl/Ex/Co), qui s'appuient sur une même représentation du projet [18] (Voir Table 1). Les responsables procèdent alors par concertation préalable à la prise de décision, celleci étant diffusée et capitalisée pour pouvoir y faire référence ultérieurement dans un cas similaire, afin de limiter à terme les erreurs et améliorer la décision.

IV. Conclusion

Il s'agit donc d'aller vers des contributions d'abord conceptuelles et ensuite méthodologiques : 1) définir des processus unifiant les points de vue IS et CP en les rendant par définition cohérents, suffisamment génériques pour être applicables à des organisations de taille moyenne ou petite, 2) élaborer un ensemble d'indicateurs types associant les dimensions opérationnelle, technologique, organisationnelle, afin de favoriser le pilotage collaboratif des projets d'ingénierie (cf. Figure 5).

Figure I- 1

 1 Figure I-1 Three proposals of the thesis ............................................................................................

Figure I- 2

 2 Figure I-2 PhD report organisation ....................................................................................................

Figure II- 1 A

 1 Figure II-1 A stove-piped view (Langley, Robitaille, et Thomas 2011) ............................................

Figure II- 2

 2 Figure II-2 Overlaps between SE and PM based on (Kossiakoff et al. 2011) ...................................

Figure II- 3

 3 Figure II-3 An integrated view of project adapted from Figure II-1 (Langley, Robitaille, et Thomas 2011) .........................................................................................................................................................

Figure II- 4

 4 Figure II-4 Systems Engineering applied to the product and to the project (Fiorèse et Meinadier 2012) ........................................................................................................................................................

Figure II- 5

 5 Figure II-5 General context of the thesis ...........................................................................................

Figure II- 6

 6 Figure II-6 The result of the survey (Conforto et al. 2013b) ...........................................................

Figure II- 7

 7 Figure II-7 Three major activities of systems engineering management (Leonard 1999) ...............

Figure II- 8

 8 Figure II-8 Typical project lifecycle structure (PMI 2013) ..............................................................

Figure II- 9

 9 Figure II-9 Simple example of the sequential relationships (PMI 2013) .........................................

Figure

  Figure II-10 Simple example of the overlapping relationship (PMI 2013) .....................................

Figure II- 11

 11 Figure II-11 Simple example of the predictive life cycles (PMI 2013) ...........................................

Figure II- 12

 12 Figure II-12 Simple example of the iterative and incremental life cycles (PMI 2013) ...................

Figure II- 13

 13 Figure II-13 Simple example of the adaptive life cycles (PMI 2013) .............................................

Figure II- 14

 14 Figure Comparison between product lifecycle and project lifecycle[START_REF] Koppensteiner | Process mapping and simulation for software projects[END_REF] ..

Figure II- 15

 15 Figure II-15 Concept of PLM (Mocan et al. 2009) ..........................................................................

Figure II- 16

 16 Figure II-16 Context of Collaborative Engineering .........................................................................

Figure II- 17

 17 Figure II-17 First contribution of our proposal ................................................................................

Figure II- 18

 18 Figure II-18 Shared indicators to assist in the detection and the anticipation of decisions .............

Figure II- 19

 19 Figure II-19 Our proposal methodology ..........................................................................................

Figure III- 1

 1 Figure III-1 SE standards and guides timeline from 1969 onward ..................................................

Figure III- 2

 2 Figure III-2 Hierarchical organization of the ANSI/EIA 632 standard ............................................

Figure III- 3

 3 Figure III-3 Hierarchical organization of the IEEE 1220 standard ..................................................

Figure III- 4

 4 Figure III-4 Hierarchical organization of ISO/IEC 15288 standard ................................................

Figure III- 5

 5 Figure III-5 Hierarchy of the SEBoK standard ................................................................................

Figure III- 6

 6 Figure III-6 The proposal systems engineering processes (Xue et al. 2014) ...................................

Figure IV- 1

 1 Figure IV-1 Five process groups of PMBoK (PMI 2013) ...............................................................

Figure IV- 2

 2 Figure IV-2 Structure of PMBoK ....................................................................................................

Figure IV- 3

 3 Figure IV-3 The mapping table of processes (PMI 2013) ...............................................................

Figure IV- 4

 4 Figure IV-4 Structure of ISO 21500 ................................................................................................

Figure V- 1

 1 Figure V-1 Structure of ISO/IEC 15288 ..........................................................................................

Figure V- 2

 2 Figure V-2 Structure of PMBoK ......................................................................................................

Figure V- 3

 3 Figure V-3 Relationship between planning process groups and 10 Knowledge Areas ...................

Figure V- 4

 4 Figure V-4 Relationship between the monitoring and controlling process group and 10 Knowledge Areas.......................................................................................................................................................

Figure V- 5

 5 Figure V-5 Comparison between ISO/IEC 15288 and PMBoK at the first level ............................

Figure V- 6

 6 Figure V-6 Process relationship between ISO 15288 and PMBoK .................................................

Figure V- 7

 7 Figure V-7 Match between the three levels of both references .......................................................

Figure V- 8

 8 Figure V-8 Major time considerations for ISO/IEC 15288 .............................................................

Figure V- 9

 9 Figure V-9 Major time considerations for PMBoK .........................................................................

Figure V- 10

 10 Figure V-10 Some time considerations for ISO/IEC 15288 and PMBoK .......................................

Figure V- 11

 11 Figure V-11 The proposed method of harmonization of PM and SE processes ..............................

Figure V- 12

 12 Figure V-12 Alignment of the PMBoK and ISO/IEC 15288 (Xue et al. 2015) ...............................

Figure V- 13

 13 Figure V-13 Regrouping processes from the PMBoK .....................................................................

Figure V- 14

 14 Figure V-14 Structure of ISO/IEC 29110 ........................................................................................

Figure VI- 2

 2 Figure VI-2 The steps of the CPM approach ...................................................................................

Figure VI- 3

 3 Figure VI-3 Example of the EVM data resources (Art Gowan, Mathieu, et Hey 2006) .................

Figure VI- 4

 4 Figure VI-4 The implementation of our proposal ............................................................................

Figure VI- 5

 5 Figure VI-5 Gantt chart of the example project ...............................................................................

Figure VI- 6

 6 Figure VI-6 The PERT chart of the example project .......................................................................

Figure VI- 7

 7 Figure VI-7 The schematic of the adaptive AHP method ................................................................

Figure VI- 8

 8 Figure VI-8 The AHP method in our proposal-2 ...........................................................................

Figure VI- 9

 9 Figure VI-9 An example of transferring the values of indicators to a common scale between 0 and ..............................................................................................................................................................

Figure VII- 1

 1 Figure VII-1 Our future work related to this thesis .......................................................................

1

 1 Comparison the tasks between project managers and program managers ..................... Table III-1 Systems engineering standard differences (Sheard et Lake 1998) ............................... Table III-2 Analysis of references to the three new criteria ............................................................Table III-3 Full Comparison of standards ....................................................................................... Table III-4 Comparison between the five SE standards and guides ............................................... Table IV-1 Comparison between the two project management references..................................... Table IV-2 Corresponding between the structures of the two references ....................................... Table IV-3 Differences and similarities between PMBoK and ISO 21500 (PMI 2013) ................. Table V-1 International references by category .............................................................................. Table V-2 Process component (ISO/IEC 2008) .............................................................................. Table V-3 Ten knowledge areas of PMBoK (PMI 2013) ............................................................... Table V-4 Five process groups (PMI 2013) .................................................................................... Table V-5 Matching items between ISO/IEC 15288 and PMBoK ................................................. Table V-6 Relationships between ISO/IEC 15288 and the PMBoK............................................... Table V-7 Focus on different systems in ISO/IEC 15288 and PMBoK ......................................... Table V-8 The result of the harmonization of the PM and SE processes ....................................... Table VI-1 The indicators' weights of process A .......................................................................... Table VI-2 The original indicator values of process A ................................................................. Table VI-3 The adaptive indicator values of process A ................................................................ Table VI-4 Comparison of two possibilities of the project index .................................................

  Figure I-1 Three proposals of the thesis

Figure

  Figure I-2 PhD report organisation

  Figure II-1): different persons, different tools, and different processes. Professionals from each domain usually apply different approaches based on their own practices, which might delay success. For many years, a cultural barrier has been growingbetween practitioners of SE and of PM leading them to consider their respective work as separate rather than integrated towards a common objective, that of satisfying the end user[START_REF] Langley | Toward a New Mindset: Bridging the Gap Between Program Management and Systems Engineering[END_REF]. As a result, work is often more costly, takes more time to be completed and provides a suboptimal solution to the customers[START_REF] Langley | Toward a New Mindset: Bridging the Gap Between Program Management and Systems Engineering[END_REF].

Figure II- 1 A

 1 Figure II-1 A stove-piped view (Langley, Robitaille, et Thomas 2011)

Figure II- 2

 2 Figure II-2 Overlaps between SE and PM based on (Kossiakoff et al. 2011) It is thus essential for a successful project execution in this fast-paced and continuously changing world to explore the similar or complementary aspects of SE and PM functions and activities, and to share skills and experiences (see Figure II-3).

Figure II- 3

 3 Figure II-3 An integrated view of project adapted from Figure II-1 (Langley, Robitaille, et Thomas 2011)

Figure II- 4

 4 Figure Engineering applied to the product and to the project[START_REF] Fiorèse | Découvrir et comprendre l'ingénierie système[END_REF]

  (ISO/IEC 2008) [START_REF] Laporte | International systems and software engineering standards for very small entities[END_REF] (Bonjour et Dulmet 2006). So the goal of this thesis is to integrate System Engineering (SE) practices (whose objective is the operational performance of the technical product) and Project Management (PM) practices (whose objective is the supervision and optimization of the implementation of the engineering process) at the earliest possible stage, to facilitate their adoption and their joint deployment within the company, in order to improve decision-making in engineering projects.The context of the problem is as shown inFigure II-5. This thesis is at the intersection of three domains in the context of Collaborative Engineering (CE): Systems Engineering (SE), Project Management (PM) and Decision Making (DM), with a focus on the intersection between SE and PM.

Figure II- 5

 5 Figure II-5 General context of the thesis

  October 2012, INCOSE and PMI conducted a survey to better understand the responsibilities of systems engineers and project managers and understand how PM and SE are lead and could be integrated within the organizations. The Consortium for Engineering Program Excellence (CEPE), set up at the Massachusetts Institute of Technology (MIT), provided a method to analyze, review and finalize the results of the joint survey (based on a panel of 680 chief systems engineers and program managers) (Conforto et al. 2013).

Figure II- 6

 6 Figure II-6 The result of the survey (Conforto et al. 2013b) As shown in Figure II-6, four options were put forward to reduce unproductive tension between systems engineers and project managers. The first option makes use of standards from both domains, but no SE standard really fit with the PM standards. The second consists in formalizing the integration of SE and PM. The survey emphasizes the fact that the degree of formalization of integration depends on company size. The third option suggests developing integrated engineering program assessments.

Figure II- 7

 7 Figure II-7 Three major activities of systems engineering management (Leonard 1999)

  Figure II-8 Typical project lifecycle structure (PMI 2013)

  Figure II-10) (PMI 2013).

Figure II- 9

 9 Figure II-9 Simple example of the sequential relationships (PMI 2013)

Figure II- 11

 11 Figure II-11 Simple example of the predictive life cycles (PMI 2013)

Figure II- 12

 12 Figure II-12 Simple example of the iterative and incremental life cycles (PMI 2013) -Adaptive life cycle: This method allows the project split up into phases or iterations which can be sequential or overlapping. However, because adaptive life cycles are used in applications areas such as Information Technology (IT) where there is a rapid change, sometimes the processes within the iterations can even be going on in parallel. Like the iterative and incremental life cycle, the detailed scope is only determined ahead of a time for the current iteration or phase of the project. The phases or iterations are more rapid than in the iterative and incremental life cycle, however, usually with a duration of 2 or 4 weeks. During the iteration, the scope is decomposed into a set of requirements (deliverables) and the work to be done to meet those requirements (often called the product backlog) is prioritized. At the end of the iteration, the work on the product is reviewed by the customer, and the feedback from the customer is used to set the detailed scope of the next iteration (PMI 2013).

Figure

  Figure II-13 Simple example of the adaptive life cycles (PMI 2013)

Figure II- 14

 14 Figure II-14 Comparison between product lifecycle and project lifecycle (Koppensteiner 2008) As shown in Figure II-14, the project lifecycle has to be applied to the product development and the product adaptation phases. But the product development phase is completed when the product is delivered to the market.

  as shown in Figure II-15.

Figure

  Figure II-15 Concept of PLM[START_REF] Mocan | Product life management system in digital manufacturing environement[END_REF]

Contribution 1 :

 1 To propose a process framework integrating SE and PM, defining and structuring useful activities to provide support for the organization of a technical systems engineering project. It will involve bringing SE and PM closer together, harmonizing the way each describes the processes to be implemented during the design stage, which is a strategic need highlighted by the joint study by the MIT for the INCOSE and the PMI.

  engineering application whose development is outside the scope of the work. The steps of the first contribution are given in Figure II-17.

Figure

  Figure II-17 First contribution of our proposal Contribution 2: To deepen the concept of indicators and ensure that it is shared between the disciplines concerned. Define the key indicators for stakeholders, including the monitoring of

  The monitoring proposed by this proposal improves the coverage of the system of indicators and extends it by incorporating specific knowledge from the project management or the engineering sides (proven process patterns from which it would be preferable to draw inspiration, business rules), to give it the ability to assist in the detection and the anticipation of deviations. The definitions of the shared indicators are as shown in Figure II-18, they are the basis of the third contribution.

Figure

  Figure II-18 Shared indicators to assist in the detection and the anticipation of decisions Contribution 3: Define the mechanisms to assess the project progress based on the shared indicators

Figure

  Figure II-19 Our proposal methodology

Figure III- 1

 1 Figure III-1 SE standards and guides timeline from 1969 onward ISO/IEC 15288 was published by the International Organization for Standardization (ISO). Known as "Systems and software engineering-System life cycle processes" it focuses on processes for engineering a system throughout its full life cycle.

Figure III- 2

 2 Figure III-2 Hierarchical organization of the ANSI/EIA 632 standard As shown in Figure III-2, ANSI/EIA 632 organizes processes into 5 groups. The Technical Management process group is related to the project management aspect and includes the Project Management Process (PMP). Although it defines some processes about project management, these

  IEEE 1220 standard was first published in 1995. The first version was initially published in January 1995 as a trial use standard, and updated in 1998 and 2005. It focuses on technical processes

  Figure III-3 shows the structure of the IEEE 1220 standard; note that it considers the context of the system and defines the systems engineering management plan. The use of this standard in complement to the ISO/IEC 15288 standard and the differences between the two standards are also addressed. This standard defines the requirements for an enterprise's total technical effort related to development of products and processes that will provide life cycle support for products. The latest version defines 14 requirements, 8 processes in total. Most requirements and processes are related to the technical aspect of SE. Compared with the ANSI/EIA 632 and ISO/IEC 15288, it intends to define SE processes at a high level of detail. It also includes the systems' entire life cycle, but focuses on conception, development and production. It offers one process only, the Quality Management requirement that belongs to PMP.

Figure III- 3

 3 Figure III-3 Hierarchical organization of the IEEE 1220 standard As shown in Figure III-3, this standard is not organized into process groups. The structure of this standard is not similar to the others. It defines 6 stages for systems engineering, but a close look at the definition of those stages shows that it defines the same systems life cycle as ISO/IEC 15288. Its most

Figure III- 4

 4 Figure III-4 Hierarchical organization of ISO/IEC 15288 standard As shown in Figure III-4, ISO/IEC 15288 defines 4 process groups for the areas of agreement, enterprise, project and technical aspects. The Enterprise Processes and Project Processes groups lead to a partial overlap with project management processes. This standard defines more PMPs than ANSI/EIA 632. But it suffers from the same drawback in that it fails to provide or specify systems engineering methods or procedures to address detailed process requirements for the application of this standard.

Figure III- 5

 5 Figure III-5 Hierarchy of the SEBoK standard As shown in Figure III-5, there are five process groups in this guide, the fifth one being SystemsEngineering Management. So there are identical processes, such as systems implementation process, system integration process and system validation process. All technical processes contained in

  process, we propose to complete it with elements from the ISO/IEC 15288 standard. The final architecture of systems engineering processes is shown in FigureIII-6; the processes that are underlined are selected from ISO/IEC 15288, the others come from ANSI/EIA 632.

Figure III- 6

 6 Figure The proposal systems engineering processes(Xue et al. 2014)

------

  and differences among SE standards to help individuals and organizations in charge of SE understand them and to determine the one most likely to be most useful. The study was conducted in 1998; at that time, the SE available standards were the MIL-STD-499B, EIA/IS-632:1994, IEEE-1220, ANSI/EIA 632 (the ballot version in January 1998) and ISO/IEC 15288 (Working Draft #2 in January 1998). They compared these standards according to four classical criteria: scope of standard, level of abstraction, systems life cycle and Systems Engineering Management Plan (SEMP) guidance. Since then, the ANSI/EIA 632, IEEE 1220 and ISO/IEC 15288 standards have been updated, and two additional guides, the INCOSE SE HANDBOOK and SEBoK, have been published, but no recent research analysis can be found comparing them. Our comparison is based on the latest versions of ANSI/EIA 632, IEEE 1220, ISO/IEC 15288, the INCOSE SE HANDBOOK and SEBoK. To analyze these references, eight criteria have been retained, to refine the set of 3 criteria defined by Sheard and Lake: Content: this criterion describes the number of processes defined by the reference and how they are pooled together; Focus on the systems life cycle: which stages of systems' life cycle the reference focuses on and coverage of the systems' life cycle in each standard or guide; -Number of pages; -Level of details: shows how detailed the reference which introduces the processes or requirements is; Context of application: this criterion is used to specify the environment to which the reference is related, such as the program environment, enterprise environment and the external environment; Year of publication; Revision frequency; Number of management processes: how many processes (in ANSI/EIA 632 and IEEE 1220, processes are referred to as requirements) related to management are included in the reference;

  Figure IV-1); any set of processes can also be reused for any stage of SE.

Figure IV- 1

 1 Figure IV-1 Five process groups of PMBoK (PMI 2013)As a result, the project management Process Groups and Knowledge Areas are structured this way

  The five process groups can be used at any stage or sub-project or throughout the project. Each process contains the purpose, input and output (deliverable, a result, a document).The structure of ISO 21500 is shown in Figure

Figure IV- 4

 4 Figure IV-4 Structure of ISO 21500

Figure V- 1

 1 Figure V-1 Structure of ISO/IEC 15288 Each process is composed of three parts: purpose, outcomes and tasks & activities; the descriptions of the three parts are as shown in Table V-2.

Figure

Figure V- 3

 3 Figure V-3 Relationship between planning process groups and 10 Knowledge Areas After analyzing parts of the two process groups, we found that all the process in Figure V-3 of PMBoK can be found in the project planning process of ISO/IEC 15288. The processes of monitoring and controlling process group in Figure V-4 can be found in the Project Assessment and Control Process of ISO/IEC 15288.

Figure V- 4

 4 Figure V-4 Relationship between the monitoring and controlling process group and 10 Knowledge Areas After aligning the two process groups of PMBoK to the two processes of ISO/IEC 15288, we compare all the processes of ISO/IEC 15288 to the 10 Knowledge Areas of PMBoK. This comparison is based on ISO/IEC 15288; so, Figure V-5 highlights those parts of the PMBoK covered or not covered by said standard. If a knowledge area in the longer dashed rectangle, it means that this knowledge area is only partially covered by ISO/IEC 15288. If it is in the solid rectangle, it means that the whole knowledge area can be found in said standard.

Figure V- 5

 5 Figure V-5 Comparison between ISO/IEC 15288 and PMBoK at the first level

  Figure V-6 Process relationship between ISO 15288 and PMBoK

Figure V- 7

 7 Figure V-7 Match between the three levels of both references In Figure V-7, it can be seen that there is a direct match between tasks and activities of ISO/IEC 15288 and processes from PMBoK, which are other, in the structures of standards, at the same level of decomposition. Now, the 25 processes of ISO/IEC 15288 can be compared to the 10 knowledge areas of the PMBoK even if the numbers of processes and knowledge areas are not the same. The five process groups of the PMBoK are similar to the tasks and activities of ISO/IEC 15288.

Figure V- 8

 8 Figure V-8 Major time considerations for ISO/IEC 15288

Figure V- 10

 10 Figure V-10 Some time considerations for ISO/IEC 15288 and PMBoK

  4.3, we propose a structuration of processes into three process groups, aiming at planning, executing and controlling, as shown in Figure V-11.

Figure V- 11

 11 Figure V-11 The proposed method of harmonization of PM and SE processes

Figure V- 13

 13 Figure V-13 Regrouping processes from the PMBoK

  1) Overview (ISO/IEC TR 29110-1), 2) Framework and taxonomy (ISO/IEC TR 29110-2), 3) Assessment guide (ISO/IEC TR 29110-3), 4) Profile specification (ISO/IEC TR 29110-4) and 5) Management and engineering guide (ISO/IEC TR 29110-5). The fifth part deals about implementation management and engineering guide for the small entities. This guide is suggested to be used with some project management and software implementation processes and outcomes from the standard ISO/IEC 12207 and products from ISO/IEC 15289 (ISO 2011). Based on the purpose and the character of ISO/IEC 29110, this standard is better for VSEs because of their features and flexibility. The VSEs also can select the processes from another standard based on the projects, for example the ISO/IEC 12207, ISO/IEC 15288 and ISO/IEC 15289.

Figure

  Figure V-14.

Figure V- 14

 14 Figure V-14 Structure of ISO/IEC 29110

  , the indicators have three types of values: planned value, actual value and earned value. -Planned value (PV): the budget (or planned) value of work scheduled -Actual value (AV): the actual value of work completed -Earned value (EV): the "earned value" of the physical work completed

Figure VI- 2

 2 Figure VI-2 The steps of the CPM approach

Figure VI- 3

 3 Figure VI-3 Example of the EVM data resources (Art Gowan, Mathieu, et Hey 2006)

Figure VI- 4

 4 Figure VI-4 The implementation of our proposal As shown in Figure VI-4 there are 13 common steps of our proposal. 1) Start the project and do some necessary work, such as sign the contact. 2) Define the project phases and processes according to the project stakeholders. 3) Give the initial indicator values of all the processes. Then we use our combined methodology at the beginning of each phase of the project until the project is finished. 4)Define the processes required by this phases. 5) We find the critical path of processes which means that processes must be started and finished on time of this phase based on the CPM method. 6) Calculate the process weight based on the CPM method. 7) Give the pair wise comparisons of the five indicators both by systems engineers and project managers based on the AHP method. 8) Calculate the weights of

Figure VI- 5

 5 Figure VI-5 Gantt chart of the example project

  steps above, we can get each weight value of the process, and it is obvious that the weigh is more related to the flexible time that the processes have beginning time and the duration of the process. All the processes in the critical path have the greatest values because they must be started and finished on time and they do not have flexible time. The methodology of defining weights based on CPM method is shown in Figure VI-6. The processes that have the same flexibility of time schedule at the same zone have the same weights. The processes of the critical path have the highest weights and the values are same. The processes that have the same difference of duration have the same weights. Let us consider the example project to calculate the process weight based on the CPM method. The PERT chart (Program Evaluation and Review Technique) of the example project is as shown in Figure VI-6.

Figure VI- 6

 6 Figure VI-6 The PERT chart of the example project Based on the CPM method, the B and D processes are critical processes; we thus can get the values as follows:

  the indicator weight based on the AHP method under an integrated view of systems engineers and project managers. The methodology is as shown in Figure In our context, we consider the project as the goal at the top level. It is obvious that the system engineers' and project managers' experiences should be taken into account for the project progress evaluation, so they are located at the intermediate levels. A line connecting two elements makes the existence of a relation of hierarchical dependence between them. So according to the AHP method, we can calculate the weights of the indicators based on the collaborative view of systems engineers and project managers. It is as shown in Figure VI-7. The systems engineers and project managers can have different impact to the indicator weight based on their experiences.

Figure VI- 7

 7 Figure VI-7 The schematic of the adaptive AHP methodLet us continue to take the same simple example as before to explain how to use this method to calculate the indicators' weights under the integrated view. In this explanation, we only consider the five core indicators of the four processes (A, B, C, D) as we defined before. This project has two phases, so we consider the project consists of five milestones (M1, M2, M3, M4 and M5). M1is at the beginning of the phase 1; M2 is at the middle of phase 1 and M3 is at the end of phase 1; M4 is at the middle of phase 2 and M5 is at the end of project. At each milestone, in order to calculate the indicator weights, each of the systems engineers and project managers who take part in the phase should establish relative priorities among the indicators. Here we will take the M3 as an example milestone to explain how to implement the AHP method to evaluate the indicator weight of process A. We only consider the related roles: SE1, SE2 and PM1. But it is worth noting that we need to analyze the positions of the three different roles. For example, based on the hierarchical organization of the company and the size of the project, a pairwise comparison matrix (A) of SE1, SE2 and PM1 was given by the previous project managers (PM2), as shown in Figure In fact, the relative weights of SEi and PMi could be on the basis of other features of the project.

Figure VI- 8

 8 Figure VI-8 The AHP method in our proposal-2

Figure VII- 1

 1 Figure VII-1 Our future work related to this thesis A methodological extension of this work is to propose support for decision-makers in diagnosing

  Dans un contexte économique très compétitif, les entreprises doivent améliorer leur performance dès les premières étapes de la conception du produit, dont l'impact sur l'ensemble du cycle de vie du produit est primordial. Cette thèse a pour objectif d'intégrer au plus tôt les pratiques de l'Ingénierie Système (IS) (dont l'objectif est la performance opérationnelle du produit technique) et de la Conduite de Projet (CP) (dont l'objectif est la supervision et l'optimisation de la mise en oeuvre du processus d'ingénierie), de faciliter leur adoption et leur déploiement conjoint en entreprise, afin d'améliorer la prise de décision dans les projets d'ingénierie. En effet, l'organisation de l'entreprise induit souvent une ségrégation entre CP et IS, ce qui a pour résultat des prises de décision parfois peu cohérentes et peut nuire à la réalisation du projet, alors que, tout en ayant des visions et des cibles spécifiques, ces disciplines servent néanmoins un objectif commun, celui de satisfaire le client[START_REF] Conforto | Survey Re-port: Improving Integration of Program Management and Systems Engineering[END_REF]. De ce fait, les pratiques et outils de CP et d'IS cohabitent encore mal dans l'environnement économique actuel. La coordination des pratiques dans les projets d'ingénierie est ainsi une des voies d'amélioration de la compétitivité des entreprises[2], s'appuyant sur :

  d'argumentaires classés et accessibles,un problème d'interopérabilité des méthodes et outils en interne à l'entreprise et en relations externes(conseils, fournitures, sous-traitances, donneurs d'ordre, partenaires).Cependant, dans le développement de systèmes complexes, l'enjeu consiste à trouver le bon équilibre entre coûts, délais et performance, cette performance intégrant des aspects économiques, sociaux et environnementaux. L'ingénieur est traditionnellement en charge de la performance technique et le manager responsable des coûts, des délais et des indicateurs d'impact à connaître dans le cadre de la RSE (Responsabilité Sociétale des Entreprises), il est primordial que chacun comprenne l'impact de ses décisions sur l'autre, afin de maîtriser de potentiels dépassements de coûts par exemple et, au-delà, d'être en mesure de procéder à des optimisations de ces coûts. Sachant que le coût résulte majoritairement de la conception du système et de sa performance, nombreuses sont les sources de conflits d'intérêts entre l'ingénieur et le manager, impactant directement les délais de livraison du système et les bénéfices du projet.Toutes ces difficultés de terrain expliquent que des progrès importants de performances de conduite du projet et de qualité du produit se trouvent dans l'amélioration de ces procédures. Il y a donc beaucoup à innover pour mettre pleinement en oeuvre toutes les recommandations de l'Ingénierie des Systèmes et les composantes utiles du PMBoK et parfaire leur coordination : la réflexion de cette thèse part du constat d'un besoin d'harmonisation mais surtout de rapprochement entre les démarches, ce qui est un sentiment de plus en plus partagé au sein même des sociétés savantes des domaines invoqués, et par l'identification de certains points faibles déjà largement évoqués (exigences, indicateurs, diagnostic et décisions, interopérabilité). La situation dans les PME est sensiblement différente : les technologies sont plus ciblées et les projets moins complexes. En conséquence les besoins méthodologiques et les outils sont orientés vers la compatibilité aux exigences d'échanges avec l'environnement notamment des partenaires et des clients et vers la simplicité d'usage. Cette exigence de simplicité est essentielle car elle permet une assimilation rapide des procédures et des échanges plus aisés entre tous les acteurs. Par rapport à cet état de l'art, nous avons voulu élargir l'étude à des pistes qui nous semblaient intéressantes, comme celle qui consiste à favoriser l'aide à la prise de décision partagée dans un contexte d'ingénierie collaborative, ou celle consistant à favoriser l'émergence d'indicateurs. Cette thèse répond ainsi à un enjeu important et un besoin plus ou moins satisfait en conception de produits et ingénierie des systèmes. En effet, si on regarde les projets menés dans ce domaine, la plupart sont dédiés à certains domaines comme le bâtiment (COMIS, VBD, CANOPEE, MEFISTO) ou l'ingénierie numérique, notamment les réseaux (CBOD, DOKKA, OPIMPUC, COCORAM, MODECOL, Spacify, PI-NUTS). Nous remarquons qu'il y a peu de projets concernant l'ingénierie des systèmes techniques et même que ces projets se concentrent sur certains aspects comme la performance en termes de sécurité (BioPriv, IMOFIS, VACSIM), la production énergétique (CHWWEPS, INTENSE, OMEGA) ou encore la mécanique (IPPOP). Certaines études ont été menées pour le développement ou la combinaison des techniques pour l'ingénierie des systèmes comme par exemple, les études comparatives de production entre l'Allemagne et la France (projet COMPNASTA) ou le laboratoire LARIOPAC, pour étudier les enjeux en techniques de coupe. Cependant, nous observons plusieurs travaux sur le développement de plateforme de conception de logiciels numériques (MyCitizSpace, FORMOSE). Peu de ces travaux sont étendus pour aborder la conception des systèmes techniques avec les enjeux qui leur sont propres comme le choix des composants et leur influence sur l'environnement, les spécifications comportementales et leur simulation, la gestion des indicateurs de performance technique et environnementale, etc. Citons néanmoins des travaux dans ce cadre mais dans le domaine de l'urbanisme (GEODD, ANNONA, PLUMES). Cette analyse de l'existant : méthodes, outils, pratiques et besoins, domaines d'application, montre l'intérêt de proposer des démarches nouvelles qui corrigeront les défauts et insuffisances des pratiques actuelles. Ces propositions doivent être le plus compatibles possible avec l'existant, rajouter des analyses et des outils sur les points délicats, favoriser la construction, à terme, d'un outil nouveau, ergonomique, utilisable, centré sur les notions de supervision et de coordination et laissant leurs places aux outils de terrain couramment utilisés dans les entreprises.

  cette base de processus coopérants, nous voulons définir des indicateurs et des mécanismes supports d'aide à la décision qui permettent aux décideurs (techniques et managers) de superviser et piloter de façon conjointe le projet et le développement du système technique.

  considérer le projet comme un système sociotechnique global où les interactions entre la mise en oeuvre, la conduite de projet et l'organisation sont traitées conjointement. Pour aller dans cette voie, nous proposons trois objectifs, que nous déclinons en trois propositions qui sont au coeur du développement de notre thèse.Un premier objectif est de travailler à l'harmonisation des processus de CP et d'IS. Une analyse comparée des processus identifiera les principaux écarts dans leurs descriptions, les rôles participant à l'un et/ou l'autre et proposera des aménagements pour rendre ces processus plus opérationnels en les rendant coopératifs dans la pratique, avec une recherche et une définition des liens qu'il convient d'établir entre eux. Ceci est un préalable et une condition de succès dans la recherche d'un processus intégrant IS et CP : passer par une harmonisation des processus est en effet l'un des moyens suggérés pour rapprocher les démarches. Sur la base d'un état de l'art académique, normatif et des pratiques industrielles, une option avait déjà été identifiée dans des travaux antérieurs (projet ANR ATLAS[START_REF]Aides et assisTances pour la conception, la conduite et leur coupLage par les connAissanceS[END_REF]) ; elle consistait en une description parallèle et récursive des systèmes en sous-systèmes et des tâches associées, coordonnant structure produit et activités projet par un modèle décisionnel associant les responsables des deux disciplines. Une piste envisagée à présent consiste à répartir la responsabilité

Figure 3

 3 Figure 3 La démarche de la première contribution Contribution n°1 : Proposer un processus intégrant IS et CP, définissant et structurant les activités utiles en fonction de la taille de l'entreprise, enrichissant éventuellement les activités définies par les normes pour s'adapter aux besoins exprimés par les entreprises, gérant l'interdisciplinarité, permettant d'aider à organiser un projet d'ingénierie de systèmes techniques. Il s'agira de favoriser le rapprochement entre l'IS et la CP, en harmonisant leurs descriptions des processus à mettre en oeuvre durant l'ingénierie, besoin stratégique souligné par l'étude conjointe menée par le MIT pour l'INCOSE et le PMI [13].

Figure 4

 4 Figure 4 les cinq indicateurs clefs Un troisième objectif consiste, sur la base des évaluations et informations remontant des contributions 1 et 2, à proposer aux décideurs de l'aide pour diagnostiquer ces dérives ou opportunités et prendre des décisions afin de réorienter le projet (décisions concernant à la fois le produit et le projet), pour prolonger le suivi de projet par des actions de pilotage [28]. Des méthodes (AHP, CPM et EVM) d'analyse (évaluation et d'interprétation des risques et opportunités) seront proposées, qui

Figure 5 .

 5 Figure 5. Positionnement de la thèse

  concept of software engineering emerged with the development of computer science. It was first used by Anthony Oettinger and then used by Margaret Hamilton in 1968 as a title for the world's

	first conference on software engineering. Many organizations give different definition of the software
	engineering. Let us give the ones from ISO/IEC/IEEE std 24765:2012 and IEEE std 610.12-1990.
	Definition: The systematic application of scientific and technological knowledge, methods, and
	experience to the design, implementation, testing, and documentation of software (ISO/IEC/IEEE
	2012).

Table II -

 II 1 Comparison the tasks between project managers and program managers So far, many standards exist for program management. For example, the PMI published a standard for program management in June of 2006, the latest version being issued in 2013; it has been recognized by the American National Standards Institute (ANSI) as an American National Standard.

	Project managers	Program managers
	Focus on content	Focus on context
	Manage projects	Manage portfolios of projects
	Focus on scope, schedules, resources	Focus on people, politics and negotiating
	Perform more technical tasks	Perform more strategic tasks
	Handle risk management	Handle change management (program and
	Deal with project requirements	environmental changes)
	Are responsible for ensuring projects to get	Deal with business strategies and objectives
	completed on time, within budget	Are responsible for maximizing ROI and
		value delivery

Table III

 III

	-1 Systems engineering standard differences (Sheard et Lake 1998)
	ANSI/EIA632	ISO/IEC 15288	IEEE 1220

Table III

 III

		-2 Analysis of references to the three new criteria
		ANSI/EIA 632:	ISO 15288	IEEE 1220
	Validation	Gives more details about validation:	Requirement validation	End product
		requirement validation; solution		validation
		representations, end products validation
	Verification	Gives more details about verification: design	Function verification	Design
		solution verification; end product		verification
		verification; enabling product readiness
	Internal	Highest, gives the relationship between the	Higher than IEEE 1220	Lowest
	consistency	processes, activities

  Table III-3 combines Table III-1 and Table III-2, and shows the coverage (colored portion) of our criteria by the different standards.

Table III

 III

			Gives more details about
	Verification	verification: design solution and end product verification;	Function verification	Design verification
			enabling product readiness
	Internal consistency		Highest, gives the processes, activities relationship between the	Higher than IEEE 1220	Lowest
			-3 Full Comparison of standards
			ANSI/EIA 632	ISO/IEC 15288	IEEE 1220
			Defines 5 process groups, a		Defines 14 general
			total of 33 requirements for	Defines 3 concept groups and	requirements for developing
	Scope of standard		13 processes, gives tasks and outcomes for each requirement, gives some	4 process groups, 25 system life cycle processes, gives the purpose, tasks and outcomes	a total system, gives 8 sub processes for one systems engineering process, gives
			application context and key	for each process	the tasks and activities for
			concepts		each sub process
	System life cycle		Assessment of opportunities Investment decision System concept development Subsystem design and pre-deployment Development, operations, support and disposal	Conception Development Production Utilization Support Retirement	System definition Preliminary design Detailed design FAIT Production Support
	Level of detail of the processes	Higher level than ISO/IEC 15288, lower than IEEE 1220	Lowest level	Highest level
					The engineering activities
	Focal point		Enterprise-based systems	Product-oriented systems	necessary to guide product
					development
			Gives more details about
			validation: requirement
	Validation		validation; solution	Requirement validation	End product validation
			representations, end product
			validation

Table III

 III

		-4 Comparison between the five SE standards and guides
		ANSI/EIA 632	ISO/IEC	IEEE 1220	INCOSE	SEBoK
			15288		HANBOOK
	Content of	13 processes	25 processes	8 processes	25 processes	26 processes
	standard	34 requirements
	Focus on systems'	Conception and	systems'	systems' entire	' systems'	systems' entire
	life cycle	development	entire life	life cycle	entire life cycle	life cycle
			cycle
	Number of pages	110	70	70	400	850
	Level of details
	Context of	Program and	Enterprise	Program and	Enterprise	External
	application	project	environment	project	environment	environment
		environment		environment
	Year of	1998	2015	2005	2010	2013
	publication
	Revision
	frequency
	Number of SEMP	3	12	1	12	12
	SEMP's	3/13	12/25	1/14	12/25	12/26
	proportion

  : ANSI/EIA 632, ISO/IEC 15288, ISO 1220, INCOSE SE HANDBOOK and SEBoK and we considered two different approaches to reach our objectives: one is to use a multi-standard to integrate SE with PM, another one Method (CPM), the Work Breakdown Structure (WBS) and the Earned Value Management (EVM)[START_REF] Maserang | Project Management: Tools & Techniques[END_REF] are well-known tools. If some methods for developing systems are easier to manage than others and some more likely to succeed, particularly in large-scale projects, using project management references, standards or compendiums of good practices, is also a way to support and guide project management(Xue et al. 2014) [START_REF] Munns | The role of project management in achieving project success[END_REF]. The first PM reference was the PMBoK Guide, a Guide to the Project Management Body of Knowledge; it was published by Project Management Institute (PMI) in 1987; the fifth version was edited in 2013[START_REF] Pmi | A Guide to the Project Management Body of Knowledge: PMBOK® Guide[END_REF]. The ISO 21500Standard for Project Management is a standard developed by ISO (International Organization for Standardization) from 2007, later released in the September 2012 (ISO 2012). For project managers, determining which standard or guide is more suitable for their projects means spending a lot of time to read, analyze and compare these two references. So the purpose of this chapter is to proceed to such an analysis and to compare the two project management standards or guides in order to integrate with the ISO/IEC 15288 on the behalf of systems engineering domain.

Table IV -

 IV 1 Comparison between the two project management references

		PMBoK	ISO 21500
	Processes of references	47 processes	39 processes
	The target audience	Any company	Any company
	Level of details
	Proposition on tools and	Yes	No
	techniques
	Year of publication	2013	2012
	Revision frequency

Table IV -

 IV 3 Differences and similarities between PMBoK and ISO 21500[START_REF] Pmi | A Guide to the Project Management Body of Knowledge: PMBOK® Guide[END_REF]

		PMBoK	ISO 21500
	The same processes emerge in both	27	27
	references
	The process replaced	1	1
	The process combined	14	5
	The process rewritten	3	4
	The processes only emerges in	2	_
	PMBoK
	The processes only emerges in ISO	_	2
	21500
	Total	47	39

Table V -

 V

1):

Table V

 V

		-1 International references by category
	Category	Description	Popular standard or reference
	Product standards or	Characteristics related to quality and	ISO 9001 Quality Management
	guides	safety	Systems
	Process standards or	Conditions under which products and	ISO/IEC 15288 systems and software
	guides	services are produced or packaged	engineering -system life cycle
			processes
	Project management	Helps organizations to manage their	PMBoK
	standards or guides	operations or project

Table V -

 V 4 Five process groups (PMI 2013)

	Group	Description
	Initiating	Defining a new project or a new phase of an existing project by obtaining
		authorization to start it
	Planning	Establishing the scope of the project and defining the objectives and the
		course of action required to reach the objectives
	Executing	Completing the work defined in the project management and planning to
		satisfy the project specifications
	Monitoring & Controlling	Reviewing and regulating the progress of the project; identifying any areas
		in which changes to the plan have to be made and initiating the
		corresponding changes
	Closing	Finalizing all activities across all Process Groups to formally close the
		project

Table V -

 V 5 Matching items between ISO/IEC 15288 and PMBoK

	Quality Management Process	Quality
	Project Planning Process
	Project Assessment and Control Process
	Configuration Management Process
	Human Resource Management Process	Human Resource
	Configuration Management Process
	Information Management Process	Communications
	Measurement Process
	Configuration Management Process
	Risk Management Process	Risk
	Configuration Management Process
	Acquisition Process	Procurement
	Supply Process
	Configuration Management Process
	Decision Management Process
	Configuration Management Process
	ISO/IEC 15288: 25 processes	PMBoK: 10 knowledge areas
	(14 of them)
	Decision Management Process	Integration
	Project Planning Process
	Project Assessment and Control Process
	Configuration Management Process
	Stakeholder Requirements Definition Process	Scope
	Requirement Analysis Process
	Project Planning Process
	Project Assessment and Control Process
	Configuration Management Process
	Project Planning Process	Time
	Project Assessment and Control Process
	Configuration Management Process
	Project Portfolio Management Process	Cost
	Project Planning Process
	Project Assessment and Control Process
	Configuration Management Process

Stakeholder

As shown in Table V-5, processes "Project Planning Process" and "Project Assessment and Control

Table V

 V

	Execute, Evaluate, Acquire, Activate, Analyse	Executing
	Monitor, Deliver, Assess, Provide, Control, Treat	Monitoring and Controlling
	Accept, Close, Improve, Maintain, Perform, Support,	Closing
	Finalize
	-6 Relationships between ISO/IEC 15288 and the PMBoK
	ISO/IEC 15288: Tasks & activities	PMBoK: 5 processes
	Prepare, Initiate, Identify, Establish, Define, Elicit	Initiating
	Advertise, Develop, Plan, Manage	Planning

Table V -

 V 7 Focus on different systems in ISO/IEC 15288 and PMBoK

	Risk Management Process	(ISO/IEC 15288)	Project Risk Management (PMBoK)
	Tasks and Activities:		5 processes:
	Plan risk management		1. Plan risk management
	Manage the risk profile		2. Identify risks
	Analyse risks		3. Perform qualitative risk analysis
			4. Perform quantitative risk analysis
	Treat risks		5. Plan risk responses
	Monitor risks		6. Control risks
	Evaluate the risk management process

Table V -

 V 8.

Table V -

 V [START_REF] Pmi | A Guide to the Project Management Body of Knowledge: PMBOK® Guide[END_REF] The result of the harmonization of the PM and SE processes

	Planning (Pl)	Executing (Ex)	Controlling (Co)
	Scope Plan Process	Quality Execute Process	Scope Control Process
	Time Plan Process	Human Resource Execute Process	Time Control Process
	Cost Plan Process	Information and Communication	Cost Control Process
	Quality Plan Process	Execute Process	Quality Control Process
	Human Resource Plan Process	Business or Mission Analysis	Risk Control Process
	Risk Plan Process	Process	Information Control
	Information and	Stakeholder Needs &	Process
	Communication Plan Process	Requirements Definition Process	Information and
	Knowledge Plan Process	System Requirements Analysis	Communication Control
		Process	Process
		Architectural Design Process
		Design Definition Process
		Systems Analysis Process
		Integration Process
		Implementation Process
		Operation Process
		Transition Process

Table VI

 VI

			-4 Comparison of two possibilities of the project index
		A	B	C	D	Project
	weight	1/6	1/3	1/6	1/3	1
	PcPEI value 1	2	0.25	1	1	11/12<1
	PcPEI value 2	0.5	2	1	1	5/4>1

Table 1 la table des processus intégrés

 1

	Planning (Pl)	Executing (Ex)	Controlling (Co)

Comparison of the PM references

Acknowledgements

First think to my supervisors Ms. Claude Baron and Mr. Philippe Esteban for all the helps during Abstract Sp cialit : G nie industriel Nom: XUE Abstract R sum

This chapter introduces the research work that has been done during this thesis. This thesis was carried out in Laboratory for Analysis and Architecture with the funding from China Scholarship Council. The research work was carried out with the Systems Engineering and Integration (ISI) team at LAAS.

List of Abbreviations

The system life cycle on which the ANSI/EIA 632 standard relies is enterprise-based; it defines more stages referring to the enterprise. The focus is on systems and products in general; its concern is implementing the requirements of the standards within a defined engineering life cycle, which can be applied in any enterprise-based life cycle stage to engineer or reengineer a system. The ISO/IEC 15288 standard covers man-made systems; the focus is on a set of generic processes applied as appropriate to accomplish the purposes of any one of the phases of a system's life cycle. The IEEE 1220 standard also focuses on systems and products and more precisely on the development stage of the system life cycle, but adds focus on the enterprise (large organization) as well.

Considering the level of detail, the ANSI/EIA 632 standard describes the system life cycle at a requirement description level. It is more detailed than the ISO/IEC 15288, which describes the system life cycle at a process description level. The IEEE 1220 focuses on the practice for engineering a system, especially the development stage; it defines purpose, tasks and outcomes in more detail than the ANSI/EIA 632. This last focuses on the conception stage; it adds more processes on the assessment of opportunities and the investment decision. ISO/IEC 15288 describes the processes at the highest detailed level. Activities, tasks and outcomes are also defined in the ANSI/EIA 632, but they are less detailed than in the ISO/IEC 15288. The IEEE 1220 standard describes the processes at the least detailed level.

The ANSI/EIA 632 defines the context for application of the standards as the external environment (laws, social responsibilities), enterprise environment (local culture, domain technologies) and the project environment (plans and tools) (ANSI 1998) [START_REF] Sheard | Systems engineering standards and models compared[END_REF]. The three standards cover different contexts of the project. The ANSI/EIA 632 covers a small enterprise environment and the project environment, while the coverage of the environment in ISO/IEC 15288 is larger than the other two standards; it covers both the enterprise environment and the project environment. But IEEE 1220 only covers the project environment. As we can see that there is no ideal and universal standard, suitable to any kind of neither enterprise nor system. To offer a SE that would offer PM facilities, either is to select one reference from the five SE references on the SE side considering the PM ability to be aligned with the one we will choose on the PM side.

The first approach led us to proposing selecting some processes from ISO/IEC 15288 to complete ANSI/EIA 632 to get a multi-standard, but this option presents some limits considering PM. We thus propose to select the best 'alignable' reference in SE from our point of view, ISO/IEC 15288. The next chapter compares and analyzes PM references to select the 'most alignable' one with ISO/IEC 15288.

Chapter IV. Comparison of Project Management References

In order to integrate SE with PM, the first step is to align the references from both domains.

Chapter III has presented the five main systems engineering reference and the conclusion is that the ISO/IEC 15288 standard would represent best candidate to alignment with PM standards or guides.

This section now presents the two main PM references: PMBoK, and ISO 21500 and compare them to select one reference to align with the ISO/IEC 15288.

IV.1. Introduction

With the increasing complexity and scales of systems, it is necessary to use Project Management during the implementation of projects. Even though many Systems Engineering standards or guides consider the managerial processes, such as the acquire process and supply process, the implementation of Project Management processes is not enough developed in these standards or guides. Furthermore, how to integrate both project management objectives and practices with systems engineering ones during all the project lifecycle is also a critical issue besides the implementation of project management processes in systems engineering projects. Many tools, techniques and even standards or guides have been developed by different organizations in order to support the management of such projects. For project managers, selecting and relying on immediately operational methods, tools and references (standards and guides) to lead his project represents a true difficulty. The purpose of this chapter is to introduce, analyze and compare the most famous project management references or guides (PMBoK and ISO 21500) at different levels to provide global and detailed views on project management methodological guidelines to project managers, in order to facilitate the choice of a project management reference to help them to manage the systems engineering projects effectively, consequently to improve the success rate of projects. Project Management (PM) plays a critical role in the implementation of projects in all the organizations or companies, wherever they are small or large. Using PM methods and tools cannot ensure the success of a project, but it can improve its chances of success. PM has been practiced for thousands of years that can be dated back to the Great Pyramid of Giza [START_REF] Kwak | A brief history of Project Management. The story of managing projects[END_REF] [START_REF] Beiryaei | Implementing Knowledge life cycle in the body of project life cycle by using knowledge management system (KLC in PLC)[END_REF]. Many methods and tools have been developed since and are now available and routinely used by projects or programs managers. Among them, the Gantt chart, the Critical Path

Comparison of the PM References

Figure IV-3 The mapping table of processes (PMI 2013)

As we introduced above, the PMBoK has 47 processes grouped into 5 process groups and the processes are regrouped into 10 KAs. The ISO 21500 nearly has the same structure. It defines 39 processes organized into 5 groups. Instead of the KAs, it defines the 10 subjects related to knowledge areas of project management field. Both references (PMBoK and ISO 21500) define the purpose, inputs and outputs of each process, and the PMBoK provides the tools and techniques additionally. In the next section, we analyze and compare all the processes from the two references in order to align them at the process level.

IV.4.3. Detailed Comparison based on the process level of two references

In this section, we first analyze the processes from the two references, then we compare them in order to find if processes are identical or can be aligned; at last we give the detail on the same processes in both the two references, the process merged of same new activities and the special processes in each reference.

To compare processes, we proceed this way: we consider the ISO 21500 referred to PMBoK. First we compare the ISO 21500 with the PMBoK. The comparison of the ISO 21500 with the PMBoK revealed 27 identical processes, the ISO 21500 having 2 processes less than PMBoK (validate scope process and plan stakeholder management process) and it introduces two new processes (collect lesson learned process and control resource process). It displaces the "define activities process" of project time management knowledge area into the project scope management subject. The ISO 21500 defines the "Manage Stakeholder Process" as the "manage stakeholder process'' and the "control stakeholder process" of PMBoK; the "define scope process" instead of the "collect requirements process" and "define scope process" of PMBoK; the "assess risk process" instead of the "perform quantitative risk analysis process" and "perform quantitative risk analysis process" of PMBoK; the "administer contracts process" instead of the "control procurement process" and "close procurement process" of The ten knowledge areas are listed in Table V-3. A Knowledge Area represents a complete set of concepts, terms, and activities that make up a professional field, project management field, or area of specialization. There are five process groups that compose the ten knowledge areas (PMI 2013). As Figure V-12 shows, the level of detail of PMBoK's "Processes" are the same level of the "Activities" of the ISO/IEC 15288 (Xue et al. 2015) that is thus where we decide to focus the analyses.

In order to illustrate how we proceed, let us take the example of "Planning Processes" of the "Human Resource Management Process group" of PMBoK. We can note that the description of the 4 tasks and activities in the ISO/IEC 15288 is at the same description level as the 4 processes of the PMBoK.

V.4.2. Regroup the processes and remove the overlap between them

Once the comparison and alignment are done, it is necessary to regroup the processes from PMBoK into the aggregated process at the same level of detail as the processes of ISO/IEC 15288.

Here is an example to explain the procedure of the regrouping. The "risk" knowledge area of PMBoK contains four processes: Plan risk management, Identify risk, Perform quantitative risk analysis and Plan risk responses. We regroup the above four processes into a new process: Risk Plan Process as

Chapter VI. Assessment of the Project Progress

VI.1. Introduction

On the basis of the assessments and information produced before, this chapter is aimed to offer support for evaluating the project progress and taking decisions in order to reorient the project (decisions relating to both the product and the project), to extend project monitoring by management initiatives [START_REF] Eckerson | Performance dashboards: measuring, monitoring, and managing your business[END_REF]). We will integrate the AHP, CPM and EVM methods which will be used to model our knowledge of the relationships between the known factors of the project. The objective is by no means to be a substitute for policy makers, but to provide factual arguments to assist with decisionmaking, thanks to the better knowledge of facts and increased reliability of forecasting. If it is necessary to reorient a project, the approach will thus consist in considering several optional scenarios and assessing them, in order that the decision-maker may take corrective measures. This integrated method facilitates the assessment and the choice of alternative project management scenarios as well as for the expected product architecture. The proposition's chief concern is to develop methods that improve the efficiency of the process without making it more onerous, and that are properly adapted and scaled for each size/type of business with consideration for its own objectives. The detailed application of our proposal will be given in next section. Section VI.2 will give the brief indicators that be defined for assessing the project progress. The implementation of the AHP, CPM and EVM methods will be presented in section VI.3; for each method, we will give the simple example to show how to use them. The conclusion will be given in section VI.4.

VI.2. Definition of a set of indicators

Project indicators can have several uses and be of several types: monitoring (the state of health of the project), observing (discrepancies), analyzing (possible solutions), synchronizing (activities), anticipating (risks and opportunities), facilitating (decision-making), and characterizing the project [START_REF] Larson | Significance of project management structure on development success[END_REF]. For this, it is necessary to evaluate the influence of changes of the indicators from both the systems engineer and project manager views. So our proposal values the indicators both by systems engineers and project managers to control and monitor a project under the integrated views.

By comparing them with the objectives it will be possible to detect deviations (scheduling,

= the planned value of the resource required of this process

Let us take a process where the resource allocated to this process is 11 employees; the resource assigned to this process is 9 employees at the moment, and the budgeted resource of the finished work of this process is 8 employees. Then we have , , .

VI.2.5. Expected criteria

The indicator "Expected criteria" is defined as . It indicates the minimally acceptable outputs in order to perform the next process. The planned value, actual value and earned value of the EVM method of this indicator are defined as:

For example, the process "Quality Plan Process" of PMBoK has five: "quality management plan", "process improvement plan", "quality metrics", "quality checklists" and "project documents updates" expected outputs. If at this moment, two inputs should be finished but there is only "quality management plan" is finished, the number of the budgeted outputs performed is 1. Then we have

In this section, we defined a set of five core indicators to support process and project evaluation for decision-making. We also give the method to calculate the EVM value of indicators. However, depending on the project or enterprise, systems engineers and project managers can define specific additional indicators. In the next section, we will explain how to integrate the AHP, CPM and the EVM methods to assess the project progress.

VI.3. Brief introduction to the AHP, CPM and EVM methods

VI.3.1. The introduction to the AHP method

With the complexity of the world growing rapidly, it is necessary for the project managers and companies to make the best decisions. Many methods have been evaluated from the mathematics and matrixes are as follows:

It can be calculated that the maximum eigenvalue of SE2 is . Using the formula for , we obtain . So the , is less than 0.1, so we consider this matrix is also consistent. The maximum eigenvalue of PM1 is , the

We obtain the , which is less than 0.

Chapter VII. Conclusion and Perspectives

VII.1. Conclusion

The research work that been taken out in this thesis proposal a methodology that aims to integrate the SE and PM domains by integrating the processes and practices from standards or guides. As we presented in Chapter II, the integration of SE and PM has become an important issue and begun attracting the attention of both research and industry. Several projects have been carried out with the goal to improve performance in engineering projects. Some of these studies extend their scopes to consider the design of technical systems with their own sets of issues, such as the choice of components and their influence on the environment, the behavioral specifications and their simulation, and the management of technical and environmental performance indicators, but a few addresses the integration of domains to research this goal. This analysis of the existing situation (methods, tools, practices and needs, areas of application) shows the advantage of proposing new approaches to correct the faults and shortcomings of current practices. Chapter II presented the context and state of the art of this thesis in detailed. We also explained our proposal briefly in this chapter. Considering this need of industry, Chapter III chose the five main SE international standards and guides: ANSI/EIA 632, ISO/IEC 15288, IEEE 1220, INCOSE SE HANDBOOK and SEBoK, and compared them based on different criteria. At last, we proposed two approaches: a multi-standard or choose one "most alignable" references from this domain considering the ability of PM. We gave the multi-standard in section III.4.1. In section III.4.2, we chose the ISO/IEC 15288 on behalf of SE domain. On the other hand, Chapter IV addressed the choice of reference from PM domain. We selected the two PM references: PMBoK and ISO 21500 and compared them in many levels. At last, we came to the conclusion that the PMBoK is the most suitable reference to integrate with the ISO/IEC 15288.

Chapter V compared and analyzed the possibility to align the two references and compared our proposal with the ISO/IEC 29110. In Chapter VI, we also gave some example to illustrate how to align and integrate them. We defined a set of core indicators and integrated the CPM, AHP and EVM methods to assess the project performance under the integrated views of systems engineers and project managers.

In fact, our strategic discussion regarding international standards for bringing together the two approaches provides a promising dynamic for this topic (Sharon, de Weck, et Dori 2011). The contributions of this work can be summarized as follows. 1) We integrate the SE and PM in two aspects by the alignment of the standards or guides from both domains. 2) We calculate the indicator values with the views of both systems engineers and project managers based on the AHP methods. 3)

We define the project assessment values based on the CPM and EVM methods. 4) We also provide the indexes on the basis of the adaptive EVM method to help the project managers to gain insight from the project progress easily.

These contributions can help integrate not only the general practices from systems engineering and project management by the alignment of standards and guides, but also the systems engineers' and project managers' views of a certain project based on their own practices and knowledge. According to different types of projects, we also allow the systems engineers and project managers to define the additional indicators. The assessment of a project by our proposal improves the coverage of the system of indicators and extends it by incorporating specific knowledge from both the project management and the systems engineering sides, to give it the ability to assist in the detection and the anticipation of project deviations. This proposal formalizes the difficult goals in view of the complexity of products and the multidisciplinary skills that need to be mobilized and coordinated to the simple indexes to understand.

VII.2. Perspectives

As we have the contributions 1 and 2 in Figure II-19, we need to extend our work to make it easily used by companies, especially the SMEs. So during the last period of this thesis, we send out a detailed survey to the laboratory's partner companies to get their expected methods to use in their own context.

We will carry out some other work about how to simplify the integrated processes that we proposed in our methodology to be adapted to different type and scale companies.

List of the publications and reports

List of the publications and reports

-Xue, R., Baron, C., Esteban, P. (2015). Aligning systems engineering and project management standards to improve the management of processes. Progress in Systems Engineering (pp. 547-553). Springer International Publishing.

-Xue, R., Baron

List of publications and reports

-Xue, R., Baron, C., Esteban, P. (2015). How to choose a systems engineering standard: -Malbert, M., Estève, D., Baron, C., Esteban, P., & Xue, R. (2014). Managing requirements:

for an integrated approach from systems engineering to project management. In Advances in Production Management Systems. Innovative and Knowledge-Based Production Management in a . Springer Berlin Heidelberg.

Glossary

-Acquirer: An enterprise, organization, or individual that obtains a product (good or service) from a supplier.

-Agreement: An arrangement, not necessarily contractual, between two parties (an acquirer and a supplier) that define the tasks to be performed, the items to be delivered, the acceptance criteria to be applied to delivered items, and other requirements affecting the development or procurement of system products.

-Assign: Designate a function, product, process, or other item as accountable for a particular purpose.

-Configuration management: A management process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational management information throughout its life.

-Customer: An individual, organization, or enterprise that ( 1) commissions the engineering of a system; ( 2) is a prospective purchaser of the end products of a system, or portions thereof; or ( 3) is an acquirer of a product.

-Deliverable: An item agreed to be delivered to an acquirer as specified in an agreement. This item can be a document, a hardware item, a software item, a service, or any type of work product.

-Derivative system: A special type of precedented system derived from a previously operational system through the use of major elements, but whose requirements have been modified to meet new objectives.

-Development: The action by which a set of requirements is translated into a solution definition for a set of products that satisfy stakeholders.

-Document: A collection of data, regardless of the medium on which it is recorded, that generally has permanence and can be read by humans or machines.

-End product: The portion of a system that performs the operational functions and is delivered to an acquirer.

-Engineering life cycle: A sequence of phases that evolves an instance of a system from a concept to a set of products consistent with the exit criteria established for an enterprise-based life cycle phase.

-Enterprise: The entity that has governance over a set project, or over organizations in which projects are carried out.

-Environment: [START_REF] Conforto | Survey Re-port: Improving Integration of Program Management and Systems Engineering[END_REF] The natural conditions (weather, climate, ocean conditions, terrain, vegetation, dust, etc.) and induced conditions (electromagnetic interference, heat, vibration, etc.) that constrain the design definitions for end products and their enabling products.

Glossary

-Function: A task, action, or activity performed to achieve a desired outcome.

-Functional requirement: A requirement that defines what system products must do and their desired behavior in terms of an effect produced, or an action or service to be performed.

-Performance requirement: A requirement that defines how well the system products are required to perform a function, along with the conditions under which the function is performed.

-Process: A set of interrelated tasks that, together, transform inputs into outputs.

-Product: (1) An item that consists of one or more of the following: hardware, software, firmware, facilities, data, materials, personnel, services, techniques, and processes. ( 2) A constituent part of a system.

-Project: A development effort consisting of both technical and management activities for the purpose of engineering a system.

-Prototype: A model (physical, electronic, digital, analytical, etc.) of a product built for the purpose of a) assessing the feasibility of a new or unfamiliar technology; b) assessing or mitigating technical risk; c) validating requirements; d) demonstrating critical features; e) verifying a product; f) validating a product; g) determining enabling product readiness; h) characterizing performance or product features; or i) discovering physical principles.

-Requirement: [START_REF] Conforto | Survey Re-port: Improving Integration of Program Management and Systems Engineering[END_REF] Something that governs what, how well, and under what conditions a product will achieve a given purpose. ( 2) Normative elements that govern implementation of this Standard, including certain documents such as agreements, plans, or specifications.

-Risk: (1) A measure combining the uncertainty of reaching a goal with the consequences of failing to reach the goal. ( 2) The probability of suffering injury or loss.

-Risk management: An organized process for identifying and assessing risks, and for implementing means to avoid them or mitigate their effect if they occur.

-Specification: A document that contains specified requirements for a product and the means to be used to determine that the product satisfies these requirements.

-Stakeholder: An enterprise, organization, or individual having an interest or a stake in the outcome of the engineering of a system.

-Stakeholder requirement: A requirement that represents what stakeholders of a system need or expect of the system products.

-Standard: A document that establishes engineering and technical requirements for products, processes, procedures, practices, and methods that have been decreed by authority or adopted by consensus.

-Subsystem: A grouping of items that perform a set of functions within a particular end product.

-Supplier: Provides a product (either end products, enabling products, or both) or a group of products to an acquirer. The supplier (external or internal to the acquirer's organization) can be a vendor that has a product that does not need development, or a developer that must develop the desired system product or products.

-System: An aggregation of end products and enabling products to achieve a given purpose.

-Traceability: The ability to identify the relationship between various artifacts of the development process, i.e., the lineage of requirements, the relationship between a design decision and the affected requirements and design features, the assignment of requirements to design features, the relationship of test results to the original source of requirements.

-User: Individual, organization, or enterprise that uses, applies, or operates system products.

Abstract

Specialty: Industrial Engineering

Management

In a highly competitive economic context, companies need to improve their performance in entire life cycle of a product. It is often found that company organization leads to segregation between systems engineering and project management, with the result that decision-making is sometimes misguided and may compromise project execution, whereas, although they each have specific visions and targets, these disciplines are nonetheless intended to serve a common objective, which is to satisfy the customer. So it is an important issue to facilitate their adoption and their joint deployment within the company, in order to improve decision-making in engineering projects. The proposal of the thesis involves bringing systems engineering and project management closer together in order to help both systems engineers and project managers assess the project progress. Based on this assessment, they can adjust the project policy dynamically through the project life cycle. In this thesis, we first harmonize the standards and guides from systems engineering and project management domains and define an integrated process groups organized into 3 groups of processes. Then we identify a set of key indicators related to these process groups, indicators are then valuated and give the evaluation of the indicator based on the analytic hierarchy process method to integrate the views of systems engineers and project managers in an additional way. On the basis of these indicators, we use the critical path method and earned value management method to assess the project progress values and define two project indexes to assess and insight the project progress easier.

Key words: En outre, les études d'ingénierie, que ce soit dans des grands groupes ou dans les PME, font intervenir des processus multiples, complexes à gérer [START_REF] Labrousse | Enterprise processes traceability based on a FBS approach[END_REF]. Il est important de simplifier les démarches, de définir les processus 'juste utiles', selon la taille de l'entreprise. C'est l'objectif visé par notre première contribution (Figure 3).