Tom Stentzel

Masoud Niknam

Jivka Ovtcharova

Comparison Framework for PLM Maturity Models

Keywords: Tom Stentzel, Masoud Niknam, Jivka Ovtcharova maturity model, product lifecycle management (PLM), model comparison

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Nowadays, companies and organizations consistently strive for improving their ongoing business to preserve their position in the market. In order to do that they need to maintain their competitive advantage by reducing their overall costs, being innovative with their products and services, and ensuring their customers' satisfaction with supreme quality. As stated by the Total Quality Management (TQM) principles taught by Shewhart, Juran, Deming and Humphrey, "The quality of a product is largely determined by the quality of the process that is used to develop and maintain it". Additionally to the quality of the utilized process, the choice of technology and people that provide the connection will guarantee a high level of quality throughout the entire company.

One way of pursuing the above-mentioned goals is to implement the use of maturity models. These models help to analyze the current state and the progress made over a period of time concerning processes or structures, assess their current level of maturity, identify strengths and weaknesses, and possibly propose improvement solutions. Also, the use of maturity models by itself will enhance the awareness of the employees being assessed and this alone could have positive effects within the organization.

However, since there is a vast amount of maturity models to choose from, depending on the specific goal, the application domain, and several other criteria, how should someone know which one to choose? This paper will try to provide an answer to this question by examining existing maturity models based on specific criteria that have been collectively put into a comparison framework. A few attempts have already been made to structure these criteria and organize them in classification systems. However, the still increasing number of maturity models entails problems of retrievability and reusability, which this paper shall help to overcome. [START_REF] Mettler | Towards a Classification of Maturity Models in Information Systems[END_REF] 2

State-of-the-art analysis

To get a better understanding of the topic of maturity models and their influence on the PLM domain, this paper will briefly describe their evolution as well as their current, interrelated use.

Maturity models

As mentioned above maturity models provide excellent support in assessing the maturity of an entire organization with the aim of improving the competitive advantage on dynamic markets. Starting off in 1987, the Software Engineering Institute (SEI) introduced the Capability Maturity Model (CMM), one of the first models to assess the maturity of processes and the predecessor of many-to-follow maturity models. [13] Following the official CMM version 1.0 in 1991, the CMM Integration was launched in 2002, which eventually lead to the most current CMMI version 1.3, released in 2010. Especially addressing software development, the SEI introduced the concept of having five maturity levels (initial, managed, defined, quantitatively managed, optimizing), indicating the process capabilities expected at a certain level. These process capabilities describe a range of expected results achieved by following the observed software process. Each level also contains a number of key process areas, regulating which goals to achieve according to a set of activities. These key process areas will mostly be considered as business dimensions in other models. Lastly, a detailed description of how to conduct improvement activities is covered in the key practices, which in concerning the CMMI are included in five common features. Some models use the CMMI structure as a reference frame, although many others choose a different approach, mostly due to specific domain requirements.

Since maturity models start to become more and more popular, many different variations in their development have been attempted. As stated by [START_REF] Fraser | The use of maturity models / grids as a tool in assessing product development capability[END_REF], all maturity models shall include six basic components, which will be necessary for them to be well-structured: (1) a number of levels (typically three to six), (2) a descriptor for each level (such as the CMMI's differentiation between initial, repeatable, defined, managed, and optimizing processes), (3) a generic description or summary of the characteristics of each level as a whole, (4) a number of dimensions (such as the "process areas" in CMMI), (5) a number of elements or activities for each dimension, and (6) a description of each element or activity as it might be performed at each level of maturity. As stages (1) to ( 4) are usually met with ease, some models struggle with clear definitions for stages [START_REF] Kärkkäinen | Defining the customer dimension of PLM maturity[END_REF] and [START_REF] Kulkarni | Development and Validation of a Knowledge Management Capability Assessment Model[END_REF]. Regarding those models the idea and fundamental structure is often well designed, but they lack detailed descriptions for the implementation and/or improvement activities, which leads to less appreciation by end users due to limited practicality.

As of today, research related to maturity models heavily focuses on the development, including basic descriptions, more detailed conceptualizations, and approaches with different scientific structuring methods, e.g. design-oriented research or Delphi studies. About a third of all researches concentrates on the application of maturity models, e.g. to specific domains, with the help of maturity assessments, or transferring this knowledge to other contexts. Only very few works conduct empirical studies or simulations, compare maturity models, or conclude model validations of some sort. This paper shall reduce this gap by providing a new concept for model comparison. [START_REF] Wendler | The maturity of maturity model research: A systematic mapping study[END_REF]

Product Lifecycle Management

Similar to the term maturity there are various ways of defining the area of PLM. A widely-spread definition used by [START_REF] Stark | Product Lifecycle Management: 21st Century Paradigm for Product Realization[END_REF] states 'Product Lifecycle Management (PLM) is the activity of managing a company's products across the complete lifecycle, from the early stages of conception to the final disposal or recycling of the product.' PLM can rather be considered a concept than a system due to its focus on maintaining sustainable market advantage by addressing flexibility and innovation. [START_REF] Batenburg | PLM roadmap: stepwise PLM implementation based on the concepts of maturity and alignment[END_REF] This concept can be considered as a combination of business rules, processes, methods, and guidelines including descriptions for the practical implementation. [START_REF] Saaksvuori | Product Lifecycle Management[END_REF] The concept of PLM is very powerful as mentioned benefits include shorter time-to-market, increased innovative ability and profits, fewer engineering changes late in the lifecycle, higher efficiency, and less product faults. [START_REF] Stark | Product Lifecycle Management: 21st Century Paradigm for Product Realization[END_REF] Other drivers for the use of PLM consider the demand of more complex products with regard to functionality and components, shorter product lifecycles, customization options because of higher demand standards, management of eventually more complex supply chains, as well as factoring in the increasing regulations concerning safety and environmental issues as mentioned by Batenburg et al [START_REF] Batenburg | PLM roadmap: stepwise PLM implementation based on the concepts of maturity and alignment[END_REF].

Since the PLM concept addresses very common business goals that are pursued by different organizations Batenburg et al [START_REF] Batenburg | PLM roadmap: stepwise PLM implementation based on the concepts of maturity and alignment[END_REF] also state that it has been used in various industries, including e.g. the automotive and transport sector, aerospace and defense, process industry, life sciences and heavy machinery. However, this versatility needs specific application adjustments with respect to the addressed domain and industry. One way to cope with these adjustments is the use of maturity models. They can either be used to assess the maturity of an organization with respect to their readiness to introduce the PLM concept or assess the maturity of an already implemented PLM system in regards to the efficiency of processes, structures, etc. Some of these models provide further guidelines and roadmaps for the improvement of specific gaps and aspects. However, it is always important to realize the strength and weaknesses of the available maturity models in the field and choose the most suitable with regard to the organizations' requirements.

Development of an assessment framework

As stated in Wendler's study [START_REF] Wendler | The maturity of maturity model research: A systematic mapping study[END_REF], there is a significant lack of research in the area of maturity model validation, which by his means covers maturity model comparisons. Therefore, the aim here is to develop a comprehensive framework to facilitate a fair comparison of the models with respect to their different attributes. Although there have already been attempts to classify, categorize, compare, and evaluate maturity models, the intent of this paper is to develop a framework considering all important general aspects that could be relevant for a comparison on the base of explicit literature research analysis. The basic structure of the framework consists of three attribute dimensions, similar to the dimensions addressed by Mettler [START_REF] Mettler | A Design Sciene Research Perspective on Maturity Models in Information Systems[END_REF]: general attributes, design attributes, and usage attributes.

General attributes dimension

The general attributes dimension will cover two blocks of attributes. The first block will include the "basic information", which represents top level information that is necessary to get a simple distinction between all kinds of models. This includes the name of the model, the acronym (if existent), the primary source (where information was collected), the addressed topic, the origin (academic or practitioner-based), the year of publication, the granted access (free or charged), and the addressed audience (management-or technology-oriented). The second block "structure details" will go more into detail on aspects like the covered business dimensions and maturity levels as well as possible testing parameters.

Design attributes dimension

This dimension will focus on design related issues concerning the maturity models. That includes the main purpose of the model, which can be either descriptive (the application is a single point encounter with no intention of maturity improvement or analysing performance relationships), prescriptive (analyzing domain relationships in order to boost business performance and thus increase the business value, therefore identifying gaps and creating a road-map for improvement), or comparative (performing an industry-wide benchmark across different organizations to compare similar practices). [START_REF] De Bruin | Understanding the Main Phases of Developing a Maturity Assessment Model[END_REF] As mentioned by Mettler [START_REF] Mettler | A Design Sciene Research Perspective on Maturity Models in Information Systems[END_REF] the concept of maturity covers the focus of the model, including process maturity (to which extent a specific process is explicitly defined, managed, measured, controlled, and is effective), maturity (to which extent a particular object like a software product, a company report or similar reaches a predefined level of sophistication), and people capability (to which extent the workforce is able to enable knowledge creation and enhance proficiency). Additionally, Kärkkäinen [START_REF] Kärkkäinen | Defining the customer dimension of PLM maturity[END_REF] introduced a fourth customer dimension (capability for management of all customer-related data, information and knowledge concerning the whole product lifecycle), which will be factored into the comparison. The composition shows that a model can either be concluded as a maturity grid (text descriptions for each activity at each maturity level with moderate complexity), a Likert-like questionnaire or hybrids (questions are statements of 'good practice' to score the relative performance; hybrids combine this with a maturity grid), or something else (e.g. the CMMI). [START_REF] Fraser | The use of maturity models / grids as a tool in assessing product development capability[END_REF] As for the chosen assessment approach, the model can either be staged (the model matures the organisation as a whole) or continuous (improves capability of specific processes within the organization). [START_REF]CMMI for Development, Version 1.3[END_REF] Whether a model is designed to be oneor multi-dimensional (being adaptable to multiple domains) will be covered in the scope as well. The flexibility or rather adaptability of a model can either be represented as a change in its form (e.g. the underlying meta-model or model schema, the descriptions of the maturity levels or question items) or its function (e.g. how maturity is assessed). [START_REF] Mettler | Towards a Classification of Maturity Models in Information Systems[END_REF] Lastly, the reliability of the model will be addressed. When there is at least one testing available, it can be assumed that the model has been verified. Only until a model has been thoroughly tested and accepted by many practitioners it could be considered as validated.

Usage attributes dimension

The usage attributes dimension covers five attributes mainly concerning application issues. First off, the method of application is defined by either being done by a self-assessment, a third-party assisted assessment, or be concluded by certified practitioners. A variety of instruments is used for this application, including document reviews, work groups, and/or questionnaires. When self-assessing support for the application is needed. If there are any, this support could include textual descriptions or handbooks, or a software assessment tool. Since not all of the observed models provide specific improvement guidelines when trying to advance from one level to the next, this attribute shows importance to be covered. As for the practicality of evidence, implicit improvement activities for future development of the model as well as explicit recommendations are covered. Lastly, some models might need specific training for correct application. This training can range from basic to extended, depending on the level of detail and the desired purpose of use.

Results of the assessment framework

The comparison framework as described in Chapter 3 is applied to a variety of maturity models in the PLM area, including the PLM framework proposed by Batenburg et al [START_REF] Batenburg | PLM roadmap: stepwise PLM implementation based on the concepts of maturity and alignment[END_REF], the Capability Maturity Model Integration (CMMI), Version 1.3, by the CMMI Institute [13, 14], the Configuration Management Maturity Model by Niknam et al [START_REF] Niknam | Towards Higher Configuration Management Maturity[END_REF], the EDEN Maturity Model by the BPM Maturity Model eden e.V. (all information translated from German) [START_REF] Allweyer | EDEN -Reifegradmodell 'Prozessorientierung in Unternehmen[END_REF], the addition of a customer dimension of PLM maturity based on Batenburg's model by Kärkkäinen et al [START_REF] Kärkkäinen | Defining the customer dimension of PLM maturity[END_REF], the Knowledge Management Capability Assessment Model by Kulkarni et al [START_REF] Kulkarni | Development and Validation of a Knowledge Management Capability Assessment Model[END_REF], the PLM Maturity Reference Model by PLM Interest Group [START_REF]PLM Interest Group[END_REF] the Product lifecycle management model by Saaksvuori et al [START_REF] Saaksvuori | Product Lifecycle Management[END_REF], the PLM Maturity Model by Savino et al [START_REF] Savino | PLM Maturity Model: A Multi-Criteria Assessment in Southern Italy Companies. s.l[END_REF], and the PLM Components Maturity Assessment by Zhang et al [START_REF] Zhang | PLM Components Selection Based on a Maturity Assessment and AHP Methodology[END_REF]. The comparison is based on the available literature about the aforementioned models, which were found and reviewed by the authors in order to extract the categorized information with respect to the comparison framework's requirements.

The results of the general attributes dimension are listed in Table 1 below. Although the scope of their application might vary, all models are associated to the PLM domain. Most of the models are academically based, although some have a rather practitioner-based background. Seven of the ten described models are entirely free to access and for three of them some fees shall be paid for a granted access to assessment tools and extensive documentation or professional assistance in the application of the model. Although most of them have different termed business dimensions, similarities and correlations can be found. For example, Kärkkäinen's model proposes adding another dimension to the Batenburg model. Concerning the number of business dimensions, there is a vast variety of approaches to be found. Some models focus on only four to five dimensions, coping with the covered subject in a more general matter, while other models show up to 15 or 16 dimensions. In case of the Savino and Zhang models, they use the TIFO(S) framework for their coverage, which provides another layer of structure. The observed maturity levels range from four to six and, similar to the business dimensions, they have different labels. For more than half of the models testing is available and has been concluded in different industries. Concerning the CMMI, due to its popularity and widespread acceptance, there are two annual reports that cover the main status of their usage and the maturity of their clients.

Table 1 -General attributes dimension

IT systems 4. The results of the design attributes dimension are listed in Table 2 below (unclear or unverified information in parentheses). All of the observed models present a minimum of "descriptive" purpose meaning that they can at least be used to assess the maturity of the organization or certain processes. Seven of them still provide certain prescriptive actions for improvement and only three provide options for benchmarking. Mostly all of them feature process, and more or less object and people maturity concepts, only few models can be considered to have covered the customer dimension. The composition spreads out very diverse throughout all attribute options, although the Likert-like questionnaires / hybrids and other concepts are used most of the time. Only two models are considered multidimensional, being able to be applied to almost any domain. Most models are in some way mutable, whether it is by adapting the form, function, or both. Many models feature at least a basic test, but only few models have concluded thorough testing, which might lead to consider them as being validated.

Attribute category Attribute

Model

(1) (2) (3) (4) (5) (6) (7) (8) (9) (10)

Main purpose

Descriptive ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Prescriptive ✓ ✓ ✓ ✓ ✓ ✓ ✓ Comparative ✓ ✓ ✓ Process ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Object ✓ (✓) ✓ ✓ ✓ (✓) ✓ ✓ ✓ People ✓ (✓) ✓ ✓ ✓ (✓) ✓ ✓ ✓ Customer (✓) ✓ ✓ (✓) Composition Maturity grid Likert-like quest./hybrid ✓ ✓ ✓ ✓ Others ✓ ✓ ✓ ✓ ✓ Staged ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Continuous ✓ ✓ ✓ ✓ Scope One-dimensional ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Multi-dimensional ✓ ✓ Mutability Form ✓ ✓ ✓ ✓ ✓ (✓) ✓ (✓) Functioning ✓ ✓ ✓ ✓ ✓ (✓) (✓) Reliability Verified ✓ ✓ ✓ ✓ ✓ (✓) ✓ ✓ Validated ✓ ✓ ✓

Concept of maturity

Assessment approach

Design attributes dimension Table 2 -Design attributes dimension

The results of the usage attributes dimension are listed in Table 3 below (unclear or unverified information in parentheses). Most of the models use a selfassessment as the application method. Certified practitioners are usually only available with models that are used by institutions or consultant agencies and that come with a charge. The instrument for application divides up quite evenly between all possible attributes, although the charged models tend to rather strive towards using work groups than only document reviews or questionnaires. An often used supporting tool for the application is a software assessment tool, which has been provided by five of the ten observed models. Also, the charged models seem to provide more support in general. About half of the models exhibit guidelines for specific improvement activities based on the achieved maturity level. Almost all of the models show regular implicit improvement activities. The adaption to the dynamically changing requirements is very relevant and important for future usage purposes. A downside of the charged models is the required training. Depending on the intensity and future plans of use the training can be more or less extended.

Practicality of evidence

Guidelines for specific improvement activities

Usage attributes dimension

Method of application

Instruments for application

Support of application Table 3 -Usage attributes dimension 5 Conclusion

As illustrated in Wendler's study [START_REF] Wendler | The maturity of maturity model research: A systematic mapping study[END_REF], only a fraction of the research in the field of maturity models strives into the direction of validation. With this paper we tried to provide a more comprehensive maturity model comparison framework based on general categories extracted from literature. The few past categorization and comparison approaches have thoroughly been analyzed to develop a framework that covers all the important attributes. The comparison result is aiming to not only reduce the search time for specific models, allow easier communication, identify differences and similarities, and thus enhance retrievability, but also provide a baseline of attributes needed for a high-quality development of future models. Thus, this framework can serve as a benchmark for future PLM maturity model developments.

However, since the comparison approach only covers a qualitative evaluation, a weighting system regarding individual preferences could be implemented to add further detail to the analysis and to be able to rate the models more precisely with respect to their intentioned application and organization needs. A possible approach on adding quantitative value to the comparison might be to use plus and minus values instead of checkmarks, which could eventually add up to show a preference of certain models in specific categories. Additionally, because the PLM area is generally becoming more important to companies and organizations, further research on "which models might also be suitable for this domain" (e.g. due to their mutability) should be concluded. Since in this paper only models with easy access and available documentation were covered, further research on models with limited access might provide an even more comprehensive overview.


Bernard Chabot

Philippe Gautreau

Brice Sommacal

Business Consultant

How to improve PLM approach efficiency based on knowledge engineering, knowledge management and semantic web technologies domains?

Keywords: Product Lifecycle Management, Project and Program management, Knowledge management, Knowledge engineering, Semantic web, business referential, knowledge referential, Ontology, Knowledge base

The objective of this article is to show that SEAMLESS, a designed and developed method from PCO Innovation, allows improving PLM approach efficiency by proposing to set up a business/Information System referential. PLM, as a PLM solution, is a software which basically supports product conception and product industrialization business processes (and potentially other upstream and/or downstream business processes). The functional scope may be really wide and the various amounts of subjects are strongly connected to each other. A PLM approach (which seeks to establish a PLM solution in the organization) is basically composed of a program with several projects. Among all PLM approach activities; upstream activities (and specifically specification activities) are absolutely crucial. This kind of approach is, generally, lengthy and complex. Specification activities raise many challenges. They come from a functional positioning (whereas a business one is expected) of user's requirements and also from the deliverables documentary nature. Looking at what is a business/Information System referential; we observe that it has all the ingredients to avoid misunderstanding of user's needs and the nature of the document. SEAMLESS is an assisted method to modelize, capture and restitute (graphically and/or textually) the underlying knowledge domain delimitating a set of activities. SEAMLESS allows implementing any knowledge referential by using a generic approach as well as modular and reusable components. By applying SEAMLESS approach on PLM specification activities, we improve PLM approach efficiency.

Introduction

As business consultants, we are solicited by our clients to help them set up a PLM solution in their company. Alongside this progress, most of the time, we encounter some behaviors (independently of their sectors) which prevent to run successfully our mission. That's why; we want to show how our SEAMLESS methodology allows improving PLM approach efficiency. This article is divided into 4 complementary sections. The first section describes the general nature of the PLM approach (i.e. as a PLM solution) and the specificities of a PLM project. The second section describes how activities which contribute to the specification of a PLM are traditionally apprehended, as well as the pitfalls which are usually encountered and the factors which are at the origin of these pitfalls. The third section describes what a business/information system referential is and how it could solve pitfalls mentioned in the previous section. The fourth section describes SEAMLESS, an assisted semantic methodological approach which allows implementing this kind of referential. This prerequisite will strengthen the understanding of what a PLM project is and what the main activities in it are. It will also describe the recurring features of a PLM project and show how a PLM project is not really like other projects.

The PLM and the PLM approach

The PLM at a glance

A PLM, as defined by a "PLM solution", is a software solution which generally comprises a PLM software package, is to an extent configured and/or "customized" and serves as the main component, as well as many other software applications which are more or less integrated with the main component. The ultimate purpose of a PLM is to support and coordinate every activity which is linked to every step in the lifecycles of products and/or services in a company: product innovation needs definition, design, industrialization, production, distribution and others, and in any other case (relative to the nature of the product): operation, maintenance and support, dismantling or even recycling. Depending on certain criteria (product nature, business model type, company strategy, etc.), this end goal will also encompass activities located upstream or downstream of the product lifecycle. A PLM solution will allow a company to design more products and/or design them quicker and/or design less costly products (Miller 2003).

Due to the nature of activities supported by PLM solutions, we may deduct that the major topics (in terms of area of interest) of a PLM are core business concepts used during design and industrialization activities. Other « Core » subjects can be found, such as products informations, but also other subjects which are more or less related to products such as customers, product component suppliers, product requirements, control, verification and product validation methods. These subjects have traditionally been portrayed, described and/or characterized in documents or office software format (Word, Excel, PowerPoint, etc.) such as briefs, functional and technical specifications, assembly nomenclature or mixing recipes, audit files, procedural file control plans, … It can easily be said that the primary function of a PLM solution is to organize and to bind together the various concepts which are handled by the trades relative to differing views of the "Product". The most known views are:  "As required" view (describing the uses and requirements for the future product),  "As designed" view (describing the product's technical reference solution)  "As to be built" view (describing a local industrial solution for the product)

 "As built" view (describing a real product which has already been built)  "As maintained" view (describing a real product which has been modified) It also covers configuration mechanisms and upholds the coherence of these different views, modification tracing, data access control (access rights) and the orchestration of the various tasks which handle these (responsibilities, workflow).

A PLM project in short

Since a PLM project must ultimately deliver a software application, this type of project is too often considered as an ordinary IT project. The apparent software nature of a PLM project is a trap which must not be fallen into. Even if the advent of a PLM solution in the application landscape represents an opportunity to rehabilitate and simplify (which is not trivial) by eliminating many established legacy programs, it is not an end in itself but rather an opportunity to restructure the company's technical craft. This is why a PLM project must be considered as being a project which is essentially related to the company's core business activity but with a software component to it.

As with any project, a PLM project potentially requires pure project management activities (like planning, resource allocation, budget fixing), project steering activities (like meetings with various committees) and project quality assurance activities (like project quality implementation plan, analysis and project risk analysis activities). As with any project which must ultimately deliver a computer-related solution, a PLM project may potentially require:  Application specification activities (identification of project issues, determining the project perimeter, formalizing the needs of users, functional and technical specifications, etc.),  Application construction activities (PLM software package parameterization, specific development and screen customization, associated application interfacing, etc.),  Application deployment activities (existing software landscape integration, data recovery and interface preparation and execution, etc.),  Activities regarding the migration of existing application data to the PLM (migrating data identification, preparation, consolidation, migration, etc.),  Activities surrounding application decommissioning (in order to guarantee that the PLM will be used efficiently and effectively and that "legacy programs" will eventually be removed from the application landscape),  Change management activities (adapted communication to several groups: project deciders and sponsors, project team members, key and end users, user training, administrator and user support activities, etc.). Each one of these activities does not weigh on the success of the PLM project and its overall efficiency in the same manner (generally apprehended via the Scope / Schedule / Cost [START_REF] Newell | Amacom, The Project Management Question and Answer Book Partridge C[END_REF].

A PLM has several recurring features which are almost systematically found in every PLM project. The first recurring feature of a PLM project is its transversality, which is to say that the processes which are sustained by the future software application cross over many of the company's functional areas (e.g. marketing, R&D, engineering and design, purchasing, production, logistics) and also many technical subjects (whose list closely depends on the nature of the product which is offered by the company and covers a very large spectrum of components : mechanical, electrical, electronic, pneumatic, software, chemical, organic, living beings, etc.). This implies that the different core business partici-pants in the company are capable of understanding each other and that the project team has the ability to make sure that they are coherent. The reason is that it is essential to identify and define the core business concepts which are handled through the activities in project perimeter. The second recurring feature of a PLM project is its major impact on the existing application landscape. This implies being able to precisely define which applications store and/or handle data within the project perimeter. The third recurring feature of a PLM project is its timeframe. It is generally acknowledged that a PLM project is one which is set over a length of time: many months or even many years are often required to deliver a complete PLM project (which is often organized into several projects). And of course, over this type of period, many kinds of changes are likely to appear (like changes in the company's organization, technological developments, and changes in the project's participants). This implies that the ability to express which needs must be fulfilled within the scope of a project by relying on invariable descriptions of the company's field of expertise is required. The fourth recurring feature of a PLM project is linked to the target application's nature as a software package. Nearly every PLM solution in the market is based on software packages which load a certain number of generic structures and/or mechanisms which must be configured in order to adapt them to the company's context. This implies ensuring that the selected generic elements (structural and/or functional) implementing each core business need are relevant. The reason is that this approach can be used to limit the immediate cost of specific development and the future costs of application maintenance.

Every previously cited feature confirms that a PLM project is first and foremost a company-related project. It is an "in depth" transformation project that affects how the company is run, and even if this transformation strongly affects the application landscape in the company, it's a transformation that must be steered by business and for business. It is also acknowledged that this type of project may become a structuring agent for an organization since, bearing the right tools, it forces the company to follow the rules and processes it has set out for itself.

As a result, a PLM approach is complex because it depends on many factors. In the next section, we will see that this complexity is also integrated into PLM specification activities.

The traditional approach and its pitfalls

This section will describe, within the context of a PLM project, how PLM specification activities are traditionally apprehended, which classic pitfalls result from them and what their root causes are. In this section and later in the article, we focus exclusively on PLM specifications activities because all others activities depend on the produced informations from this step.

PLM specifications activities positioning

The root cause comes from the fact that this kind of project is addressed from a computing perspective. In many cases, PLM software is selected in the earlier phase of the PLM project (even before user's needs are specified). It may also be justified by the fact that the organization already has a PLM solution in production and would like to change their solution (from minor version upgrade to editor's change). Evidence shows that more and more companies wish to drive PLM projects with an "Agile" method (of the "Scrum" type) as is the case for the development of functional components such as internet browsers. Another root cause is when the starting point to capture user's need consists in describing the "as is" situation by focusing on the current practice on the one hand and the evolutions of these practices on the other hand (said "to be" situation). Therefore, the business processes description (which should describe what the business has to do) become the application processes description (e.g. how the business makes things). In others words, instead of capture what the business does (independently of the manner), we capture the way things are realized (or will be), whom realize them, and how they are realized (like resources, tools). It means that user's need capture is done at a procedure level (describe the way to make an activity) instead of at a process level (describe what has to be done). This doesn't allow the organization to take a step back regarding theirs original and genuine needs.

Capturing information at a level which is highly functional and settling for "as is" and "to be" practical descriptions often results in implementing current practices to the upcoming PLM solution, since the description of needs was never done in a way which was focused on what needed to be done (independently to the motivations for doing so and the means to do so). In the end, the company will not have benefitted from the new opportunity to lay flat its core business processes and to reflect on a new way of putting them into practice, in a way closer to best industrial practices and more compatible with the standards in the PLM software package, all of which is provided by the PLM project. We may also encounter that the various business stakeholders may have trouble to understand each other, because from a functional level, the real profession has been erased. The capture is made from an applicative way whereas it should only be focused on the needs (push from PLM approach and/or selected PLM solution).

PLM specifications activities deliverables

Specifications activities produce a huge amount of informations which describe business organization in the company, PLM program organization, potential business scope and the one covered by PLM program, existing practices (using legacies system), future practices (using PLM solution), business process "to be", business concepts semantic model, logical data model and applicative cartography. This list is not exhaustive, but, what is important is that these deliverables are produced in corpus of document. The necessary information to complete activities to specify the PLM solution (define the trade perimeter and the parceling of the project, formalizing user needs, depicting core business processes, specifying system functions, etc.) is almost exclusively managed with office document-type support tools (Word, Excel, PPT, Visio, etc.). Unfortunately, this approach implies that a large corpus of documents is created, with many different documents relating to the same topics (business usage cases, artefacts and business concepts, business roles, application, etc.), viewed under different perspectives (process, responsibility, access to information, etc.) and created by different participants in the project (sponsors, business experts, solution experts, etc.) who often use different jargons.

The fact remains that this body of documents rapidly swells in the project development phase and becomes increasingly difficult to maintain, always requiring greater effort to preserve overall coherence. The resulting pitfall is that an important burden is dragged throughout every phase in the project, which consequentially reduces the productiveness of the project team and increases the risk for error.

Business/information system referential

This section allows showing that a business/information system referential approach is well-suited to support PLM specification activities. Essentially by the fact that it allows to avoid a large majority of traditional effects linked to deliverables produced form.

What's a business/information system referential?

A business/information system referential is a computer application which would allow storing all required elements representing deliverables contents (traditionally produced by PLM specification activities). It allows capturing elements from different levels such as business, functional and/or technical and the entire set of relations that we have to create in the aim of reconstitute the globality of information retrieved in traditional deliverables. The following table shows examples of the type of elements we could retrieved in a business/information system referential:

Workflows N/A

Note that what it is named here a business/information system referential (in the context of this article about PLM) could be renamed enterprise referential in the context of another approach such as Information system urbanization or enterprise architecture. In fact, if instead of taking in account PLM subsection of information system, we could considerate all the information systems of the company, we could execute a similar approach.

What are the main functionalities of a business/information system referential?

First and foremost, a business/information system referential has a model. It means that elements can only be captured in accordance with this model. In other words, it's model duty to allow defining what type of element to capture in the model and what type of relationship to capture between elements. It is also due to this model that user's need specification could be more oriented to the business level Then, a business/information system referential allows ensuring element unicity (independently of its type). In this manner, even if an element is used at several places in the referential, it's stored like a unique occurrence. For example, the same business role may occur in several business processes. The unicity of the information allows identifying that the business role is engaged into several business processes.

Finally, a business/information system referential allows allocating to a particular element one or several labels in one or several languages. In this manner, we are able to capture several designations for a same thing (as it is often observed in the same enterprise) and also in a multilingual way. For example, the same business concept is named differently by R&D and marketing team. Furthermore, we are able to determine new informations (from existing informations) using inference mechanism. For example, interaction between projects is induced by interactions between processes Also, knowledge referential can be considered like a structured database which can be requested to only extract some elements (depending on the context). For example, we may consider these extractions:  Compact or detailed representation of business process (with or without interims informations)  Provide adapted representation for each kind of actors in the different projects of a PLM program  Publish representations for all actors (synthesis)

The ins and outs of business/information system referential approach

This kind of approach allows facilitating the communication (less ambiguity or misunderstanding) between various team's actors (program, projects, business), respecting the terminology of each party and find a common term for each thing, ensuring each specification element unicity, global consistency and informations exhaustivity, helping actors to apprehend -without minimizing it -the complexity of a PLM demarch and providing to all a view of the PLM specification (with not more, not fewer informations). However, this approach is time consuming and should be started as soon as the PLM approach is launched.

The ins and outs of SEAMLESS

What's SEAMLESS?

In a few words, SEAMLESS is an assisted methodological semantic approach to modelize, capture and restitute (graphical and/or textual formats) the knowledge domain supporting a range of bordering activities. What it is called knowledge domain is all of the concepts and relationships underlying activities (independently of the type of these activities). SEAMLESS is an approach in the sense that it suggests a specific course of action to support its specific activities, in the instance of PLM specification activities within the context of a PLM project. SEAMLESS is methodological in the sense that this approach is rooted in best practices which are stable, invariable and repeatable, which adds formality and rigor to each step within this approach. SEAMLESS is semantic, in the sense that this methodological approach gives fundamental importance to specifying what it covers but also because one of the key components of this approach is the use of ontology (e.g. a formal semantic model with concepts). SEAMLESS is assisted, in the sense that this methodological semantic approach could theoretically be implemented without any particular tool, but in practice relies on a software solution which is specifically adapted to sustain it.

It is a key point to note that SEAMLESS has been initially designed to be applied on a knowledge domain (even far away from PLM); and that's why, in the scope of this section, the primary interest will appear to be focused on SEAMLESS approach and then on the particular application field: "SEAMLESS applied to PLM specification activities".

SEAMLESS fundamentals

SEAMLESS mission is to propose solutions which allow effectively equipping any controlled activity by PCO Innovation at an industrial level, quickly apprehending a new knowledge domain, capitalizing self-supporting semantic data (not about tools) and restituting all or some parts of knowledge domain by graphical and/or textual manner.

In the context of the missions (consulting or integration) of PCO Innovation, SEAMLESS allows properly understood communication by having the assurance to speak about the same thing (by the use of a semantic model), guarantying the coherence and description homogeneity of the scope (unicity informations), converging to the same terminology (differentiation between terms and concepts) [START_REF] Roche | Terminologie conceptuelle versus Terminologie textuelle Sirin E and Parsia B[END_REF], describing as much relationships as necessary between different elements -semantic network (Sowa 1991) -and identifying all susceptible elements to have an interest for the current application field (exhaustively).

In order to achieve this, SEAMLESS designs, develops and deploys solutions which allow equipping activities of increasing knowledge, management and necessaries informations restitution to execute a mission. These solutions are respectful of knowledge management and engineering best practices, adaptable to context (because they are comprised of generic software components, re-usables), consistent to web semantic technologies, norms and standards and based on open-source tools (like Jena API and Protégé software).

SEAMLESS approach is an iterative approach which allow specifying knowledge domain model, building knowledge model-driven referential (eg. populate the knowledge base with respect to the specified model) and, then, exploiting them using pre-cabled requests which allow representing and visualizing all or some parts of the knowledge referential.

Methodologies used by SEAMLESS directly report to knowledge engineering and management domains. They allow specifying semantic model of knowledge domain (textually or graphically expressed as a semi-formal mode) and then ontologies (expressed as a formal mode -eg. OWL)

SEAMLESS technologies

Tools used by SEAMLESS directly report to semantic web technologies norms and standards domain (Hebler, Fisher, Blace, Perez-Lopez and Dean 2009). Note that, in the matter of equipment, SEAMLESS may be considerate as Excel. It means that it is a generic tool which allows supporting a huge amount of various application fields.

Globally, this is a computer solution only constituted of generic standard components (eg. no links with PLM, PLM project, PLM specification activities or even with enterprise architecture) which are customizable by using ontology. This kind of application is named ontology driven application [START_REF] Kühne | Model-driven development: a metamodeling foundation Le Duigou J[END_REF].

The principle of this kind of application is that the ontology is used to drive knowledge base population with individuals (and links between individuals), which allow to guarantee the fact that the knowledge base respect as a whole all the rules (typing rules, optionality, cardinality, etc.) defined in the ontology. The generic components allow for example:  Storing ontology, storing individuals, add, read, modify and delete individuals from the knowledge base.  Requesting the knowledge base using SPARQL, infering new knowledge from existing knowledge using reasoner like Pellet (Sirin and Parsia 2004) or by creating new data with SPARQL, extracting informations about individuals  Putting these informations in a good shape (graphical and/or textual reports). Note that we basically use MS Office Excel to visualize tabular data, and yEd for graphical data.  Maintaining the knowledge base (save, export, import, back-up)

Conclusion and perspectives

We have shown that PLM projects are complex and business / information system referential could improve their efficiencies. The key component for reaching this goal is the ontology. Our current ontology is mainly focus on business concerns and information system concerns are just defined by a small set of core concepts. In the future, the ontology should be completed with more accurate concepts in order to cover a whole enterprise architecture scope : business, functional, logical & technical aspects.

Our SEAMLESS approach allows the knowledge base population thanks to an ontology-driven knowledge acquisition process. This is really an added value which allows to easily check the knowledge base coherency and/or completeness and also to produces text and/or graphical reports with a high quality level. But our acquisition module based on Protégé is not really suitable for end-user and not useful for collaborative knowledge acquisition. In the future, we could avoid those pitfalls thanks to a web interface for the knowledge acquisition process.

In short, one complete and relevant enterprise architecture ontology and an ontologydriven web interface for an ontology-driven acquisition process are the 2 mains perspectives for improving our global approach.

  This section will be used to define exactly what a PLM is by identifying what the PLM is used for, what PLM speak about, how PLM works and finally what are the reasons for a company to acquire a PLM.

Figure 1 :

 1 Figure 1: SEAMLESS functional architecture These different components are mainly used with an open-source license, but some of these are commercials. All remaining components are developed by PCO Innovation (like web applications, Protégé plug-ins).

Table 1 : Criteria to avoid pitfalls

 1

	Criteria	Description	Example
	Accurate se-	Don't have the possibility	The same business concept may exist in
	mantic	to associate several terms to	the corpus of documents but named in
		one concept (Roche 2011)	different manners.
	Translation	For each information, dis-	Each document has to be translated.
		pose of the translation in
		one or several languages
	Coherence	Dispose of a consistent cor-	The same business concept could be
		pus of document	implemented by 2 different applicative
			objects in the context of 2 projects
	Completeness Can list a specific kind of	Difficult to list all business roles in-
		information	volved in all projects
	Inference	Can easily deduce infor-	Not possible to deduce inter project de-
		mations from a corpus of	pendence from inter processes de-
		documents	pendence

Table 2 : Example of business/information system referential

 2

	Referential Level	Type of element	Example
	Business	Business	Business process	Design a product, Industrialize a
				product, Buy a component, etc.
			Business concept	Need, "As designed" product, "As to
				be built" product, etc.
			Business role	Designer, Industrializer, Buyer
			Semantic conceptual	N/A
			model


L Rousset-Rouviere

DGA I Sisakoun

FFI T Skauli

C Coudrain

Y Ferrec

S Fabre

L Poutier

SYSIPHE, an airborne hyperspectral system from visible to thermal infrared

ABSTRACT SYSIPHE is an airborne hyperspectral imaging system covering all atmospheric transmission bands from 0.4µm to 11.5µm: visible, NIR, SWIR, MWIR and LWIR. The ground sampling distance is 0.5m over a 500m swath, with higher resolution available in the visible and NIR. The imaging system, developed by Onera and Norsk Elektro Optikk, is flown on a Do-228 aircraft operated by DLR. The SYSIPHE system may also integrate a real-time processing capability developed by FFI and a ground post-processing chain, the STAD, developed by Onera. The main information products are georeferenced images of spectral radiance, spectral emissivity and reflectance as well as a surface temperature map. The system has completed its first flight campaign successfully in 2013. A qualification campaign for Defence needs was done during the summer 2015. SYSIPHE represents a significant enhancement of airborne sensing capabilities in Europe. The system will be made available soon to external users.

Index Terms-hyperspectral, infrared, remote sensing

MOTIVATION AND OBJECTIVES

The general objective of the SYSIPHE system is to validate and quantify the interest of spectral imaging techniques for defence, security and environmental applications. The SYSIPHE system will supply hyperspectral data that may be used in studies related to a variety of scenarios represented by ground scenes, even in real time. SYSIPHE requirements are based on both civilian and military applications. It can address a huge variety of applications like improved target/background separation or classification (including counter camouflage or target decoy), soil characterization and classification, vegetation studies, gas or chemical agent detection, bathymetry, hydrography and so on. SYSIPHE is characterised by its unique spectral coverage from 0.4 to 11.8 µm in the atmospheric transmission bands. This spectral coverage was the main driver for the implementation of three hyperspectral cameras into the same aircraft to provide spatially and temporally coherent measurements over the whole spectral domain. The pre-processing inherent to each instrument will lead to georeferenced and inter-band registered radiance data. In addition, a real-time pre-processing system could be used to demonstrate or to explore concepts of operation.

SYSIPHE SYSTEM

The SYSIPHE system was built in collaboration between France and Norway. It is unique by its wide spectral coverage, combined with a high spatial resolution (0.5m ground sampling distance over a 500m swath).

To achieve this performance, SYSIPHE is composed of three instruments: HySpex Odin 1024, for the visible, NIR and SWIR ranges, developed by Norsk Elektro Optikk in Norway (NEO), and Sieleters-MWIR and -LWIR, developed by the French aerospace laboratory Onera. These three instruments are integrated on the same aircraft, a Do228 operated by the German aerospace center DLR (see Figure 1). By having imagers for all bands in the same aircraft, SYSIPHE can produce georeferenced images of spectral radiance with more than 560 spectral bands. The SYSIPHE system may also integrate a real-time processing capability dedicated for target detection (developed by FFI) [START_REF] Skauli | An airborne real-time hyperspectral target detection system[END_REF], and a ground pre-processing chain, the STAD, developed by Onera to register the hyperspectral images of each instrument and to produce georeferenced outputs as spectral radiance, ground spectral reflectance, and surface temperature maps.

ODIN INSTRUMENT

HySpex Odin 1024 [START_REF] Loke | A next generation VNIR-SWIR hyperspectral camera system : HySpex ODIN-1024[END_REF] is the visible and shortwave infrared part of the SYSIPHE project. It was developed by NEO. It consists of two push broom imaging spectrographs based on transmissive gratings. These two modules share a common fore-optics and a common slit, to ensure perfect registration between the VNIR and the SWIR images. The spectral resolution varies from 5nm the visible to 6nm in the shortwave infrared.

The HySpex Odin-1024 has an onboard spectral and radiometric calibration source. The VNIR channel is capable of higher spatial/spectral resolution than the other SYSIPHE bands by sampling 2560 cross-track pixels. Figure 2 shows a single spectral channel of a georectified airborne hyperspectral image acquired by HySpex Odin-1024. Figure 6 shows an Odin image for the spectral channel at 1334 nm.

SIELETERS INSTRUMENT

Sieleters is the infrared component of SYSIPHE. It is composed of two distinct instruments, one for the midwave infrared domain ([3µm ; 5.4µm]) and one for the longwave infrared domain ([8µm ; 11.8µm]). The spectral resolution is 11 cm -1 in the MWIR and 5 cm -1 in the LWIR. Both instruments are cryogenic to achieve high performance absolute measurements, and both are imaging static Fourier transform spectrometers [START_REF] Poutier | COMANCHE and COCHISE : two reciprocal atmospheric codes for hyperspectral remote sensing[END_REF]. Figure 3 shows a Sieleters image for the spectral channel at 4.8 µm.

SYSIPHE FLIGHT ACCEPTANCE CAMPAIGN

A flight campaign was led in September, 2013, on the French air base of Cazaux. This site was chosen because the DGA-EV (French military flight test center) has a large active infrared target which allows to measure in-flight radiometric and imaging performances of airborne infrared systems. The Cobra target is composed with independent panels to create controlled temperature patterns. Most of parameters of Odin and Sieleters instruments were measured during this campaign (details for Sieleters can be found in [START_REF] Coudrain | SIELETERS, an airborne infrared dualband spectro-imaging system for measurement of scene spectral signatures[END_REF]). Table 1 gives a summary of the principle characteristics of the instruments. The spectra of three individual pixels are drawn on Figure 4 and Figure 5. They correspond to a pixel lying inside a large polystyrene target which was set on the ground (green curve), to a pixel lying on a white target (blue curve), and to a pixel lying on a dark target (red curve). Figure 5: Sieleters spectra of 3 individual pixels, respectively placed in the polystyrene target (green), the white target (blue) and the dark target (red) compared to the ground spectral radiance measure propagated to the pupil of the Sieleters instrument For Figure 5, the bold curves are the spectra from Sieleters measurements, the normal curves are the ground truth measurement propagated to the entrance window of the instrument Sieleters using Comanche code [START_REF] Poutier | COMANCHE and COCHISE : two reciprocal atmospheric codes for hyperspectral remote sensing[END_REF]. From these spectra, it appears that the signal to noise ratio has still to be improved. Various avenues are currently explored to enhance the SNR. Nevertheless, these spectra show a good agreement in terms of both spectral and radiometric calibration. The Odin spectra couldn't be compared to ground truth measurement due to the cloudy sky. In this atmospheric condition, the ground measurements are not validated.

ODIN

SYSIPHE 2015 CAMPAIGN

The data acquired during the 2013 airborne campaign couldn't address all the verification needed to qualify the SYSIPHE system, especially the verification of the calibration of the instruments and the atmospheric correction software used in the STAD. For this reason, a new airborne campaign was scheduled in August 2015 where measurements with clean sky were done.

This campaign was located in the South of France, in the military base of Canjuers. A ground truth workshop was deployed covering different targets (Figure 6). In parallel, military scenarios were deployed in the Canjuers base to acquire full bandwidth hyperspectral images with SYSIPHE. The campaign was led from 17th of August to 2nd of September 2015. During this campaign, the system flew 7 times including a night flight. Different meteorological conditions were encountered: clean sky, partially cloudy, windy, opening new studies on the robustness of hyperspectral products in function of the weather conditions.

CONCLUSION

SYSIPHE is now at the end of its initial development phase. The flight acquisition was performed with a large success demonstrating the operability of the spectro-imagers for airborne campaign. Laboratory and in-flight measurements are in accordance with the expected performances. Hyperspectral airborne images acquired during the qualification 2015 campaign are currently being processed.

The SYSIPHE system will be proposed soon to external users for military or scientific/civilian purposes, with an ability to offer turnkeys campaigns with a wide range of support options, including organization of airborne campaigns and data processing.

( 1 )

 1 Rouvière 1 , I. Sisakoun 2 , T. Skauli 3 , C. Coudrain 1 , Y. Ferrec 1 , S. Fabre 4 , L. Poutier 4 , Y. Boucher 4 , T. Løke 5 , S. Blaaberg 5 ONERA, centre de Palaiseau, chemin de la Hunière, 91761 Palaiseau cedex, France (2) DGA, -60 Bd du Général Martial Valin 75509 Paris cedex 15 -France (3) FFI, P O Box 25, 2027 Kjeller, Norway (4) ONERA, centre de Toulouse, 2 avenue Edouard Belin, BP 74025, 31055 Toulouse cedex 4, France (5) Norsk Elektro Optikk AS, Prost Stabels vei 22, N-2019 Skedsmokorset Norway

Figure 1 :

 1 Figure 1: The Do-228 with the hatch opened

Figure 2 :

 2 Figure 2: Monochromatic (1134nm) georectified image acquired by HySpex Odin-1024

Figure 3 :

 3 Figure 3: Monochromatic (4.8µm) image acquired by Sieleters-MWIR

  extended betwwen 2013 and 2015since 2014 ‡ in-flight estimate from out-of-band signal during 2013 campaign

Figure 4 :

 4 Figure 4: ODIN spectra of 3 individual pixels, respectively placed in the polystyren target (green), the white target (blue) and the black target (red).

  Targets and reference ground surface for ground truth measurements. (a) black and white panels, (b) linoleum panels, (c) polystyrene panel, (d) painted concrete, (e) sand, (f) clay.

Table 1 :

 1 Main technical specifications for Odin and Sieleters (values are subject to change due to on-going development)


Shinji Mochida
email: shinji_mochida@red.umds.ac.jp

A study on developing a decision support agent for project management

Keywords: project management, knowledge, agent, prioritization

The term "business system" refers to the methods which use to manage their information or knowledge. All companies employ business systems during the development of new software, mechanical equipment or other projects. There are several stages in development projects. There are stages of planning, development, system examination, and upgrade. However, because business knowledge and system development knowledge are united in the systems engineer individual, and the final system image is designed in the engineer's mind, the knowledge earned in the project is not adapted to the next system development project. Business knowledge and system development knowledge are different. A unification of measures for value of these two types of information is needed to treat the information equally. Then, this paper aims to achieve the decision support agent. This decision support agent should have the function of evaluating the value of knowledge and supporting judgment through all stages of the project. Additionally, because the environment around the system development is always changing, a function to evaluate the importance of knowledge from the data stream is needed so that the decision support agent may acquire and interpreted information in real time.

Introduction

In business development projects, there are stages of planning, development, system examination, and upgrade. However, the person in charge of each these stages are different, and knowledge is not adapted to the next system development project. The uncertainty of scope, project duration and cost planning are repeated every time during development project due to knowledge shortages. These uncertainty causes schedule delays and cost overruns for the project [START_REF] Parviz | PROJECT ESTIMATING COST MANAGEMENT[END_REF] [START_REF]A Guide to the Project Management Body of Knowledge: Official Japanese Translation[END_REF]. One reason for cost overruns is that during the requirement assessment stages of a project, each project engineers' level of skill and experience is variable. This paper will use the term' subject ' to engineering staffs, engineers. Subjects may misunderstand the scope or requirements of the clients. Thus subjects do not know the best way to make the system at the early stage.The progress management is important and difficult work while the project is executed [START_REF] Royer | Project Risk Management[END_REF][4] [START_REF] Tyler | Practical Project Evm: The Application of Earned Value Management to Project Management[END_REF]. Generally in a business system development project, the feasible scope and the achievement method are designed after the subject investigates or studies the business for systematization. Business knowledge and system development knowledge are united in the systems engineer individual, and the final system image is designed in individual subject's mind. Thus, if business knowledge and system development knowledge are treated in the same way and used at the early stage of the project, it becomes possible to plan the duration and cost of the project accurately. Sub-optimization is necessary to develop the productivity and reduce costs of projects. Developing the productivity is important to achieve the sub-optimization. Offering appropriate knowledge to the all subject at appropriate time is necessary to develop the productivity and reduce costs of developing business systems.

Previous Studies

The current research studies techniques for the accumulation of information that is distributed and exists in the computer system, and also implements knowledge mining using a high performance computer [START_REF] Rzepka | Common Sense from the Web? Naturalness of Everyday Knowledge Retrieved from WWW[END_REF]. However, there is no research on unification of values to deal with different information, such as business knowledge and the system knowledge, etc. in the same way. Moreover, there is no research that analyzes, evaluates the data stream including environmental information from consecutive work, and acquires knowledge continuously during a project [START_REF] Agrawal | Mining Sequential Pat-terns[END_REF]. Many researchers are studying techniques for implementing knowledge mining from information that has already been acquired, not real time processing [START_REF] Nakagawa | Detecting Errors in Corpora Using SupportVector Machines[END_REF].

Productivity and Knowledge

This paper aims to achieve a software agent that collects effective business knowledge and system development knowledge in the business system development projects. Figure 1 shows software agent. First this research need to create the function of compiling knowledge in Figure 1 for the software agent [9][10]. This software agent should have a function to evaluate the value of information automatically and support subject's judgment in all stages of the project. These judgments will allow subject to decide which work to do at what time. This paper will refer to this software agent as "the decision support agent". This decision support agent should is expected to accumulate, and maintain the knowledge acquired from all stages of the project, as well as to offer the knowledge to the all subject when necessary. When subjects engage in the project, it is thought that productivity increases as time spent on the project passes. This also assumes that productivity is low at the beginning of the work because necessary skills have not yet been developed and there is luck of detailed information necessary to start the work. We collected the productivity data from the computer system development project, and apply to the Weibull distribution. Thus we defined the model which is suitable for productivity curve in order to estimate productivity at specified time. The physical model and parameters are shown in Expression [START_REF] Parviz | PROJECT ESTIMATING COST MANAGEMENT[END_REF].If the productivity data collected from a computer system development project is substituted into Expression (1), then productivity at a certain time is obtained by f(t) as shown in Figure 2 at time:t, and Table 1 shows the parameters obtained from the screen design work in a past system development project. Figure 2 was created using the parameters obtained the system development project.

K : f inal productivity a : preparationdays : studyresistance m : pro f iciency d : workrepetition (1) Table 1.
parameters gotten from the screen design work

d a t K t f m              ) ) ( exp( 1 ) (



The area of square in Figure 2 shows the planned work days and graph shows actual work days. Figure 2 shows the difference of actual work days and planned work days. In this example, it was estimated that it would take 11 days to finish the part of the project, however 25 days were required. The number of actual work days shown Figure 2 as the area under the curve F(t) were integrated using F(t) and t(time). The number of calculated actual work days was 12.8 days, while estimated work days were 11 days. In this example, therefore, calculated actual work days are nearly equal to planned work days. If high productivity achieved, then work will finish according to the schedule. Preparation work is necessary to achieve the expected level of productivity. The productivity does not increase if there are mistakes in preparation. Mistakes in preparation are caused by lack of knowledge or appropriate preparation work not be done. It is necessary for all subjects to decide what they must do before beginning work. Then, this paper proposes a method to recognize the work launch date. The work launch date is the day when information gathering and a preliminary examination of the project is begun. Assigning a work launch date which allows all subject to complete appropriate preparation work in anticipation of the planned work start date is necessary in order to achieve high earlier in the work cycle and shorten the number of work days. Because it is inevitable that there many tasks to be completed simultaneously, for example; scheduled task, preparation task for the next task, and troubleshooting work, it is important for subject to judge what they should do during preparation work phase as follows in Figure 3. All subject needs to prioritize their tasks. Then the psychological value which subject set on each task effects how they prioritize their takes. The psychological value which subject set on each task is limited by the short-term memory and their actual understanding at each task. Then, the decision support agent should support the selection of the most important task to do at each specific time. During any task it is especially necessary to make time to prepare for the next scheduled task. Then, the decision support agent should understand each subject's working characteristic, their skill and their involvement in other tasks. Prioritization mistakes during the preparation work phase causes schedule delays and cost overruns in projects. Work efficiency during the entire project decreases because of mistakes in preparation.

Set the Work Priority Level

Selecting the appropriate work that should be done at any given time is very important in order to increase the productivity of a project. The efficiency of the subsequent work does not increase when there are preparation mistakes in the project. It becomes impossible for the subject to accurately set a priority level for each task accurately when two or more tasks are being executed. Especially, because environmental conditions change hour by hour, it is difficult to select an appropriate task. Usually in such a case tasks are selected according to the experience of the subject. Then, one of the support functions of the decision support agent is to set appropriate priority levels for each task. Awareness of the environmental condition is necessary in order to select the work accurately. Then, the task selection process was examined by the questionnaire which has some completion targets; today and tomorrow, the day after tomorrow and complete in one week. For example, the task which should be done by today is review of the plan. The task which should be done by tomorrow is creating the schedule of tasks. The task which should be done by the day after tomorrow is creating documents of tasks. The task which should be done one week after is checking the report of tasks. Figure 4 shows the result of the subject selection process when subjects are asked to choose which tasks they would begin working on during three time periods; today, tomorrow, the day after tomorrow. In the questionnaire subjects are asked to order three out of four tasks over three days(designated today, tomorrow and the day after tomorrow);by according to their first, second and third priorities. The task which subjects wants to begin previously has high priority. Figure 5 shows the results in a situation similar to Figure 4 when subjects are asked to choose which tasks they would begin working on during four time periods; today, tomorrow, the day after tomorrow, one week after. From the above results, the priority level of the tasks is set according to the time limit in logical in Figure 4. However, the priority level of tasks is not set according to the time limit in Figure 5. Figure 5 show that subjects do not always consider the time limit when prioritizing tasks over a longer range of time. Subjects are expected to select tasks according to the time limit, and not their individual skills. In actual working situations the prioritization of tasks would be left to the subject's individual skills. A Person's short-term memory is one reason why appropriate work cannot be selected. The shortterm memory is maintained for only a few minutes. Because the time when subjects get the information about the tasks is different, prioritizing the tasks is not correctly evaluated in the subjects' minds. It is said that human can memorize only 10 pieces in a few seconds~ [11][12]. There is a limitation in the number of tasks which a subject can prioritize within a specific time. Revisions in order to improve execution efficiency 5

Changes in Productivity

There are changes in productivity in the system development project as follows in Figure 6.Figure 6 shows productivity during the system development project. Productivity is measured according to increases or decreases in the number of lines of source code per an hour. The programming criteria of productivity which we have is 60 ~ 200 Line/day(Not include comments).The main reasons why productivity decreases are shown in table 2. From table 2, we can understand that it is necessary to clarify specifications and avoid violations of coding standards in order to improve productivity. Additionally, revisions in cording following review or specification changes are a one of the major causes of work delays. Offering appropriate knowledge is important to improve the productivity of staffs. Thus it is necessary to compile not only technical knowledge for programing but also knowledge for assessing of requirements of clients. One of functions to compile many kind of knowledge for decision support agent is creating. Additionally prioritizing tasks is vital to offering appropriate knowledge when it is needed. It is necessary to evaluate correctly the difficulty of their tasks according to their current working situation. Observation of the environmental conditions in real time is needed in order to evaluate the appropriate time when appropriate knowledge should be offered. It is necessary to be aware of the changes in the work situation to prioritize object's tasks. Productivity is changing every day. Prioritizing tasks appropriately is important to prevent cost overruns and delays in system development project.

Decision support agent

This paper aims to demonstrate the efficient of the decision support agent. This decision support agent should have the function to evaluate the value of knowledge and offer that knowledge to the subjects at the appropriate time. Additionally, the decision support agent should have the function to prioritize subjects' tasks in all stages of the project according to the environmental situation. Importantly, Figure 7 shows that subjects give the same level of priority to tasks both one week and one month in the future, thus leading to incorrect prioritization of their assigned tasks. Because subjects cannot effectively prioritize tasks further than one week in the future (see Figure 7), it is necessary to support subject's prioritization of tasks. Additionally, the decision support agent is needed to support prioritization of subjects' tasks when dealing with various kinds of interruptions. The decision support agent should also have the function of taking into account the subjects' work pat-terns as follows in Figure 8. Figure 8 shows a histogram of the self-reported level of concentrated for two subjects during a typical day of work on the system development project. Then, this paper proposes the decision support agent in Figure 1 .The decision support agent prioritizes their tasks according to the score obtained by the following Expression (2). Expression [START_REF]A Guide to the Project Management Body of Knowledge: Official Japanese Translation[END_REF] shows the f(x,t);function which calculates of prioritization of tasks according to their complexity. This f(x,t) is the most important function of Decision support agent. Because as tasks become more complex, the figures become larger. In this function smaller values indicate a higher priority. Simple task is needed a few knowledge. It is important that tasks can be done in order of it is easy to work and simple. This f(x,t) shows priority level of the task x at time t. g(x,t) shows the number of knowledge for completing the task at a specific time t. h(x,t1) shows proportion to have obtained knowledge for completing the task at time t. Table 3 shows the expected effect when the priority level of tasks are appropriately set by this function; f(x,t), and revision work is not generated. The productivity of the system development project is shown by the amount of increase in the amount of source code. (2)

Discussion

In this study the researcher gathered data from an actual information retrieval software project. In order to increase the productivity of software development, this study proposes a formal or explicit work lunch date be set. The work launch date is the day when information gathering and a preliminary examination of the project is begun. In the management of a project launch date, a preparation work phase will be added before the actual work phrase. In the preparation work phase it is necessary to achieve a required level of productivity for the scheduled work. During this preparation work phase, there are many tasks which must be done at specific times. For example; scheduled tasks, preparation for the next stage, and troubleshooting. It is important for subjects to prioritize when must begin each specific task. It is also necessary to schedule their task in detail during each week. Then, this study proposes a decision support agent which is able to prioritize objects' tasks according to the score generated by the function in Expression (2) and which offers subjects applicable knowledge. Additionally, this agent should take into account the subjects' work patterns as shown in Figure 8. Although in the function in Expression (2) the connection between tasks is not expressed. Future tasks should take into account the environmental information to prioritize the tasks appropriately and clarify the effect of the prioritizing function; f(x,t). Meeting budget, finishing on schedule, and maintaining high quality are all important in project management. Because project managers and engineers are usually working on multiple projects simultaneously, they must be able to make appropriately prioritized decisions in order to achieve these three goals. Then, this paper shows that it is effective to schedule a formal work launch date one week prior to the planned work start date, and to prioritize engineers' tasks appropriately. However, further research and study is needed to refine and improve the method of prioritizing engineers' tasks especially in the week before the planned work start date.

Fig. 1 .Fig. 2 .

 12 Fig. 1. Decision support agent software

Fig. 3 .Fig. 4 .Fig. 5 .Fig. 6 .

 3456 Fig. 3. work start date and work launch date

Fig. 7 .Fig. 8 .

 78 Fig. 7. Task priority values

Table 2 .

 2 Reasons

		why productivity decreases
	NO	Reason why productivity decreases
	1	Insufficient time to revise work according to new specifications
	2	Revision work to correct cording errors
	3	Revisions in cording standards following review
	4

Table 3 .

 3

	Expected effect
	project name	L(lines)	D(lines)	H 1(hours)	H2(hours)
	A	44478	1348	964	28.9
	B	52746	21505	1616	618
	C	8589	91	973	10.7
	L :	The total number of lines written
	D :	The number of deleted lines
	H1:	Total working hours
	H 2:	Working hours which could be saved if revision work is avoided.

Acknowledgment

This work was supported by JSPS KAKENHI Grant Number 24500266.