Jarl Höglund
email: jarl.hoglund@allmentor.se

Anne Persson
email: anne.persson@his.se

Up-stream and Down-stream Quality in Enterprise Modeling Practice -Supporting Model Driven Continuous Improvement in Organizations

Keywords: Enterprise Modeling, process quality, successful implementation of enterprise models, continuous improvement

The paper identifies and discusses what is considered to be the three most critical points, both up-stream and down-stream to Enterprise Modeling, for ensuring the usefulness and use of EM results in the continuous improvement of organizations. The model type that is targeted in the cases discussed in the paper is the process model, but other related model types, e.g. goal models and concepts models are also addressed in relation to process models. The points addressed in the paper are: 1) Trigger handling -acting on symptoms or the root cause problem, 2) critical aspects during modeling, and 3) establishing mechanisms for continuous model based business process improvement.

Introduction

There are two main reasons for using Enterprise Modeling (EM) [START_REF] Persson | An explorative study into the influence of business goals on the practical use of Enterprise Modelling methods and tools[END_REF]: • To develop the business. This entails developing business vision, strategies, redesigning the way the business operates, developing the supporting information systems, etc. • To ensure the quality of the business. Here the focus is on two issues where EM can play an important part: [START_REF] Persson | An explorative study into the influence of business goals on the practical use of Enterprise Modelling methods and tools[END_REF] sharing the knowledge about the business, its vision and the way it operates, and (2) ensuring the acceptance of business decisions through committing the stakeholders to the decisions made. In addition, EM can be used as a vehicle for communication and visualization in organizational problem solving.

Examples of EM methods can be found in [2, 3, 4, 5, 6 and 7]. Examples of application domains for EM can be found in [8, 9, 10, 11 and 12].

In order to achieve high quality results, the modeling process is equally important as the modeling language used. There are two levels of EM process:

The EM project level, where the modeling activities are placed in a context of purpose. [START_REF] Stirna | Purpose Driven Competency Planning for Enterprise Modeling Projects[END_REF] describes the generic process including the activities listed in Table 1. These activities can be categorized as belonging to two levels:

The modeling level where domain knowledge is gathered and enterprise models created and refined. When it comes to gathering domain knowledge to be included in enterprise models, the main EKD way of working is facilitated group sessions. In facilitated group session, participation is consensus-driven in the sense that domain stakeholders "own" the models and govern their contents. In contrast, consultative participation means that analysts create models and domain stakeholders are then consulted in order to validate the models. In the participatory approach stakeholders meet in modeling sessions, led by a facilitator, to create models collaboratively. In the sessions, models are often documented on large plastic sheets using paper cards. The "plastic wall" (Figure 2) is viewed as the official "minutes", for which every domain stakeholder in the session is responsible. There are two main arguments for using the participative approach, namely: • The quality of models is enhanced if they result from collaboration between stakeholders, rather than from consultants' interpreting stakeholder interviews. • The approach involves stakeholders in the decision making process, which facilitates the achievement of acceptance and commitment. This is particularly important when modeling is focused on changing some aspect of the domain, such as e.g. its visions/strategies, business processes and information system support.

In this paper we address these levels of the EM process, but we also take a step up from the process and puts this process in the context of continuous implementation of model-driven organizational improvements to achieve changing organizational goals. We call this the control level. The full EM lifecycle can be outlined as follows. It is also depicted in Figure 1. 1. Something triggers the need to investigate a potential change in the organization.

This trigger can be a business opportunity, a challenge, a problem or a symptom of a problem. A choice is made to use EM in the investigation and potentially also to design a change to business operations. 2. The EM project is initiated and executed according to the process described in [START_REF] Stirna | Purpose Driven Competency Planning for Enterprise Modeling Projects[END_REF]. 3. The implementation of the resulting models is planned and executed and the models now become part of the day-to-day business processes. 4. Continuous improvements are made. Some of these improvements could be supported by EM. Changes of greater importance will most likely cause the process to start over from 1. The outcome or effect of the implementation of models is very much dependent on • How the EM project is planned and executed. From the point of view of the EM project we call this down-stream quality. Managing modeling and model quality is one aspect here as well as the many facets of managing the EM project as a whole. • How the implementation and continuous improvement of the resulting models is planned and executed over time. From the point of view of the EM project we call this up-stream quality.

Their position in the continuous improvement process is depicted in Figure 2. Effectively managing these two types of quality will ensure that the intended effect of modeling and the resulting models will materialize, not only from a short-term perspective but also long-term.

This paper is an experience paper that heavily relies on the experiences of the first author of the paper from 27 years of Enterprise Modeling and Enterprise Modeling method development. In fact, the first author was involved in developing the Swedish ABC EM method [START_REF] Willars | Handbok i ABC-metoden[END_REF] that is the predecessor of both the Astrakan EM method 1 , that has become quite a popular EM method in Sweden, and the Enterprise Knowledge Development (EKD) EM method [START_REF] Bubenko | User Guide of the Knowledge Management Approach Using Enterprise Knowledge Patterns, deliverable D3[END_REF]. He was also involved in developing participatory ways of working. The paper also builds on the experiences and research of the second author. She has, since the 1990-ies, specifically targeted the practice of EM in her research but has also substantial practical experience from EM projects. She has contributed to the development of the EKD EM method [START_REF] Bubenko | User Guide of the Knowledge Management Approach Using Enterprise Knowledge Patterns, deliverable D3[END_REF].

The goal of the paper is to identify and discuss what is considered to be the three most critical points, both up-stream and down-stream to EM, for ensuring the usefulness and use of EM results in continuous improvement of organizations. The model type that is targeted in the cases discussed in the paper is the process model, but other related model types, e.g. goal models and concepts models are also addressed in relation to process models. The points addressed in the paper are as follows:

• Trigger handling -acting on symptoms or the root cause problem.

• Critical aspects during modeling • Establishing mechanisms for continuous model based business process improvement.

The remainder of the paper is organized as follows. Section 2 discusses the need to make decisions in starting an EM project that address root causes rather than symptoms. In section 3 some critical aspects in modeling are discussed, critical in the sense that we want to achieve organizational effects. The point of departure is process modeling. Section 4 focuses on how an effective mechanism for continuous organizational improvement can be implemented. Throughout the paper, illustrative examples from real life cases are provided. Finally, in Section 5, some concluding remarks are given.

Trigger Handling -Acting on Symptoms or the Real Root Cause

In order to ensure that the process of continuous improving organizational operations really serves the purpose of making the organization fit to take on its challenges and to prosper, it is essential that the organization acts on the "right" signals/triggers. This implies that the analysis of triggers needs to get enough and qualified attention, as a basis for making decisions about starting a change process. This will ensure that the EM project rests on firm ground from the start. We are simply starting the EM project for well-grounded reasons and with a goal that will effectively improve business operations. To illustrate this point, we describe two real life cases, one successful and one less successful.

A successful case -getting at the root causes

Situation

A construction vehicle supplier with workshops for repair and maintenance all over Europe spends/wastes time and money. Some 5-10 administrators in each region are involved, on a daily basis to handle incorrect invoices, i.e. to credit and to correct failures. This is due to invoices stating the wrong amount and/or receiver. After correcting the errors, they finally send the correct invoices. Too many stakeholders are involved in this error correction process. This causes irritation and dissatisfaction for the involved stakeholders, but most serious is that no value is created. Action Nobody could state a "one and only" root cause to the problem, so a problem investigation was carried out. In order to involve the right participants a stakeholder diagram was made. A group of five prime and motivated members were selected and guided by a facilitator and they took on the task of carrying out the investigation.

Method

The method that was used was Root Cause Analysis (RCA) [START_REF] Oaks | Root Cause Analysis: the Core of Problem Solving and Corrective Action[END_REF]. This is a method that has shown to be effective also to analyze the implications of new opportunities and threats, as an alternative to a SWOT analysis. The general principles of root cause analysis are as follows:

1. The primary aim of RCA is to identify the factors that resulted in the nature, the magnitude, the location, and the timing of the harmful outcomes (consequences) of one or more past events in order to identify what behaviors, actions, inactions, or conditions need to be changed to prevent recurrence of similar harmful outcomes and to identify the lessons to be learned to promote the achievement of better consequences. ("Success" is defined as the near-certain prevention of recurrence.) 2. To be effective, RCA must be performed systematically, usually as part of an investigation, with conclusions and root causes identified backed up by documented evidence. Usually a team effort is required. 3. There may be more than one root cause for an event or a problem, the difficult part is demonstrating the persistence and sustaining the effort required to develop them. 4. The purpose of identifying all solutions to a problem is to prevent recurrence at lowest cost in the simplest way. If there are alternatives that are equally effective, then the simplest or lowest cost approach is preferred. 5. Root causes identified depend on the way in which the problem or event is defined. Effective problem statements and event descriptions (as failures, for example) are helpful, or even required. 6. To be effective, the analysis should establish a sequence of events of timeline a to understand the relationships between contributory (causal) factors, root cause(s) and the defined problem or event to prevent in the future. 7. Root cause analysis can help to transform a reactive culture (that reacts to problems) into a forward-looking culture that solves problems before they occur or escalate. More importantly, it reduces the frequency of problems occurring over time within the environment where the RCA process is used. 8. RCA is a threat to many cultures and environments. Threats to cultures often met with resistance. There may be other forms of management support required to achieve RCA effectiveness and success. For example, a "non-punitory" policy towards problem identifiers may be required.

Outcome

In contrast to the visible symptoms the following severe root causes resulted from the analysis. They were supported by hundreds of post-its on a big plastic folio on the wall, well sorted/related to each other: 1. The processes and their interfacing objects were not well defined. One aspect was mixed value-chains where, e.g., a vehicle all of a sudden became an invoice in the same process. Also, the input/output objects for steering and supporting processes were not satisfactorily specified, so in this case the workshop process was not quality controlled in its context. 2. At the customer reception the rules and policies to conform to, were too broad and complex and not easily accessible so the workshop receptionists hardly adhered to them. 3. The way to measure and reward responsible actors was in severe conflict, e.g. the workshop and service contract managers´ KPIs were not aligned. Rather they were in conflict. 4. There was a lack of functionality and data accessibility in the IT support and there were also a variety of different systems in use. All in all, the IT support did not support the processes. A number of opponent sessions according to the Astrakan EM method were then organized. In opponent sessions important stakeholders who have not been involved in creating the enterprise models are invited to discuss and criticize the models. This increased the quality of the analysis and created broad participation and commitment to invest and solve the key problems, i.e. it paved the way for next coming steps of successful improvement of the business operations. The four root causes became the basis to set a distinct purpose for next investigation project.

A less successful case -acting on symptoms

Situation

A number of problems were experienced in the existing ordering process at an international high-tech company. The problems referred to were mainly overload, long lead-time and quality problems. Action No root cause analysis was made. The process was initially not described in relation to its context, so the interfaces to other processes were not included in the first analysis workshops.

The purpose of the first analysis was unclear, meaning that needed level of detail was not indicated. Substantial time and resources were spent. The project finally made a backward and forward analysis and found the sources of the main problems to be in processes before and after the ordering process that was initially the focus of the analysis.

The assignment was expanded to include the whole process from Sales to Delivery, thus including the ordering process.

The analysis resulted in (1) demands on IT-projects in order to enhance the interfaces between current IT-systems and (2) make process interface agreements between the main processes.

Method

No method was really used from the start. Later the Astrakan EM method was used, both in order to identify and define the context of the process and to identify the process interfaces. Based on a concepts model, the terminology was aligned between the processes, thereby minimizing misunderstandings and as basis on which to update the requirements on data availability in the IT-support. However, by then the company had spent a large amount of resources and not getting anywhere in their efforts to solve the problem.

Lessons learned

Already when we were 3-4 years old we stressed our parents by asking the question "WHY?" until we thought we had a sufficient answer, and then we were pleased. That behavior is natural for us as human beings and is one of the most important and easy to use "tools" in Root Cause Analysis and also in the Toyota Way, the LEAN Concept.

The main lessons that we learn from the above cases are: • The situation that initially triggered the need for change must be clearly identified, and as soon as possible too, otherwise valuable time and resources will be wasted. Acting on symptoms as without asking the question why enough times is always bad. • It is essential that the project manager or consultant involved arms herself/himself with sufficient arguments to justify why investments should be made in a Root Cause Analysis before the EM project is initiated and staffed. • It is advisable to use a proven easy-to-use method, e.g. Root Cause Analysis (RCA). Free hands-on documentation about how to use the method is available on the web.

Critical Aspects during Modeling

Business/Enterprise Improvements are like making a journey or to go on an expedition. The better map you have the more pleasant and timely the journey or expedition will end. You will also know how to make the journey the next time, and you will have your eyes open for shortcuts or more scenic roads, i.e. added value. In EM a Process Model takes the role as the key map. It functions as the handrail where actors, information objects, rules/policies etc. can be attached in resource layers.

Complementing models (e.g. goals models, concepts models and rules model) will be added depending on the cause and purpose of the improvement at hand.

Case 1 -a systematic way of driving towards improvement

Yet another global company takes a strategic decision to sharpen a total solution concept and to increase the margins from the growing post market. The first steps were to analyze and describe a total solution sales process and to make a benefit analysis for the company and the customers. An EM project was started. All key roles were identified (project manager, business analyst, modeling facilitator, experts from the business operations). The key steps from a modeling point of view were: 1. Stakeholder analysis 2. SWOT analysis (not only filling the diagram, but to discuss and document conclusions which justified and updated the purpose of the investigation) 3. Modeling of the main process map using the Astrakan EM method was carried out in order to set the new sales process in its context. a. The start and end of the process was identified. b. Interface objects to/from the steering and supporting processes were identified as well as the interface to customers´ purchasing process. c. The future solution sales process was described using extensive interaction with stakeholder experts. d. In resource layers rules/policies were mapped to the process as well as actors and interfaces to existing and required IT-support. 4. A benefit analysis proved the importance to start the most critical sub-projects for improving business operations suggested in the project report, which was based on the models. This approach proved to pave the way towards successful implementation of change.

Case 2 -lack of knowledge in the organization about how to run improvement projects

This case involves an organization that manages a large pension fund. The main focus is on the back office function on which most other functions in the organization were dependent 24/7. Bad timing and bad quality in reports accelerated the stress on individual employees and on the function´s interfaces, externally and internally.

An external consultant was assigned with the task to interview some stakeholders as a start. He indicated that the next coming step needed to be to do an initial investigation according to what was described in section 2.1 using EM. In parallel with the interviews the consultant started to make a stakeholder diagram and a main process map including interfaces to critical external actors. He paved the way for the next steps, but then something happened. When the interviews were made he was expected to give a full report of "what to do to solve the problem". The project was halted.

Lessons learned

From the second case we can learn that it cannot be taken for granted that the problem owner/project initiator has insights in EM and is willing to carry out improvements accordingly. For internal as well as external consultants it is crucial not to start this type of investigation, or any EM activities for that matter, without double checking that the purpose is realistic and accepted, e.g. in terms of the way of working, resource availability, before starting the investigation. Make a plan and have it formally signed off! If the organization, and particularly the problem owner, is not familiar with EM as a method an additional challenge is to "sell" the method to the organization and to get it accepted and sufficient resources allocated. The problem owner will always want to cut corners in terms of resources and to find shortcuts to what could be perceived to be a quick and solution. The quality of the outcome of EM will never benefit from this, and neither will the organization of course.

Establishing mechanisms for Continuous Model Based Process Improvement

EM's moment of truth is when the future state process is implemented, a responsible process owner is in control, measurements are in place and used for continues follow up and rewards of process performance and continuous improvements. New opportunities and threats emanating from external or internal sources will challenge or ask for attention. Finding the complete toolbox to cope with continuous improvements is a never-ending process. The quality of the map is crucial here, i.e. the process model and supporting models, which calls for quality assurance in all steps preceding the implemented and running process in its context.

Here we can find a positive case in Scania CV AB, Sweden, where continuous improvement is in "the spine" of all employees. Many academic papers have already been written referring to Scania and Continuous Improvements2 , so we will not go into any detail about how this improvement process is organized.

What differentiates Scania in continuous improvements is perceived to be the following:

•

The enterprise culture and leadership supports continuous improvement • All employees are treated as experts in their role

•

The personnel are loyal and proud of the company and their own work

•
A problem is always turned into a possibility • Working in teams is encouraged • "Right from me" is a well-established attitude in all personnel. This means that people make sure that what they deliver is correct and follow a high standard of quality.

•

There is an established arena for dialogue/control/support, the "PULS" meetings, where all improvement activities are prioritized, are followed up, discussed, supported and made visible and thereby known and understood.

•

There is an awareness of the fact that change may take time and is done in small controlled steps.

•

There is a Scania Development Process supporting continuous improvements, where one of the initial phases is always Enterprise Modeling. The effect of this is that the process of EM supported continuous improvement is kept alive and that external and internal triggers for change are properly analyzed and acted upon. Scania has proved to have a high degree of satisfied customers. The company has a high resilience in difficult times. E.g. in one of the latest financial crises many companies decided to lay off personnel. In Scania, on the other hand, the employees showed their loyalty by accepting a 4-day working week and a subsequent loss of salary of about 10 %. During the crisis the company involved their personnel in training activities. When the crisis decreased everyone was ready to start again but with an even better capacity.

Concluding remarks

There has been much research into the quality of enterprise models (see e.g. [START_REF] Krogstie | Process models representing knowledge for action: a revised quality framework[END_REF]). However, more attention needs to be paid to the conditions under which models of high quality of created, as well as how the potential of implementing models can materialize in the context of continuous change.

In this paper we have identified critical quality aspects for EM to support continuous improvement process in an organization:

• Down-stream quality -to ensure that the EM project gets the best possible conditions. This includes: o Modeling quality -to ensure that modeling is carried out in the best possible way, and o Model quality -to ensure that the resulting models are fit for purpose • Up-stream quality -to ensure that the EM results effectively contribute to the continuous improvement process in an organization.

The paper provides a first starting point to looking at EM practice from an overall organizational level, particularly addressing continuous organizational improvements, and placing the EM project in that context. In this way, EM is addressed at three levels: 1) the control level, 2) the EM project level and 3) the modeling level.

This way of looking at the use and practice of EM could provide a framework for future research targeting more specific issues such as situational factors, goals of a modeling effort, goals for the desired model, process to be followed (a-priori method), actual process followed, conscious changes made to the a-priory process, tool usage, competency management, actual model quality, actual outcomes, actual use of the resulting models, etc.

The main limitation of this experience paper is that relies heavily for orientation and assumptions on the previous practice and research of its authors. We aim to extend the paper into a full research paper. This is why ongoing work involves comparing the experiences reported in the paper with relevant state of research papers.

Fig. 1 .

 1 Fig. 1. EM in the context of continuous improvement

Fig. 2 .

 2 Fig. 2. Down-stream and up-stream quality in the context of continuous improvement

Table 1 .

 1 Activities in EM[START_REF] Stirna | Purpose Driven Competency Planning for Enterprise Modeling Projects[END_REF]

	Define scope and objectives of the modeling project
	Plan for project activities and resources
	Plan for modeling session
	Gather and analyze background information
	Interview modeling participants
	Prepare modeling session
	Conduct modeling session
	Write meeting minutes
	Analyze and refine models
	Present the results to stakeholders

http://www.astrakan.se/Om-Astrakan/Astrakanmetoden/ (in Swedish)

Examples of links to works on this topic are: http://www.uppsatser.se/om/scania+st%C3%A4ndiga+f%C3%B6rb%C3%A4ttringar/ (mainly in Swedish) http://www.tandfonline.com/doi/abs/10.1080/00207540802538039 http://hig.diva-portal.org/smash/record.jsf?pid=diva2:126410 (In Swedish) http://www.emeraldinsight.com/journals.htm?articleid=840538&show=abstract


Naveen Prakash

Hanu Bhardwaj
email: bhardwajhanu@gmail.com

Early Information Requirements Engineering for Target Driven Data Warehouse Development

Keywords: aspects, business indicators, target, choice set, early information

We propose two stages for data warehouse requirements engineering (i) an 'early information' part where the information relevant to decision making is discovered, and (ii) a 'late' part where this information is structured as facts and dimensions. Our focus is on the former. Early information data warehouse requirements engineering starts with targets defined as pairs of the form <A, I> where A is an aspect of an organization and I is a set of business indicators. An aspect is a work area, work unit, service or quality to be preserved in an organization. Business indicators are measures/metrics for specifying the desired performance level of aspects. Targets are organized in a target hierarchy. This hierarchy is a complete specification of what is to be achieved by a top level target. We associate targets with choice sets so that alternative ways of target achievement can be represented. These alternatives form their own hierarchy. Finally, information relevant to selection of each alternative is discovered through Ends, Means, Key Success Factor, and Outcome Feedback analysis techniques. These techniques determine early information that is to be subsequently to be processed in the 'late information' requirements engineering stage. Our early information requirements engineering phase is illustrated through a case study.

Introduction

Starting from its early years when requirements engineering of data ware house systems was about the last thing to be handled [START_REF] Inmon | Building the Data Warehouse[END_REF], requirements engineering for data warehousing has acquired increasing significance. Three life cycles for DW development were presented in [START_REF] Prakash | An Approach to Engineering the Requirements of Data Warehouses[END_REF], namely, database schema driven, ER diagram driven, and Goal driven respectively. Goal oriented approaches [Boe99, Boe00, Bon01, Gol99, Pra04, Pra08] consider organizational and stakeholder goals to define DW structure. Horkoff and Yu [START_REF] Horkoff | Comparison and Evaluation of Goal-oriented Satisfaction Analysis Techniques[END_REF] observe that "goal modeling is not yet widely used in practice" but has been successfully applied in case studies. The inhibiting factors in adoption of goal oriented techniques were identified in [START_REF] Rolland | Reasoning with Goals to Engineer Requirements[END_REF] as (a) Domain experts find the notion of a goal to be fuzzy which makes it difficult to deal with it, and (b) Goal reduction is not a straight forward process. Evidently, these issues get carried over to data warehouse requirements engineering as well.

Recall that the data warehouse requirements engineering problem is to define the information contents of a data warehouse to support the decision making task at hand.

We propose to partition this task into (i) an 'early information' part where the information relevant to decision making is discovered, and (ii) a 'late' part where the discovered information is structured as facts and dimensions. Our focus is on the former.

Early information requirements engineering starts off by determining targets that organizations want to achieve. A target is defined as a pair, <A, I> where A is an organizational aspect and I is a set of business indicators. An aspect represents a work area, work unit, service or quality in an organization. Business indicators are measures/metrics of aspect performance and can be discovered in organizations using techniques like Balance Scorecard. As an example of a target consider sales. Sales is an aspect of an organization. It is a service. An appropriate business indicator might be 'Number of units sold should increase by 5%'. The notions of aspects and business indicators provides a relatively clear basis for defining targets as compared to goals in goal orientation.

Target reduction can be done by following the aspect driven or indicator driven approach. In the former, sub aspects of a top level target are determined and their business indicators are found to form sub targets. In the latter, sub business indicators that go into computing the top level business indicators are determined, their aspects found and sub targets formulated. Thus, we have a relatively clear basis for guiding target reduction as compared to goal reduction. Now we can consider the second step of our 'early information' requirements engineering stage. Whereas target hierarchies identify what the organization wants to achieve, decision making is to be done to indeed achieve targets. To reflect this, we associate choice sets with targets. We define a choice set as a pair <CSO, O> where CSO is the choice set objective and O is the set of alternatives for meeting the CSO. Analogous to target reduction, we have choice set reduction. Each sub choice set is associated with the target that it affects.

At this moment, the full decisional capability required for target achievement is known. Now, in the last stage of early information requirements engineering, we discover the information required to make the most suitable selections from choice sets. By 'early' we mean that information is determined in an abstract, relatively fuzzy form devoid of any structure. Yet, all requirements, for example, of history and aggregation shall be identified here. In this paper, we have relied on the tool reported in [START_REF] Prakash | Towards Better Fitting Data Warehouse Systems[END_REF] for obtaining this early information. Our approach for the 'late information' stage can be found in [START_REF] Prakash | An Approach to Engineering the Requirements of Data Warehouses[END_REF].

Let us compare the early information with the notion of early requirements. Early requirements engineering [Yu 97] is concerned with modeling and analyzing the operational environment in which the software system shall eventually function. It involves an examination of the objectives, business processes, and interdependencies of different stakeholders. Our early information is arrived at by considering the decisional environment that the data warehouse shall support. However, it is nor 'early requirements' because inter dependencies between stakeholders are not investigated. We place 'early information' as the first stage of 'late requirements' engineering for data warehouses where a first cut identification of information is obtained.

The approach of this paper has been applied to a case study of a Dairy Development Board. The paper uses examples from this to illustrate the various concepts. A part of this case study is then presented.

The layout of the paper is as follows. In the next section we consider our notion of targets. It explains the two dimensions of a target and shows how choice sets can be constructed. Section 3 presents the movement from alternatives expressed in choice sets to the required information. Section 4 contains the case study to illustrate the applicability of our proposals. Section 5 places our proposals in existing literature and section 6 is the concluding section.

Targets and their Dimensions

We define a target as a pair <A, I> where A is an aspect of an organization and I is the set of indicators for A. An aspect is a work area, a work unit, a service, or a quality to be preserved. Consider an animal husbandry department. Examples of aspects in this department are as follows:

1. Genetics and Breeding are two work areas in the animal husbandry department. 2. Breed Conversion and Reproduction are two work units. 3. Veterinary Facility and Extension Programme are services provided by the department. 4. Distributed Services Across Regions is a quality to be reserved by the department.

A business indicator is a metric whose value identifies 'what is to be achieved'. This value may be absolute (27) or it may be relative (current +5%). A business indicator may be simple or composite. A composite business indicator is one whose value is obtained from its component business indicators. The notion of a business indicator is similar to that of a key performance indicator KPI. It is explained in [Bar10] that a KPI is a metric associated with goals. Thus percentage increase in sales is a KPI for the goal Increase market share. A business indicator, I, on the other hand, is associated with an aspect A to form a target. There is thus a conceptual difference between a business indicator and a KPI, the former is a constituent of a target whereas a KPI is external to a goal. Further, a business indicator is not associated with a goal but with an aspect which is not a goal but a work area, unit etc. as pointed out above.

In forming a target, we create an association between aspects and business indicators. A target is thus able to specify 'what is to be achieved' by the aspect. Notice that a target may have an aspect that is associated with more than one business indicator. For example, the aspect Breed conversion may have two business indicators, (current insemination + 10%) and (hybrid animals + 5%).

The notion of a target is depicted in Fig. 1. The pair <A, I> is shown by the two conjoined boxes. The arrow from A to I shows the indicators for A. The self loop on I shown by the solid arrow shows the relationship between a composite indicator and its component indicators. The arrow from I to A shows that aspects can be associated with indicators. Thus there is a bi-directional relationship between aspects and indicators.

The bidirectional A-I relationship allows us to form a target hierarchy. Let us be given a top level target. There are two approaches to target reduction.

1. Aspect driven reduction. Here, sub aspects of the top level aspect are determined. For example, if the top level aspect is a work area, then the work units comprising the work area are determined. Similarly, for a work unit, the services offered and the qualities to be preserved form its sub units.

Appropriate business indicators are associated with the sub aspects to form sub targets. 2. Indicator driven reduction. If the top level business indicator is composite, then the components that go into computing its values are determined. The aspects responsible for these are associated with the sub indicators and values to be achieved are identified through brain storming sessions. Thus, we formulate sub targets of top level targets.

The notion of a target identifies what is to be achieved by different aspects of an organization. It is a prescription and provides purpose for the decision making to be carried out in the organization. Decision making requires a choice set for selection of an alternative that is most helpful in achieving the target. Thus, we need to associate choice sets with targets, and formulate alternatives. This is modeled in Fig. 1 As for target hierarchies, it is possible to build hierarchies of choice sets. Again there can be two approaches, CSO driven and options driven that work in a manner analogous to the aspect and indicator driven approaches considered above.

We view Fig. 1 as giving us a two dimensional framework for targets. The first dimension is called the relevance dimension and corresponds to the left part of the figure. In this dimension a hierarchy is set up using the self loop whose nodes are targets and edges specify a 'relevance' relationship between nodes. The second dimension is called the fulfillment dimension and corresponds to the right hand side of the figure. It models the different ways in which an indicator can be affected and comprises of the hierarchy corresponding to the self loop on O.

The Relevance Dimension

The starting point of the determination of the information to be kept in a data warehouse is found in the relevance dimension. Targets are organized in a 'relevance' hierarchy, defined as follows:

Relevant(t,T) iff di t is a factor in estimating di T . Here, di T refers to a desired indicator of T and di t refers to a desired indicator of t. We say that t is a sub target of T. If there is no t such that Relevant(t,T) then T is an atomic target and is at the leaf of the relevance hierarchy.

Consider the meaning of estimation. Estimation can range from completely well defined estimation to purely judgmental. We illustrate this by considering a target T and its relevant target t. Consider Di T as expressed in the set of indicators { A 1 , A 2 , ….. A n } and Di t in {b 1 , b 2 , …. , b m }. Then estimation can take on any of the forms as follows:

1. Identity estimation: in this case A i = b j .

The Fulfillment Dimension

Whereas the relevance dimension is concerned with targets and their relevance to one another, the fulfillment dimension deals with the alternative ways for causing the change in indicator value.

Choice Set

We view a choice set as an abstraction, a class of elements that have the same purpose, that is, a choice set must be coherent. An element is a member of a choice set if and only if it meets the coherence property.

Coherence says that all elements of a choice set must achieve the same purpose. As pointed out earlier, this purpose is captures in the notion of a choice set objective, CSO. For example, consider the choice set, CSET = {Improve cattle health, Ensure cattle nutrition, Improve animal husbandry} having the CSO, 'Improve milk production'. All elements of this set have the same objective to 'Improve milk production'. CSET is coherent. As an example of an incoherent choice set consider CSET 1 = {Improve cattle health, Ensure cattle nutrition, Ensure budgetary compliance}. The element, 'Ensure budgetary compliance' does not contribute to the stated CSO. Therefore, CSET 1 is not coherent.

For a coherent choice set, we may have members that are CSOs and/or functions. We illustrate this by considering the choice set, 'Improve milk production', in its different forms as follows:

i.

The set {Improve cattle health, Ensure cattle nutrition, Improve animal husbandry} has all its elements that specify choice set objectives. ii.

Consider the choice set for 'Improve cattle health', {Perform de-worming, Perform brucella vaccination, Perform mastitis vaccination}. All options of this choice set are functions to be carried out. iii.

For the CSO 'Ensure cattle nutrition', let us be given the choice set {Launch nutrition education programme, Maintain quality feed stock, Improve raw material procurement}. Here 'Launch nutrition education programme' is a CSO whereas 'Maintain quality feed stock' is a function. Thus, it is possible to build a choice set hierarchy for every CSO. This is done by determining if a CSO/function provides an alternative way of meeting another CSO. We capture this in the 'achieves' relationship defined as follows:

Achieves(CSO i ,CSO) iff CSO i is an alternative way of meeting CSO, OR Achieves(F i ,CSO) iff F i is a function and is an alternative way of meeting CSO.

Fulfillment

The fulfillment dimension associates appropriate choice sets with targets of the relevance hierarchy. As mentioned earlier, a target may have more than one indicator, for example, Di Control Population = {number, birth rate, death rate, female_male_ratio}. Each indicator has its own choice set.

We define appropriateness as the alignment of the choice set to its indicator. That is, a choice set is appropriate to a target if it identifies ways to change an indicator of the target. For example, the coherent choice set CSET of section 2.2.1 above is appropriate to the indicator 'cattle milk production cmp, cmp + 4%' of the target 'Milk Production'.

We can now define the fulfillment criterion as follows:

Fulfils(CSO, I m ) iff CSO is appropriate to I m, where I m refers to a indicator of T. Fulfils says that the elements of CS individually or jointly cause the indicator of T to be reached.

Determining Early Information

As mentioned earlier, we determine 'early' information to be kept in the warehouse. This early information is unstructured and at an abstract level. First, notice that indicators directly identify the needed information, for example, birth rate, death rate, and can be obtained from the relevance hierarchy. The interesting question is to determine information for selecting an alternative. We refer to this as pertinent information.

In [START_REF] Prakash | Towards Better Fitting Data Warehouse Systems[END_REF] we handled the issue of pertinent information through a tool called Raju that elicits this information. The tool uses four elicitation techniques called ends analysis, means analysis, key success factors, and outcome feedback analysis. For each element of a choice set, the requirements engineer applies these four techniques to elicit what that paper calls parameters. These parameters are then analyzed to determine which of these parameters themselves lead to choice sets and which identify information. This is done on the basis of heuristics. Pertinent information is obtained as 1. History to be maintained: for example, information of registered members must be available for the last 5 years. 2. Category-wise information: for example, month-wise, age wise, designationwise etc. 3. A report or document. 4. A computation obtained by applying a function like Count of, Average etc. 5. Comparison information: for example, comparison of our performance against others. Pertinent information is elicited for all members of all choice sets.

Case Study

The case study considered in our paper is of a Dairy Development Board, DDB. In the current analytic environment at DDB, there is lack of access to consistent and integrated decision making data. The current reporting system and decision support environment is not addressing the needs of decision makers across the DDB, which causes deficiencies in data ownership and data access policies. Thus requirement of DDB is to anticipate the future and to identify data for decision making, so that it prepares itself for the emerging competitive environment and provides developments in quality of milk and genetics of animals. The information required by DDB is for strategic purposes such as trend identification, forecasting, competitive analysis and targeted market research, so as to ensure a better future for farmers and milk producers.

The activities of DDB are linked to Dairy Cooperative Societies DCS at village level, Milk Producer Union at district level, Milk Marketing federations at state level, Cattle feed plants, and research institutions, and can be broadly divided into three aspects, namely, financial, technical, and legal.

Here we apply our target oriented approach to DDB. We develop the relevance and fulfillment dimensions, choice sets and pertinent information. For reasons of space, we shall illustrate our ideas with a part of the total case.

The top level targets are shown in Table 1. indicators and aspects of the targets were determined by the Board through a process of discussion and brainstorming.

In the relevance dimension of Technical support shown in the table, the indicators of sub aspect, 'Milk production', can be quantified: new cattle milk production must be current cattle milk production, cmp, plus 4%. Similarly, cattle in milk must rise by 60% i.e. cam must become cam+60%.

Further, the sub-aspect 'Milk procurement and distribution' has the indicator quantified as <[dcs satisfaction percent dcssp, dcssp + 10%]> Now consider aspect 'Animal reproduction'; its sub targets are shown in Fig. 3. The indicators of its sub aspects are 'increasing the semen stations', st, to 11 from the current st; 'raising artificial insemination centres', aic, from 20,000 to 38,000; 'raising field artificial insemination', fai, from 4.20 min to 10.30 min, and 'increasing semen production', sp, from 6.20 min to 13.20 min. There are no sub targets of any of the leaf targets of Fig. 3. It can be seen that Fig. 1 to 3 can be put together to form a three level relevance hierarchy. Now, consider the fulfillment dimension for the target 'Milk production, <[cattle milk production cmp, cmp + 4%],[cattle in milk cam, cam + 60% ]>'' (Table 1). There are two indicators associated with it, and we get two CSOs in the fulfillment dimension. The resulting fulfillment dimension is shown in Fig. 4. As the last step in the requirements engineering process we need to discover early information for each alternative of each choice set. The result is a high level, unstructured view of data warehouse contents. We present in Table 2 the pertinent information for each of the CSO corresponding to the Fig 6. Total number and number of functional centres. Comparison of centre type to be taken monthly, quarterly and yearly as also by milk union, state and region-wise. Total coverage, comparative average.

Increase field artificial insemination

Top 20 unions performing insemination. Top 20 cluster centres. Average number of inseminations carried out by centre type, All these are monthly, quarterly, and yearly as well as by milk union, state and region wise.

Increase semen production

Semen production state and station wise. Female calves born out of insemination. Breedable cattle and buffalo population, cross breaded cattle and buffalo, milk union, village and district wise. Number of fresh insemination, coverage, percentage of total and number of inseminations annually for the last 3 years

The Process

In this section we trace the requirements engineering process and exemplify it with the process followed in the case study. The various steps comprising the process are as follows:

1. Determine top level aspects. For the Dairy Board, this was accomplished by identifying the main work areas and services to be provided. 1 is decomposed and the sub indicators obtained were recovery and disbursement. This is the indicator driven reduction approach. In contrast the target for animal reproduction of Fig. 3 was decomposed using the aspect driven reduction approach. The sub aspects of animal reproduction were found and then sub targets were set up. 5. Identify Choice Set Objective could occur at varying times. It could happen that as soon as a target/subtarget was identified, the choice set objective was identified due to the association between them. At other times, some alternatives of the choice set were first identified and then the CSO was laid down. 6. Build Achieves Hierarchy. This was rather more structured in the case study.

Here, it was possible to focus on the decomposition task and identify the components of a choice set. 7. Identify Information. This part was completely guided by the tool reported in [START_REF] Prakash | Towards Better Fitting Data Warehouse Systems[END_REF].

Our observations from the process are as follows. The first is that discovery of top level aspects can be related to the functional areas and units of the DDB. Further, identification of services provided and main tasks performed could be done through brainstorming sessions. Internal management reports can be a good source for determining aspects.

Once the top level aspects were discovered, the analysis of indicators took on a major role. Indicators are found in planning meetings where targets for different functional units are laid down. Often this is on an annual basis though in India it can be done in a five-year plan perspective as well. The targets presented in this paper were obtained in a five-year plan perspective.

Our proposals here are directly related to determining the information that shall be stored in the data warehouse. The outcome of our engineering step is not the multi dimensional schema but early information that is unstructured. It identifies at a top level the information that is needed and that is to be structured in subsequent stages. This is one major point of difference between our proposals and [Boe99, Boe00, Bon01, Gol99].

The problem of obtaining business intelligence from indicators has been considered in [START_REF] Barone | Composite Indicators for Business Intelligence, ER[END_REF]. Here, a technique has been developed for computing composite indicator values from sub indicator values when faced with ill-defined mathematical functions for computing them. In contrast, we use business indicators for specifying what is to be achieved and how this achievement is to be done. The latter yields alternatives for which we discover relevant information to be put in the data warehouse. Thus it can be seen that the proposal of [START_REF] Barone | Composite Indicators for Business Intelligence, ER[END_REF] is for modeling/providing support to obtaining business intelligence whereas our interest is to use indicators for discovering data warehouse information contents.

Indicators have been used in requirements engineering [START_REF] Van Lamsweerde | Reasoning About Alternative Requirements Options[END_REF] for evaluating the contribution made by alternative sub-goals to the main goal. The idea behind this is to determine a qualitative degree of satisfaction of the top-level soft goals so as to select the option with the best degree. These indicators therefore define the choice of system functionality that is to be included in the system To-Be. In contrast, our use of indicators is for determining what targets an organization must set for its different work aspects. These indicators form the basis of determining choice sets which in turn help us to identify early information. There is no evaluation of any alternative. The purpose is to lay down a basis for discovering the decision making capacity to be supported and thereafter to reach the information to be maintained in the data warehouse.

We also looked at the area of decision making. However, we found that whereas our focus is on discovering information to be kept in the data warehouse, interest in decision making was on techniques to make the right selection from a choice set. Wang, Liu and Ruhe [START_REF] Wang | Formal Description Of The Cognitive Process Of Decision Making[END_REF] propose a cognitive process of decision making. The basis of their proposal is the trilogy of concepts, decision goal, a set of alternative choices, and a set of selection criteria or strategies. Al-Shawa and Basir [START_REF] Al-Shawa | Constrained Rationality: Formal Targets-Reasoning Approach to Strategic Decision & Conflict Analysis[END_REF] talk about the special treatment needed for handling strategic goals as compared to tactical and operational goals. They focus attention on a reasoning framework about goals and plans to achieve strategic goals. Felix [START_REF] Felix | Efficient Decision Making with Interactions Between Targets[END_REF] considers the problem of decision making in the presence of interacting goals. The proposal is to calculate interaction between goals using fuzzy types of interaction. Niu and Zhang [START_REF] Niu | A Model of Cognition-Driven Decision Process for Business Intelligence[END_REF] propose a recognition primed decision model, RPD. The basic assumption of RPD is that when confronted with a decision situation, the decision maker will conduct an information processing process, which the authors call retrieval for decision. One kind of retrieval proposed by the authors is information defined as "what an individual needs to know for problem solving". The other is situation awareness. Niu and Zhang elaborate on the situation awareness aspect. As mentioned above, none of this work aims to define the information contents of a data warehouse.

Conclusion

Our proposal for early information requirements engineering starts off with targets, aspects and indicators. Indicators are the 'sticking glue' between the relevance and fulfillment dimensions, (i) they identify 'what is to be achieved' in the relevance hierarchy and (ii) can be used as a basis for defining 'how it is to be achieved' in the fulfillment dimension.

Once choice sets have been discovered in the fulfillment dimension, the issue is of determining the relevant information for alternative selection. This information is discovered through Ends, Means, Outcome Feedback, and Key Success Factor analysis techniques. The discovered information is 'early', abstract, fuzzy, and unstructured. It is to be converted to facts and dimensions in subsequent stages using the techniques spelled out in [START_REF] Prakash | An Approach to Engineering the Requirements of Data Warehouses[END_REF].

The notion of target is relatively less fuzzy than that of goals in traditional goal orientation. This is because aspects and indicators are somewhat more concretely defined. This mitigates the first of the two problems of goal orientation pointed out by [START_REF] Rolland | Reasoning with Goals to Engineer Requirements[END_REF]. Regarding target reduction, we have identified two mechanisms that can be followed. Thus, some guidance can be provided in the target reduction task. Again, this is to be contrasted with the difficulty of goal reduction in goal orientation.

Future work shall focus on elicitation techniques, elicitation of sub indicators and associated goals, choice set objectives and alternative ways of CSO achievement.

  Fig.1. A Conceptual Overview

Fig. 2 .

 2 Fig.2. The Relevant sub aspects of target about 'milk production'

Fig. 3 .

 3 Fig.3. The Relevant sub targets of target 'Animal reproduction, <[conception rate cr,cr+4%], <animal yield ay,ay+2%], [infant calf deaths icd, icd-5%]>

Fig. 4 .

 4 Fig. 4. The Fulfillment Dimension for target 'Milk Production, <[cattle milk production cmp, cmp + 4%],[cattle in milk cam, cam + 60% ]>' Finally, consider the target for Animal reproduction of Fig. 3. For its three indicators, we get three CSOs as shown in Fig. 5.

Fig. 5 .

 5 Fig. 5. The Fulfillment Dimension for target 'Animal reproduction, <[conception rate cr,cr+4%], <animal yield ay,ay+2%], [infant calf deaths icd, icd-5%]>' Each of the leaf nodes of Fig. 3 has one indicator associated with it; therefore each gives rise to one CSO, as shown in Fig. 6.

Fig. 6 .

 6 Fig.6. CSOs of the four leaf nodes

  The proposals of[START_REF] Barone | Composite Indicators for Business Intelligence, ER[END_REF] are of interest here. 4. Judgmental estimation: This is the case where estimation is completely adhoc and undefined. It is a pure judgment on the part of the decision maker. A rich ground for judgmental estimation is ncc targets.

For example let Di Control Population be defined as {number, birth rate, death rate, female_male_ratio}. Let Di Birth Rate Control = {birth rate, calf mortality rate}. Here, 'Birth rate' of 'Control Population' is equal to 'Birth rate' of 'Birth Rate Control'. 2. Derived estimation: Ai = F(bj). Again taking 'Birth rate' as example, it is possible that interest in 'Control Population' is in the Net birth rate taken as the difference between 'Birth rate' and 'Calf mortality rate' of 'Birth Rate Control', i.e., Birth rate Control Population = Birth Rate Birth Rate Control -Calf Mortality Rate Birth rate Control . Functions like max, min etc. may also be applied. 3. Ill-structured estimation: In this case, one may use techniques like trend analysis, forecasting, extrapolation etc. to estimate Ai from bj. Perhaps, there is a trend captured in the factor, 'Population elasticity' that helps us to estimate 'New population' based on 'New birth rate' and 'Old population'. Then using this, estimation of 'Control Population' can be made.

Table 1 .

 1 The three targets of Dairy Development Board Now consider the target about 'Milk production'. Its relevant sub target hierarchy is shown in Fig.2. An explanation of the sub aspects is provided in the table below:

	Sr. No.	Target	Sub Target
		Aspect	Indicator	Aspect	Indicator
					<[current
	1	Finance support	Budget Compliance	Fund Management	recovery cr, cr+10%], [current disbursement cd, cd +3%]>
				Loan	<current backlog
				Management	cb, cb -20%>
					<[cattle milk
	2	Technical support	Efficiency	Milk Production	production cmp, cmp + 4%],[cattle in milk cam, cam + 60% ]>
				Milk	<[dcs satisfaction
			Effectiveness	Procurement&	percent dcssp,
				Distribution	dcssp + 10%]>
	3	Legal matters	DCS coverage	Legal framework developed Adequately	<current DCS cdcs, cdcs+3> <[dcs to legal
				staffed legal	officer ration dlo,
				cell	dlo= 20:1]>

Table 2 :

 2 Early Information

	Choice Set Objective	Pertinent Information
	Increase semen stations'	Bull population under station area. Average collection
	inspections		monthly, quarterly annually. Collection wise ranking of
			stations. inventory
	Increase	artificial
	insemination centres

  2. Determine business indicators. For each top level aspect, the Board laid down the main indicators. For our top level aspects, the indicators were qualitative. The determination of effectiveness, for example, (see Technical Support in Table 1) would be done by questionnaires and feedback sessions. Provision in the data warehouse for this would be necessary, if it is decided to keep detailed information. 3. Formulate top level targets. This is done by associating aspects and their indicators. Thus, our top level target is <Finance support, Budget compliance>. 4. Decompose Targets. The relevance hierarchy is built by decomposing indicators/aspects. The indicator 'Budget compliance' of Table


Eric Lao
email: eric.lao@lip6.fr

Marie-Minerve Louërat
email: marie-minerve.louerat@lip6.fr

Jean-Paul Chaput

Semi-Automated Analog Placement

Analog design remains a manual task because of the complexity of the interactions among devices. Automation tools dedicated to analog circuits are not as mature as the digital automation ones, but have been improved a lot at a point that they can help at individual steps in the analog design flow. Our approach is to propose a semi-automated analog placement controlled by the designer, following an organization in row similar to a digital circuit structure. The results show the ability of our tool at generating multiple layouts respecting designer's constraints.

I. BACKGROUND OF THE PROBLEM

Today system-on-chip contains both digital and analog circuits. Even though most functions in an integrated circuit are implemented with digital circuitry, some functions rely on analog circuit and are the link with the external world. Despite the fact that the digital design flow has been well-defined over the last years, the analog design flow lacks a common methodology making it difficult to capture a design procedure.

An automatic placement tool should produce analog device-level layouts similar in density and performance to the high-quality manual layouts. To achieve this task, the capability to deal with layout constraints, in order to decrease unwanted parasitics due to the fabrication process, is mandatory. [START_REF] -H. Lin | Recent Research and Development and New and Challenges and in Analog and Layout Synthesis[END_REF] enumerates the most common placement constraints that are respected by modern analog placer where symmetries [START_REF] Lin | Analog Placement Based on Symmetry-Island Formulation[END_REF] are the most used constraints.

Although most of the recent works focus on highly automated approaches such as the simulated annealing algorithm [START_REF] Kirkpatrick | Optimization by Simulated Annealing[END_REF], we believe that giving more control to designers and using their interventions to set some constraints yield good analog placement results. In this work, we introduce a semi-automatic analog placement approach guided by designers' preferences. This semi-automatic approach also helps designers to debug more efficiently and makes adjustments easier since they will control the overall relative placement of the circuit but at the same time, some tiresome and error-prone tasks are automated.

II. ORIGINAL KEY IDEA OF THE STUDY A. Design Flow

The Cairo Hurricane AMS (CHAMS) project [START_REF]Laboratory LIP6[END_REF], developed by the LIP6 Laboratory, proposes a complete flow to create a library of highly reconfigurable analog circuits, and specially The proposed CHAMS analog design (fig. 1) is a two way communication between the sizing and layout generation. The idea is that the sizing tool provides the electrical parameters of the transistor such as the width, length, number of fingers, etc... to the layout generation tool. The tool automatically generates the layout from a library of parameterized cells and sends back to the sizing engine the layout-dependent parasitic parameters such as the drain and source areas and perimeters, the stress effect parameters, etc... to re-evaluate the performance. This internal loop is repeated several times, with minimal designers intervention, until the target specifications are met. Digital and analog circuits have a dedicated area on a system-on-chip circuit so they can be independently designed within a specific space (fig. 2). Digital circuits are well-known for their regular row structure where standard cells are placed and routed accordingly to their netlist. In a similar way, we plan to organize the analog circuit layout in rows of devices and the analog circuit area should be placed and routed within its dedicated area (fig. 3).

B. Placement in row

It is common to design analog circuit in rows of devices where the height of each row of devices should be adjustable so it can match its dedicated area. Therefore, we choose the slicing tree representation for several reasons:

• Slicing trees are a natural choice to describe a row structure. Rows are represented by horizontal slices which will be divided into vertical slices determined by the area of each device. Since the devices will rarely have the same height, we introduce a margin parameter, which represents the largest difference between the smallest and the tallest devices' heights in the same row. • Unlike most of modern analog placement methods, our placement strategy is semi-automatic and will be guided by designers' preferences. Slicing trees are easy to handle and let designers choose the overall topology. Our tool was implemented in C++ programming language on a Intel(R) Core(TM) i5-4590S CPU @ 3.00 GHz workstation with 6 GB RAM. To illustrate the capability of our tool, we experiment it on a fully differential transconductor [START_REF] Iskander | Hierarchical sizing and biasing of analog firm intellectual properties[END_REF], designed in a 130 nm CMOS technology. The fully differential transconductor consists of a total of 32 devices and we consider 2 possible variations for each device. The slicing tree takes into account 11 symmetries for this circuit and tolerance margins are set in a way to have reasonable amount of accepted possibilities. Designers can choose their final placement based on their experiences and preferences. Our tool presents the placement results (fig. 4) plotted on a graph (fig. 5) with heights and widths as axis and can be selected interactively to be placed in a few seconds.

III. RESEARCH THAT HAS BEEN CARRIED OUT SO FAR

IV. DISCUSSION OF THE CONTRIBUTION Slicing tree structure is a structure that has been studied over the last decades and its drawbacks are well-known. It is in a way restrictive since there are some topologies that cannot be represented with a slicing tree which can be a problem. Moreover, it does not extend to non-rectangular structures and has a bad white space distribution. Nevertheless, we are quite satisfied with the slicing tree structure which is able to handle the organization in row.

For future considerations, even though the white space distribution can be a disadvantage, we plan to exploit it during the routing step that needs to be performed. Our floorplan representation and algorithm have been thought according to the analog routing step that we plan to develop in the future.

Fig. 1 .

 1 Fig. 1. Cairo Hurricane AMS Design Flow

Fig. 2 .Fig. 4 .

 24 Fig. 2. Mixed-signal circuit floorplanning Fig. 3. Analog placement in three rows

Fig. 5 .

 5 Fig. 5. Circuit's dimensions, showing heights as function of widths