Goal-based reasoning in the construction of taxonomies for COTS components

GESSI Grup d´Enginyeria del Software per als Sistemas d´Informació Claudia Patricia Ayala Martínez Goal-Based Reasoning in the Construction of Taxonomies for COTS Components 1 11 1 G U I D E D R E S E A R C H P R O J E C T Director: Dr. Pere Botella, Dr. Xavier Franch  Universidad Politécnica de Cataluña., Junio 2004 2 22 2 3 33 3 Table Of Contents ABSTRACT........................................................................................................................................................... 4 INTRODUCTION................................................................................................................................................. 5 1. A TAXONOMY FOR COTS PRODUCTS............................................................................................... 7 2. GOAL BASED REASONING.................................................................................................................... 8 2.1. C USTOMIZING GBRAM TO OUR APPROACH ............................................................................................. 9 2.2. A PPLICATION OF H EURISTICS ................................................................................................................. 11 3. CASE STUDY. SOFTWARE REQUIREMENTS AREA ..................................................................... 14 3.1. G OAL A NALYSIS A CTIVITIES ................................................................................................................. 14 3.1.2. Identifying Goals and Objectives.................................................................................................... 17 3.1.3. Identifying Stakeholders and Agents............................................................................................... 19 3.1.4. Organization and Matching of Goals ............................................................................................. 20 3.2. G OAL R EFINEMENT A CTIVITIES ............................................................................................................. 31 3.3. S UMMARY .............................................................................................................................................. 37 4. HEURISTICS AND GUIDELINES......................................................................................................... 39 4.1. G OAL -B ASED I NSTANTIATION OF I NQUIRY C YCLE ................................................................................ 39 5. CONCLUSIONS AND FUTURE WORK............................................................................................... 44 APPENDIX 1....................................................................................................................................................... 46 I* DIAGRAMS.................................................................................................................................................... 46 APPENDIX A...................................................................................................................................................... 48 APPLICATION DEVELOPMENT SOFTWARE INFORMATION ............................................................ 48 APPENDIX B ...................................................................................................................................................... 53 TRENDS AND TERMINOLOGY OF THE ACTUAL MARKET ................................................................ 53 APPENDIX C...................................................................................................................................................... 59 ANALYZING EXISTENT TAXONOMIES .................................................................................................... 59 APPENDIX D...................................................................................................................................................... 77 SUMMARY OF SUITABLE GBRAM HEURISTICS.................................................................................... 77 REFERENCES.................................................................................................................................................... 80 4 44 4 Abstract In a previous work, our research group GESSI has proposed the construction of a taxonomy for classifying COTS components by means of characterization attributes to arrange domains which COTS components belong to, and also grouping these domains into categories [4]. In this report we present our first applicability study of GBRAM (Goal Based-Requirements Analysis Method) as a goal-based reasoning method for the construction of taxonomies of COTS components; more concretely for exploring the “characterization attributes” that are used to browse the taxonomy through an example: the context of the Application Development Tools. We illustrate the main aspects of customizing GBRAM to this objective and remark the methodological aspect we want to achieve in our future work: to propose guidelines for the construction of any taxonomy of COTS components. 5 55 5 Introduction The use of commercial off-the-shelf software components (COTS) is becoming an economic and strategic necessity for many organizations in a wide variety of different application areas, including finance, health-care, logistics, administration, manufacturing, commerce and many others. However, employing COTS in building applications is not a painless business. As the COTS market evolves, COTS users must face new challenges to successfully and effectively acquire, select and integrate commercial software components in applications and systems. The statement of methodologies and the construction of tools to support them can be a key point to enhance: a) The efficiency of the software process, through the reduction of production and maintenance costs. b) The accuracy and reliability of the decisions relative to the acquirement, integration and use of applications in the most critical points of the target companies from a strategical perspective. Therefore, there is an increasing need for arranging the types of available COTS products to improve the efficiency and reliability of selection processes. The need of having these taxonomies is evident; we can see that it arises in very different contexts, from huge consultant companies like Gartner [1], to organizations such as INCOSE [2], or websites as www.componentsource.com or eCots from Thales company [3]. In this context, we have detected that there are not studies deep enough about the identification of properties that can help to organize the taxonomies. As a result, our research group (GESSI -Grup d´Engineria del Software per als Sistemas d´Informació- 1 at UPC) has been working in many aspects addressed to build a taxonomy for classifying COTS by means of characterization attributes; this work is described and applied in [4]. The existence of such taxonomy provides a framework for the whole selection process and is a basis for structuring a knowledge base on the field (these aspects are presented in next sections). Nevertheless, more important than the concrete form that a taxonomy takes, is the rationale behind its construction, i.e. which are properties that may help to arrange it and how the taxonomy can be searched (this is especially true when considering not just the construction of the taxonomy, but its evolution). In this sense, the remaining sections show the context and our first approach in a method for enhancing the mechanism to build the taxonomy by means of goal-based 1 Software Engineering for Information Systems Group. 6 66 6 reasoning. Last, we close the report with a discussion and explanation of our overall idea and outline the need of future research to achieve our objective. 7 77 7 1. A Taxonomy For COTS Products he proposal of building taxonomies made by GESSI in [4] is an example of the specific support for improving the Business Applications (BA) selection processes. It is considered that BA belong to one or more BA domains, which appear as leafs in the taxonomy. A domain encloses a significant group of functionality. Domains are grouped into categories, and also categories can be grouped themselves to form a multi-level taxonomy. Dependencies among domains that belong to the taxonomy are included in the hierarchy itself and are represented using i* SD notation [6]. The taxonomy can be incorporated to COTS selection practices, which are based on the use of quality models to assess the adequacy of components with respect to requirements [7,8]. Those quality models are attached to nodes in the taxonomy, supporting model reuse by inheriting quality models downwards the BA hierarchy [9] (see Figure 1.1). Category C1 Quality Model QMD1 Quality Model QMD2 Quality Model QMC1 A1=v1.1 A1=v1.2 Category C2 Attribute A0 A0=v0.1 A0=v0.2 Att ribute A2 A2=v2.1 A2=v2.2 Quality Model QMD3 Quality Model QMC2 Quality Model QMC0 Dependency D12 Category C0 Attribute A1 Domain D1 Domain D2 Domain D3 Figure 1.1 The fundamental elements of a taxonomy T 8 88 8 2. Goal Based Reasoning equirements Engineering (RE) research has increasingly recognized the leading role played by goals in the RE process [10]. Such recognition has led to a whole stream of research on goal modeling, goal specification, and goal-based reasoning for multiple purposes, such as requirements elaboration, verification or conflict management, and under multiple forms, from informal qualitative to formal. Goal-based reasoning reviews how goals are used in basic activities such as requirements elicitation, elaboration, verification, validation, explanation, and negotiation; particularly for difficult aspects such as conflict management, requirements deidealization, and alternative selection [10]. We are exploring the applicability of GBRAM [5], as a goal-based reasoning method, in a different context from those cited above, that is the construction of taxonomies from goals (specifically in the Application Development domain –in this report-). In this sense, we are working for defining a guide of goal-based reasoning, which will help us to generalize, formalize, enhance and clarify the process for building taxonomies; more concretely to help in the process of identify and evaluate the most suitable characterization attributes, including the question-answer pairs for the construction of the optimal taxonomy in any specific area. In particular, we emphasize the concept of characterization attribute as a rationale for building this taxonomy in any category of COTS, together with question-answers and examples assets [4], making their use easier and dynamic. With the primary focus on the transformation of enterprise and system goals into requirements, GBRAM was formulated by Annie I. Antón [11], more specifically to assist analysts in gathering software and enterprise goals from many sources and to support the process of discovering, identifying, classifying, refining and elaborating goals into operational requirements. The method’s chief contribution is the provision of heuristics and procedural guidance for identifying and constructing goals. The high level activities of GBRAM briefly explained are: • Goal Analysis that concerns the exploration of available information sources for goal identification followed by the organization and classification of goals. • Goal Refinement that concerns the evolution of goals from the moment they are first identified to the moment they are translated into operational requirements for the system specification. It includes activities as refine, elaborate and operationalize of goals. These high-level activities just described provide an overview of the GBRAM. R 15 1515 15 Table 3.1 Overview of GBRAM Analysis Activities 3.1.1. Exploration of Existing Information Using GBRAM, we must first explore the available information to identify and extract goals from these sources. We noted that the method is not dependent upon any specific representations. Instead, GBRAM recognizes the typical challenge of working with different sources of knowledge that are represented in different forms. It is good practice to gather as much as relevant information as possible to understand the design implications of goals; thus, in GBRAM we explore these information sources to identify and extract goals. An important aspect in this our approach is that most information presented come from standard information (i.e. SWEBOK and IEEE standards), thus the level of confidence of the goals is based on them. As much as possible information was gathered. In the Apendix A and B are related many of this information (but many other are only referenced). Definitions and Domain Information : were gathered from diverse sources as web pages from consultants, organizations, standards or software engineering books. It provide us a base knowledge of the domain. Existent Taxonomies : we take into account proposed taxonomies like: Gartner, INCOSE and IDC. For each of them we compile all information related with terminology and classifying criteria. It provides us diverse point of views for classifying and remarks certain trends of the actual market. Related Standards : we are based many information on SWEBOK, because it represent the most standard information in the field and summarize IEEE 16 1616 16 standards related with the area (e.g. ISO/IEC 12207, IEEE/EIA 12207.1-1997, IEEE Std 830-1998) Other sources : In one hand an significant issue that we want outline is that the information of principal vendors provide us insights of products characteristics and boundaries, . On the other had, the construction of i* models of the domain represent a big picture of the goals concerned to achieve the main objectives so they are helpful in organize the information in order to guide us to understand all as possible the domain and facilitate the Goal Analysis stage. Activity Inputs Outputs Explore Standards related Domain Information Goals Identify Standards related Domain Information Goals Stakeholders Agents I* models Organize Goals Matching of Information Sources Reducing or Extend Goal Set Goal hierarchy Refine Goal Set Scenarios Constraints Operationalize Goals Set Characterization Attributes for Constructing the Taxonomy of the domain Table 3.2 Input and Outputs of adapted GBRAM activities. For approaching the problem of creating a taxonomy for Application Development Domain, we partitioned the topic into the 10 Knowledge Areas referenced in SWEBOK (see Figure 3.1). Guide to the Software Engineering Body of Knowledge (Version 0.95) Software Testing Software Maintenance Software Construction Software Configuration Management Software Design Software Engineering Process Software Requirements Software Engineering Tools and Methods Software Engineering Management Software Quality Figure 3.1 SWEBOK Knowledge Areas 17 1717 17 In this report we take as a Case Study the Software Requirements Area (partitioned into 6 subareas, showed in Figure 3.2) Figure 3.2 SWEBOK Software Requirements Area It is important to stand out that in the nature of the problem we have 3 main information sources that we should to match for creating a set of goals. 3.1.2. Identifying Goals and Objectives We have to report that in SWEBOK were identified the most important goals consensually validated (it has an standard level in the field), so it facilitated all the process due to these goals were supported by an standard. Thus, we worked in finding goals behind this high level goals established. This is, SWEBOK present a hierarchical structure. Software Requirements Area is divided into 6 topics (we will take them as a high level goals): Requirements Engineering Process, Requirements Elicitation, Requirements Analysis, Requirements Specification, Requirements Validation, and Requirements Management. It follows that we have to find through GBRAM adapted activities the goals into this partitions. For example: Requirements Engineering Process (this partition shows how Requirements Engineering is related with the overall software engineering process) has as subgoal Process Support and Management (introduces the project management resources required and consumed by requirements engineering process) and we have to identify goals and objectives behind this. To identify goals, each source of information is analized by asking “What goal(s) does this statement/fragment exemplify?”. In GBRAM is necessary to define and to document very precisely any preconditions or posconditions on the goals. In our adapting of the method as a consequence of the application area (original GBRAM was used to discover system requirements and we are adapting it in order to find characterization attributes) is 18 1818 18 not necessary to be so rigorous in that sense, however obviously it is necessary to document the preconditions and posconditions with the aim of facilitate the process to stablish hierarchies assuring the process of evolution or growing. Example 1: Consider the following NLD (Natural Language Description) from the description of the topic of Process Support and Management [SWEBOK]. “It is important introduces the project management resources required and consumed by the requirements engineering process -issues of cost, human resources, training and tools-” As a general rule, statements which seem to guide design decisions at various levels within the system or organization point to possible goals. By examining the statement and asking “What goals does this fragment exemplify?” some goals become evident from the description:  Getting Project Management Resources Required and Consumed by Requirements Engineering.  Getting costs of human resources, training and tools of the activities of Software Requirements. The level of decomposition of goals is not defined, but it depends on the matching of the three main information sources -described in section 3.1- (i.e. one goal that appear as “standard” should be take into account if exits in the market any tool that supports it, however discovering important goals that are not covered by any tool is a significant issue in closing the gap between tools and process). All action words are possible candidates for goals. Goals may thus also be identified by searching for action words which point to some state that is, or can be achieved once the action is completed. Certain types of verbs such as: allocated, completed, achieved, found out, and satisfied intimate possible goals. To demonstrate the ‘action word identification’ approach, consider the next example: Example 2: Requirements Analysis has as subgoal Architectural Design and Requirements Allocation. From its description we have: “In many cases, the requirements engineer acts as system architect because the process of analyzing and elaborating the requirements demands that the subsystems and components that will be responsible for satisfying the requirements be identified. This is requirements allocation.” So, we decide to show the goal of Requirements Allocation as an independent goal. Although goal identification is presented prior to discussion of stakeholder identification in this section, the activities do not preclude each other. Stakeholders must often be 19 1919 19 identified before any goals can be specified. We must understand who the stakeholders are before we can even begin to develop an understanding of the goals. However, it is evident that in most cases that are on target, we depart from an understanding of who the general stakeholders are for the system prior to goal identification phase. 3.1.3. Identifying Stakeholders and Agents In this stage, we have to determine who are the stakeholders involved in the achievement of goals, once the goals and stakeholders are specified, the goals must be assigned to their responsible agent(s). Identifying stakeholders determines who or what claims an interest in each goal so that an understanding may be gained regarding the different viewpoints. A stakeholder is any representative affected by the achievement or prevention of a particular goal. Multiple stakeholders may be associated with one goal. Agents are responsible for the completion and/or satisfaction of goals within an organization or system. For clarification, the difference between an agent and a stakeholder should be noted. As shown in Figure 3.3, some agents are stakeholders and some stakeholders are agents; that is Agents ∩ Stakeholders. A stakeholder may be a customer 2 , actor 3 , owner 4 , or representatives of organizations. The agents that lie outside of the intersection of Agents and Stakeholders are not stakeholders; instead, they are system-specific agents. Figure 3.3. Venn Diagram Distinguishing Agents and Stakeholders 2 A customer is a perceived beneficiary of the system. 3 An actor is someone who actually performs functions in the system. 4 An owner is a customer in the contractual sense. System Agents Stakeholders 20 2020 20 The stakeholder for each goal are determined by asking “Who or what claims a stake in this goal?” and “Who or what stands to gain or lose by the completion or prevention of this goal?” A logical approach for identifying the agents is to consider which agents are ultimately responsible for the achievement or maintenance of each goal by asking the question, “Who or what agent [is/should be/could be/] responsible for this goal?”. Example: The goal Process Supported and Managed (from Requirements Engineering process defined) has related two goals (G1 and G2); Table 3.3 shows that both the Requirements Engineer (RE) and Project Manager (PM) have an interest or stake in the support and management of the Requirements Engineering Process. However, the RE is the responsible of realize that goal. Here we can note the importance of the stakeholders dependencies that we have to represent through i* diagrams that facilitate the process of discover not only dependencies, but also Stakeholders and Agents. Goals Agent Stakeholders G1: Resources required and consumed by requirements engineering process defined RE RE, PM G2: Cost, human resources, training and tools stablished. RE RE, PM Table 3.3 Stakeholder and Agent Analysis Example 3.1.4. Organization and Matching of Goals Organization of goals entails eliminating redundancies and reconciling synonymous goals. It is useful first organize information related to each source, specify the goal dependencies and reconciling synonymous; then to do the match between them and apply again the goal dependency and reconciling synonymous. As mentioned above, the i* diagrams are useful to organize the information and give us a framework of the domain, activities and stakeholders involved. In Table 3.4 we can see the process of organization and classification of goals applied to the Requirements Engineering information framework, and in Table 3.5 we observe the matching with the existent taxonomies and vendors information. 21 2121 21 It is essential to stand out that in the context of the existence taxonomies related, we have to do previously a simple inspection to the characteristics that were taken into account for their construction, this for knowing what taxonomies are suitable to consider or not. Then analyze all information related with it, to gather and investigate all the concepts that are used. These activities aid us to understand and to match not only the terminology, but also to have criteria of what taxonomies and in what measure should be applied. In GBRAM, all goals are classified as either maintenance goals or achievement goals, but in our adaptation of the method (and the exercises realized until now) is not necessary and we can disregard this activity. 22 2222 22 Description Agents Stakeholders G1 Showing how requirements engineering dovetails with the overall software engineering process Requirements Engineer (RE) RE, Project Manager (PM), Q.A. 1 How the activities of elicitation, analysis, specification, validation and management are configured for different types of projects and constraints 1 1 RE RE, PM 1 2 RE RE, SCM 1 3 RE RE, PM 2Introduces the roles of the people who participate in the requirements engineering process RE 2 1 RE RE 3 Introduces the project management resources required and consumed by requirements engineering process. It make the link from process activities identified in (G1.1) to issues of cost, human resources, training and tools 3 1 RE RE, PM 3 2 RE RE, PM 4 Its purpose is to emphasize the key role requirements engineering plays in terms of cost, timeliness and customer satisfaction of software products. 4 1 RE RE, QA 4 2 RE QA 4 3 RE QA Process of Software Requirements defined Goals Software Requirements Process Description of how Requirements Engineering activity will be done and refined through the life cycle of the software process To define how to identify requirements as configurations items,and manage under the same configuration regime as other products of the development process suitable process to the organization and project context tailored Process Models defined Process Actors defined Users, Customers and Stakeholders (intern and extern) defined Issues of cost, human resources, training and tools linked to activities of process model. Process Support and Management Expected project management resources required and consumed by requirements engineering process defined Process Quality and Improvement Requirements Engineering covered by process improvement standards and models Requirements Engineering measures and benchmarking stablished Planing and Implementation improvemented 23 2323 23 G2 Its is concerned with requirements come from and how they can be collected by requirements engineer. 1It is designed to promote awareness of different requirement sources and frameworks for managing them. RE RE, Stakeholders 2Examples: Interviews, Scenarios, Prototypes, Facilitated Meetings, Observation RE RE, Stakeholders 1 RE RE, Stakeholders 2 RE RE G3 Its concerned with the process of analyzing requirements to: detect and resolve conflicts between requirements, discover the bounds of the system and how it must interact with its environment; and elaborate system requirements to software requirements 1 RE RE 2 Conceptual models comprise models of entities from the problem domain configured to reflect their real-world relationships and dependencies. Examples: data and control flows, state models, event traces, user interactions, objetc models and many others RE RE 3 RE RE 1 In many cases, the requirements engineer acts as system architect because the process of analizyng and elaborating the requirements demands that susbystems and components that will be responsible for satisfying the requirements be identified. RE RE 2The requirements allocation is the assignment of responsability for satisfying requirements to subsystems. RE RE 4 Its is concerned with resolving problems with requirements where conflicts occur; between two stakeholders´requering mutually incompatible features, or between requirements and resources or between capabilities and constraints. However, a strong case can also be made for counting it as part of requirements validation RE RE, Stakeholders Requirements Elicitation Requeriments Sources defined and analyzed Elicitation Techniques choosen and aplyed Requirements Analysis Extracting Requirements Capturing Requirements Requirements Classification Conceptual Modeling realized Architectural Design and Requirements Allocation Requirements Negotiation Architectural Design done Requirements Allocation done 24 2424 24 G4 It is concerned with the structure, quality and verifiability of the requirements document. 1 This document (sometimes known as the user requirements document or concept of operations) records the system requirements. RE RE, users/customers 2 RE RE 3 Several recommended guides and standards exist to help define the structure of requirements documentation. These include IEEE P1233/D3 guide, IEEE Std.1233 guide, IEEE Std. 830-1998, ISO/IEC 12119-1994, IEEE Std. 1362-1998 concept of operations (ConOps) RE RE 4 RE RE, QA G5 The aim is to pick up any problems before resources are commited to addresing the requirements. 1 Perhaps themost common means of validation is by inspection or formal reviews of the requirements documen(s). A group of reviewers is constituted with a brief to look for errors, mistaken assumptions, lack of clarity and deviation from standards practice. RE RE, users/customers 2 it is commonly employed for validating the requirements engineer´s interpretation of the system requirements, as well as for eliciting new requirements. RE RE, users/customers 3The quality of models developed during analysis should be validated RE RE 4 It is an essential property of a system requirements, it should be possible to validate that the finished product satisfies the requirement. RE RE, users/customers, Tester G6 It is an activity than spans the whole software life cycle. It is fundamentally about change management and the maintenance of the requirements in a state that accurately mirrors the software to be, or that has been built 1 It is central to management of requirements 1 RE RE Requirements Specification The System Requirements Definition Document done The Software Requirements Specification (SRS) done Document Structure and Standards used Document Quality Requirements Validation The conduct of Requirements Reviews done Prototyping done The procedures that need to be in place and the analysis that should be applied to propose changes defined Model Validation done Acceptance Tests done Requirements Management Change Management controlled 31 3131 31 Constructing a Goal Hierarchy Goals offer a rich outlining structure for organizing requirements information, addressing the need for documents that are easy to index and read. Since goals provide an organizing structure, GBRAM refers to this outlining mechanism as a goal topography. A goal topography can be represented in a number of ways. We use the outline form, because when a goal topography is manually constructed is tipically constructed in this form. (Tables 3.4 and 3.5 show the outline form of the framework of Requirements Engineering). The advantage of topographies expressed in the form of an outline is that they provide a clear mapping to the goals from different sources. By organizing the goals according to the goal topography, changes in the goals can be managed. This is important because the goal topography enables us to localize the goals which are affected by a change in related or proximated goals. Since dependency relations are tracked, traceability is possible the narrowing of scope facilitates the identification of other goals that are affected as a result of changes in a specific goal. Once the goal topography is constructed, we must systematically elaborate and refine the goal set. 3.2. 3.2.3.2. 3.2. Goal Refinement Activities Goal Refinement ActivitiesGoal Refinement Activities Goal Refinement Activities This section discusses the activities we must perform during goal refinement. In our GBRAM adaptation goal refinement concerns three specific activities which may be summarized as follows: • Refinement of the goal set to prune the size of the goal set; • Elaboration of the goals to uncover hidden goals and requirements; and • Operationalization of the goals into characterization attributes The remainder of this section provides a discussion of each of these activities within the context of the associated activities shown in Figure 2.1. Examples of the method´s applicability, taken from the our case study, are provided throughout the remainder of this section. It should be noted that these activities need not be performed sequentially; rather they may be performed concurrently with occasional interleaving and iteration as evidenced by the arrows in Figure 2.1. Another important aspect that we want to remark is that this phase is too a refinement phase of the i* diagrams as goals. 32 3232 32 3.2.1. Elaboration of Goals In GBRAM goals are elaborated by considering scenarios 1 and goal obstacles 2 . Goal obstacles are identified in order to consider the possible means of goals failure. They are elaborated further by identifying scenarios to develop an understanding of how the goals can be operationalized. Finally, goal constraints 3 are identified to expand our understanding of what obligations must be met for goal completion. 3.2.1.1. Specifying Goal Obstacles The objective of specifying goal obstacles for each goal is to capture any information pertaining to the goals and system objectives that might otherwise be overlooked. Original GBRAM is too meticulous in this sense (because of its original purpose), this step depend on our rationale because we must identify and construct goal obstacles by inquiry from the available information sources. Goal obstacles are identified by analyzing statements that illustrate an example of a goal being blocked by another goal or condition which prevent its completion. Obstacles can also be identified by asking “What other goal or condition does this goal depend on?”, “Can the agent responsible for a goal fail to achieve the goal?”, “If this goal is blocked, what are the consequences?”, “Can the failure of another goal to be completed cause this goal to be blocked?”. Goal obstacles may be identified in parallel to goal identification. Goals Goal Obstacles G1: Requirements Sources Identified 1. Requirements Sources not Identified (G) G2: Requeriments Sources Analized 1. Requirements Sources not Analized (G) 2. Requirements Sources not Identified (P) Table 3.7 Prerequisite Failure Obstacle Example For each goal, the normal first case goal obstacle is specified by simply negating the verb in the goal name (Table 3.7). These are considered general goal failure (G) obstacles 1 Scenarios are behavioral descriptions of a system and its environment arising from restricted situations. 2 Goal obstacles prevent or block the achievement of a given goal. 3 A goal constraint places a condition on the completion of a goal 33 3333 33 because they denote basic goal failure (expressed ¬Gi). Each general failure obstacle must then be analyzed to consider other possible obstacles (using scenarios if it is necessary). When a goal having a precedence relation is obstructed because the precedence goal fails, it is considered a prerequisite failure (P) obstacle. When a goal fails because the responsible agent is irresponsible, it is considered an agent failure (A) obstacle. In this case, the irresponsible party must be tracked down and held accountable. When a goal fails because the goal that it holds a contract relation with fails, it is considered a contract failure (C) obstacle. Goal obstacle analysis facilitate the identification of exception cases guiding the identification of new, additional goals. Once the goal obstacles are specified, we must consider the possible scenarios that are likely for each obstacle. 3.2.1.2. Constructing Scenarios The ways in which goals can fail are identified during goal obstacle analysis. The objective of this activity is to elaborate this information further via scenario analysis. Scenarios 4 offer a natural way to describe special, exceptional circumstances. Scenarios are the most creative artifact of the analysis process and play a major role in discovering goals. Scenarios denote concrete circumstances under which a goal may fail, helping us uncover hidden goals or issues needing further resolution that might otherwise go unnoticed or be overlooked, thereby supporting the process of refining goals. When goal priorities change, scenarios facilitate the evaluation of these new priorities. Scenarios are identified by considering the goals and goal obstacles previously identified to determine the reasons why and the circumstances under which a goal may be completed or can fail. By asking “Why?” and “What happens if this goal isn´t achieved?” scenarios can be identified that address why a goal failed or what the consequences are if the goal should fail. Initially, the normal first case obstacles are considered and possible scenarios are defined for each one. This is done for each obstacle by asking “What are the circumstances under which this obstacle can occur?” “Why did this obstacle occur?” and “Why was this goal not achieved?” Answers to these questions facilitate the identification of scenarios. It is beneficial to have domain experts construct scenarios, given that they are likely to think of more possible ways in which goals can fail than is an analyst who may be unfamiliar with the domain 4 Scenarios are behavioral descriptions of a system and its environment arising from restricted situations. 34 3434 34 Scenario identification and construction provides a systematic way to find abnormal cases. Scenarios also facilitate the consideration of assumptions and issues pertaining to the goals themselves. 3.2.1.3. Identifying Constraints The objective of this step is to identify any constraints that exist for goal completion. Constraints provide information regarding circumstances that must exist or conditions that must be met for a given goal to be completed. Constraints are identified by analyzing each textual description fragment. As a general rule, constraints may be identified by looking for dependency relations and by searching for temporal connectives, such as during, before an after, or variants thereof. In our approach we take into account these activities of elaboration of goals, however is not necessary to be so exhaustive (like original GBRAM); in fact this step depend on our rationale because we must identify and construct goal obstacles by inquiry from the available information sources when we think is pertinent or the context is not clear. Once the goals have been specified and elaborated to the greatest possible, this information must be operationalized and translated into the natural language expression for characterization attributes. 3.2.2. Operationalization of Goals Into Characterization Attributes During operationalization, the actions described stakeholders and the extracted information are related back to the goals. Goals are a logical organizing mechanism for the incorporation of information. As mentioned above the actions are mapped into goals. We used tables to represent this mapping (see Table 3.5). In the operationalization activities we also used tables as a resulting artifact. While no formal in the strict sense, provides a textual representation of goals and attributes organized according to system goals as prescribed by the topography. For constructing that table, we analize the previous information from Goal Analysis and Refinement activities (tables 3.4 and 3.5), then apply the inquiry cycle (explained in the next section) for getting the question-answer pairs attained to each characterization attribute. Here, we present in table 3.8 the resulting table of the actvitivies of adapted GBRAM to our approach: 35 3535 35 36 3636 36 Natural Language Descriptions Consider each fragment Goal Exemplified? Action Words? Avoidance Goals? More Fragments? Consider next fragment Specify goal Specify goal origin Specify agents Multiple Stakeholders? Conflicts? Specify stakeholder(s) Specify Conflicts More fragments? Consider each specified goal Specify preconditions Specify postconditions Precedence Dependency? Specify goal Dependency Agent dependency? More dependencies? Contract dependency? More goals? Goals uncovered by examining dependencies? Goals ordered? Eliminate system specific goals Reconcile synonymous goals Eliminate redundant goals Order goals Construct goal hierarchy Consider each goal in hierarchy Specify constraints Specify negation obstacle Precedence obstacle? Specify obstacle More obstacles? Agent obstacle? More goals in hierarchy? Goal uncovered by examining obstacle Identify circumstances Consider next goal in hierarchy Consider each goal obstacle More scenarios? Construct scenarios Goal uncovered by examining scenarios Operationalize Characterization Attributes No Yes Yes No No No Yes Yes Yes No No No Yes Yes Yes Yes No No Yes No No No Yes Yes Yes No No Yes No No Yes Yes Yes Yes Yes Yes No No No No No Figure 3.4 Adapted GBRAM Control Flor Chart Figure 3.4 provides a reduced overview of the adapted activities of GBRAM, represented in a control flow chart. The flow chart is an approximation of the method. The boxes in 37 3737 37 the figure represent the activities that we must perform. The diamonds represent the various inquiry points for an inquiry-driven approach throughout the adapted GBRAM process, while the ellipses represent the input (natural language descriptions) and output (characterization attributes) of the method. The arrows denote the flow throughout the process as well as the iterative nature of goal-based analysis. Boxes and ellipses have only one output edge; however, since the diamonds represent inquiry points, a decision is required of us. Thus, diamonds have two outgoing edges; one edge represents an answer of ‘yes’, and the other edge indicates an answer of ‘no’. Since many of the activities may be performed concurrently, the flow chart simply serve to demonstrate how GBRAM is performed. 3.3. 3.3.3.3. 3.3. Summ SummSumm Summary aryary ary This section presented the Goal-Based process and its associated heuristics within the context of our analysis of Software Requirements Area. First the process of identifying high-level goals from the sources by the application of GBRAM is fundamental. The extracted goals are expressed in structured natural language. We begin the goal mining process exploring any available information sources such as : • The information related with the domain and standards (i.e. IEEE, EIA) about Application Development in Software Engineering [14], [15], [16], [18], [19], [20], [23], [24] (see appendix A and B). • The diverse taxonomies that many consultant and organizations provide in that field [1],[2],[3],[12] (see appendix B). • The availability of products in the domain (e.g. vendors like Rational). [13],[21],[22]. Once goals are identified, they are elaborated; goal elaboration entails analyzing each goal for the purpose of documenting goal obstacles, scenarios, constraints, pre-conditions, post-conditions, questions and rationale. Goal refinement consists of removing synonymous and redundant goals, resolving any inconsistencies that exist within the goal set. In practice, the goals are documented and annotated with auxiliary information including the stakeholders and responsible agents (see Table 3.4). Goals are then organized according to precedence relations, the next step involves the matching of goals of the main information sources (see Table 3.5). 38 3838 38 Detailed techniques and heuristics for each of these operations are described in the thesis [11] Last, in the activity of operationalization the goals into characterization attributes, we construct a table analizing the previous information from Goal Analysis and Refinement activities (tables 3.4 and 3.5), then apply the inquiry cycle for getting the question-answer pairs attained to each characterization attribute. 39 3939 39 4. Heuristics and Guidelines his section provides a brief overview of some of the most useful heuristics of GBRAM and how we can apply them to our approach. In the GBRAM, heuristics are rules which guide us towards a high probability of success while avoiding wasted efforts. GBRAM provides sets of heuristics and guidelines for the identification of goals. One of our future objectives is to propose heuristics for the specific domain that helps to adapt the taxonomy to the changes, evolution of goals and needs of the users. The selection of heuristics depends upon the domain and on the information available. There are four types of heuristics employed using GBRAM: • Identification heuristics • Classification heuristics • Refinement heuristics • Elaboration heuristics Identification heuristics assist us in identifying goals, stakeholders, agents, and constraints from multiple sources. The objective of goal classification heuristics is to aid us in determining the type of each goal identified. Refinement heuristics employ a series of question and techniques to reduce the size of the goal set. Elaboration heuristics address the need to acquire more detailed information by considering goal dependency relations, suggesting the goal obstacles for which scenarios should be constructed and which scenarios to elaborate. We have to mention the concurrent and overlapping nature of these activities. 4.1. 4.1.4.1. 4.1. Goal GoalGoal Goal- -- -Based Instantiation of Inquiry Cycle Based Instantiation of Inquiry CycleBased Instantiation of Inquiry Cycle Based Instantiation of Inquiry Cycle The GBRAM heuristics are a set of rules. Some of these heuristics are straightforward, not requiring that we employ any specific inquiry process for adapting it to our domain. In contrast, other heuristics are meaningless without the accompanying questions to guide us in developing a deeper understanding and uncovering hidden goals and requirements. Often a simple answer to a question is insufficient; for example, justification or rationale for a particular response may be needed to understand the system. Thus, GBRAM offers a set of recurring question types which follows the inquiry cycle approach instantiated for goal-based analysis, and guide us in applying an inquiry-driven approach as they comprehensively investigate the available artifacts for descriptive answers. T 40 4040 40 The Inquiry Cycle model is a formal structure for describing discussions about requirements. That model was useful in the construction of question-answer pairs attained to characterization attributes (showed before in table . These recurring question types are summarized below: • What-is: These question request specific information regarding terminology which is unclear to someone with no knowledge of the application domain. For example, we may ask a stakeholder, “What is the process for deciding what elicitation technique to use?”. In any analysis effort, participants in the process have to develop a common understanding of the concepts and terms. What-is questions enable us to do precisely this. What-is question clarify a situation or scenario enabling us to ensure that something is understood correctly. This type of question is most useful when we interact directly with stakeholders. • Who-is: These questions request specification of the agent responsible for the given task, process or goal. It is helpful to ask questions such as, “Who is responsible for the ultimate decision?” and “Who is responsible for this task?” By asking who-is questions, we can acquire information about the various agents and tie the information to the corresponding goal-based on implied or explicit responsibility. • Why: These questions request reasons which underlie work activities. We must ask questions such as “Why is this information routed?” While it is relatively simple for us to determine what information is required to route, the reason why the information is routed can be very difficult (if not impossible) to ascertain without direct stakeholder inquiry. • What-if: It is beneficial to ask questions that enable us to further examine cases in which an unexpected action occurred in order to explore how other system features may be affected. These questions mandate the consideration of the other agents and processes that would be affected in the event of such an unexpected cancellation. • When: These questions request timing constraints for a given event or events. To ascertain this type of information, we ask questions that may be followed up with a clarification question. • Relationship: These questions ask how one agent is related to another or how one goal is related to another goal so that the dependency relations may be established. For example, we may consider each goal and ask: “What goals are prerequisites for this goal?”, “What goals must follow this goal?”, and “What agents depends on this goal for completion of their responsibilities?” These question types assist us in knowing when and how to apply GBRAM heuristics by providing a guide as to how much detail is needed one can be reasonably confident that 47 4747 47 Figure A2. SR Model for Requirements Engineer 48 4848 48 Appendix A Application Development Software Information he remainder of this section present most of the information gathered in our context of interest. It is not the purpose of this section to analyse deeply either the software engineering or the software development process. Our purpose in this section is to provide the reader with a general overview of some of the main information we gather and key concepts involved in the software application development process to understand the domain and to exemplify the goals extraction. Issues such as software engineering process, methods, and specific activities related with it will only be addressed in an informative way, as parts of a bigger picture that will be later used as a framework reference. Firstly, we present the concept of Application in this context [14] : • The set of business processes which capture and maintain business data and provide business information. These processes may be either manual or automated. • In information Technology, an application is the use of a technology, system or product. • The term application is a shorter from application program. An application program is a program designed to perform a specific function directly for the user or, in some cases, for another application program. Examples of applications include word processors, database programs, web browsers, development tools, drawing, paint, image editing programs, and communication programs. Applications use the services of the computer´s operating system and other supporting applications. The formal request and means of communicating with other programs that an application program uses is called the application program interface (API). In computer programs and software product development, the development environment is the set of processes and programming tools used to create the program or software product. The term may sometimes also imply the physical environment. An integrated development environment is one in which the processes and tools are coordinated to provide developers and orderly interface to and convenient view of the development process (or at least the processes of writing code, testing it, and packaging it for use). An example of an IDE products is Microsoft Visual Studio .NET. The term computerassisted software environment (CASE) is generally used to describe a set of tools and practices that facilitate management of a software development project. T 49 4949 49 As a result, Software Application Development are all activities related in the construction of software programs, designed for performance a specific function required for the user(s), in some cases may be another program. Software Process [16] The software process is a framework for the tasks that are required to build high quality software. Software engineering is a layered technology (Fig. A1.1). Any engineering approach (including software engineering) must rest on an organizational commitment to quality. Figure A1.1 Software Engineering Layers The foundation for software engineering is the process layer. Software engineering process is the glue that holds the technology layers together and enables rational and timely development of computer software. Process defines a framework for a set of key process areas that must be established for effective delivery of software engineering technology. The key process areas form the basis for management control of software projects, and establish the context in which technical methods are applied, work products (models, documents, data, reports, forms, etc.) are produced, milestones are established, quality is ensured, and change is properly managed. Software engineering methods provide the technical “how to´s” for building software. Methods encompass a broad array of task that include: requirements analysis, design, program construction, testing and support. Software engineering methods rely on a set of basic principles that govern each area of the technology and include modeling activities and other descriptive techniques. Software engineering tools provide automated or semi-automated support for the process and methods. When tools are integrated so that information created by one tool can be used by another, a system for the support of software development, called computer aided software engineering (CASE), is established. Thus, commonly we find that the software development process topic covers life cycles, best practices, and associated standards. a quali ty focus process m ethods t ools 50 5050 50 Software Application Development Our main source of information in the sense Standard Information related with Application Development Software is: SWEBOK (Guide to the Software Engineering Body of Knowledge)[15], that provide a consensuated characterization of the bounds of the Software Engineering discipline. The Body of Knowledge is subdivided into ten Knowledge Areas (KA). See Figure A1.2. Guide to the Software Engineering Body of Knowledge (Version 0.95) Software Testing Software Maintenance Software Construction Software Configuration Management Software Design Software Engineering Process Software Requirements Software Engineering Tools and Methods Software Engineering Management Software Quality Figure A1.2 SWEBOK Knowledge Areas Our purpose in this section is to provide the reader with a general introduction and overview of some of the key concepts involved in the software application development process, specifically the Software Requirements area that is showed as a case study to exemplify the applicability of GBRAM in the construction of taxonomies. Issues such as software engineering process, methods, and specific activities related with it will only be addressed in an informative way, as parts of a bigger picture that will be later used as a framework reference, but all information gathered is in the references. Software Requirements Area [15] The knowledge area breakdown that is chosen by SWEBOK (presented in Figure 3) is broadly compatible with the sections of ISO/IEC 12207-1995 [18] that refers to requirements engineering activities. 51 5151 51 Figure 3. Software Requirements Area breakdown A requirement is defined as a property that must be exhibited in order to solve some problem of the real world. The first knowledge sub-area is the requirement engineering process, which introduces the requirements engineering process, orienting the remaining five topics and showing how requirements engineering is related with the overall software engineering process. It describes process models, process actors, process support and management and process quality improvement. The second sub-area is requirements elicitation, which is concerned with where requirements come from and how they can be collected by the requirements engineer. It includes requirement sources and techniques for elicitation. The third sub-area, requirements analysis, is concerned with the process of analyzing requirements to: • detect and resolve conflicts between requirements; • discover the bounds of the system and how it must interact with its environment; • elaborate system requirements to software requirements. Requirements analysis includes requirements classification, conceptual modeling, architectural design and requirements allocation and requirements negotiation. The fourth sub-area is software requirements specification. It describes the structure, quality and verifiability of the requirements document. This may take the form of two documents, or two parts of the same document with different readership and purposes. The first document is the system requirements definition document, and the second is the software requirements specification. The sub-area also describes the document structure and standards and document quality. 52 5252 52 The fifth sub-area is requirements validation whose aim is to pick up any problems before resources are committed to addressing the requirements. Requirements validation is concerned with the process of examining the requirements document to ensure that it defines the right system (i.e. the system that the user expects). It is subdivided into descriptions of the conduct of requirements reviews, prototyping, model validation and acceptance tests. The last sub-area is requirements management, which is an activity that spans the whole software life -cycle. It is fundamentally about change management and the maintenance of the requirements in a state that accurately mirrors the software to be, or that has been, built. It includes change management, requirements attributes and requirements tracing. 53 5353 53 Appendix B Trends and Terminology of the Actual Market ere, we present many definitions and terminology used in the actual market of Software Application Development. The principal sources of information were [13], [17] and [19]. Planning The following is a list of planning-related terms and a description of each: • Methodware. (Sometimes called software process management tools). This features knowledge "libraries," workflow, defined development routes, estimation support, multiple alternative processes, planning, tracking and related functionality. • Process management. This is a management concept that describes the goal of increasing intra-enterprise coordination of separate business functions. The growth in the demand for enterprise software reflects the need for increased integration and sharing of business information throughout an enterprise. o Project portfolio management (PPM). PPM applications provide a set of integrated functions designed to streamline outward functions and inward processes of project-intensive departments, industries and organizations. They address a majority of the nine processes defined by the Project Management Institute's Project Management Book of Knowledge (PMBoK): project scope management, time management (including scheduling), cost management, resource management, quality management, project communications management, project risk management and project procurement management. The ninth area provides for integration of these processes. PPM applications optimize project delivery by providing, at a minimum, integrated functionality to support project planning, tracking, resource assignment and portfolio reporting. • Requirements management. Requirements management tools streamline development teams' analysis of requirements, capture requirements in a database-based tool to enable collaborative review for completeness, ease usecase or test-case creation, provide traceability and facilitates documentation and versioning/change control. The database approach uses special purpose H 54 5454 54 repositories that are part of the requirements management solution or ship with a general-purpose commercial database integrated with the tool. Design The following is a list of design-related terms and a description of each: • Business process analysis (BPA). This is the fundamental analysis of business processes and management systems to improve them for cost reductions, faster time to market, lowered risk or higher business value. BPA can point out opportunities for optimization, automating manual processes, reducing error cycles and identifying revenue leakage points. It uses objective, quantitative methods and tools to analyze, redesign and transform business processes, including supporting organization structures, information systems, job responsibilities and performance standards. In some cases, BPA could point out the need for wholesale changes implied in a full business process reengineering (BPR) effort. • BPA analytical techniques. These are mathematical, graphical, logical and managerial algorithms for describing and modeling business processes, information systems or management decision-making systems. • BPA methodology. This is an integrated set of management policies, project management procedures, and modeling, analysis, design and testing techniques for analyzing established business processes and systems; designing new processes and systems; testing, simulating and prototyping new designs before implementation; and managing the implementation process. • BPA tools. These are combinations of techniques and software products that allow electronic capture, analysis, testing, simulation, reconfiguration and persistent memory of business and systems models. • BPR. This is the fundamental analysis and radical redesign of business processes and management systems to accomplish change or performance improvement. • Database design. This includes logical (entity relationship) and physical (table, column and key) design tools for data. Physical data modeling is becoming almost mandatory for applications using relational database management systems (RDBMS). Strong support for physical modeling is paired with facilities to manage multiple models, to submodel or extract from larger models and to reverse-engineer a database design from established tables. Developers are a secondary market often targeted with a subset of the complete functionality. 55 5555 55 • Object-oriented analysis and design (OOA&D). These are tools that support object analysis and design technologies and they commonly use Unified Modeling Language (UML) notation with a variety of methodologies to assist in the creation of highly modular and reusable software. Applications, data, networks and computing systems are treated as objects that can be mixed and matched flexibly rather than as components of a system with built-in relationships. As a result, an application need not be tied to a specific system or data to a specific application. Note: The UML standard from Object Management Group has become the defacto standard for OO A&D tools. Construction (Development Environments and Suites) The following is a list of construction-related terms and a description of each: • Language-oriented development environments. Typically, these are development environments built around a compiler and a language, such as COBOL, C/C++, Fortran, ADA and PASCAL, among others. Languageoriented development environments generally include graphical user interface (GUI) builders, debuggers, editors and other utilities that are integrated into the environment. • Integrated services environments (ISEs). An ISE is a suite of integrated development tools, frameworks and technologies used for building service oriented and composite applications. Most often, these applications will implement a service-oriented architecture (SOA) and will use the techniques of services-oriented development of applications (SODA). ISEs are producer platforms (for creating services), much as application servers are provider platforms (for hosting services) and portal servers are consumer platforms (for using services). Seven basic characteristics of an ISE define the completeness of its support for SODA:  Design. Specification of application requirements  Modeling. Definition of application structure  Fabrication. Writing code, creating components and wrapping legacy resources. Nominally, this is the function of an integrated development environment (IDE).  Assembly. Aggregation of components, alignment of inputs to outputs, translation of input or output data  Orchestration. Flow control and process management  Automation. Hiding complexity and removing the need to write code  Variability. Rapid change management. The variability of a system may be inversely proportional to its automation. 56 5656 56 • Traditional (client/server) applications development (AD) tools. This includes all traditional client/server development environments. They may be client/server fourth-generation languages (4GLs) targeting older technologies (for example, VisualBasic targeting the Microsoft COM/DCOM environment) and third-generation language (3GL) generators for Cobol, C or C++ targeting MVS or Unix. • Wireless and mobile AD. This is the function of creating applications for wireless and mobile devices. The term refers not simply to programming, but to the larger overall process of defining application requirements, planning the application structure, developing the code, monitoring development progress and testing results. In summary, it covers the entire software development life cycle as it relates to a mobile or wireless application. • Business rule engines. Business change has been a constant companion of systems development since the inception of IT, but a growing number of factors has led to the increase of change necessary to remain competitive in business. This increase in the frequency of change is leading to new approaches to alter the business rules embedded in business process flows, applications and even in the enterprise architecture. Enterprises are more pressed to become adaptable and apply the knowledge captured in rule sets to outflank competitors and respond to changing business environments. They can no longer wait for professional programmers to change applications written in traditional programming languages. Business users want to change rules without going through a long-running change process that is, at best, measured in days and, at worst, measured in weeks and months. Therefore, rules engines allow even end-users to make dynamic "real time" changes to their applications in an abstracted level of language. Automated Software Quality Automated software quality (ASQ) includes all of the tools that are used to ensure the design and development of zero-defect software. The ASQ category consists of automated testing tools, software test management tools and hosted testing services. • Automated testing. Automated testing applies commercially or internally developed software or services to assist in the testing process. Automated tests provide consistent results and data points. The benefits are repeatability, ease of maintenance, the ability to efficiently use resources in off-peak hours and the capability to create reports based on the executed tests. • Software test management. This involves the planning and monitoring of the testing effort and includes control of the testing resources. From a tools perspective, test management is the collection, display, and control of tests and 63 6363 63 Composite Markets A composite market is one not necessarily tracked and measured on an ongoing basis, but that offers an alternative view or cut of our baseline market data (defined in Infrastructure Software or Enterprise Application Software). A composite market definition can be useful for tracking a temporary phenomenon. Occasionally, a composite market definition foretells the emergence of a long-lasting baseline Gartner Dataquest market definition at a later date. New composite markets are always emerging. Rather than continually reorganize the component segmentation, Gartner will address new markets as exceptional or fringe until they are clearly an established and well-defined market segment in their own right. Business Activity Monitoring BAM is neither a market nor a product. It is a concept, such as quality or knowledge management, and it is not new. BAM solutions focus on crossbusiness processes rather than divisional-, departmental- or technology-specific processes. The scope of integration in BAM solutions expands far beyond the four walls of a plant or a division, and real time is not necessarily nanoseconds but rather is determined by the requirements of the business process. It brings the near real-time world of the BI operational data store together with NSM monitoring and BPM through integration brokers and shared messaging. Collaborative Commerce (C-commerce) involves the collaborative, electronically enabled business interactions among an enterprise's internal personnel, business partners and customers throughout a trading community. The trading community can be an industry, industry segment, supply chain or supply chain segment. For some enterprises, c-commerce is already a fact of business life, but how can they measure it? It is not yet quantifiable with any consistency. It is not a class of software and it is difficult even to define. Corporate Performance Management (CPM) is a term that describes the methodologies, metrics, processes and systems used to monitor and manage the business performance of an enterprise. Applications that enable CPM translate strategically focused information to operational plans and send aggregated results. These applications are also integrated into many elements of the planning and control cycle, or address BAM or customer relationship optimization (CRO) needs. CPM applications enable sharing of information across and even beyond the borders of the 64 6464 64 enterprise, to all employees, business partners shareholders and most importantly, customers. Contract Management Is the identification and efficient management of all contracts with suppliers. Applications that manage companies' contracts weave themselves through sourcing and procurement applications. Although contract management is an integral part of sourcing (creation) and procurement (enforcement), Gartner has separated it out as a segment but acknowledge the interdependencies. Contract management aides sourcing and procurement through negotiation, generation and non-repudiation, abstraction, versioning and archiving, compliance management and exception alert generation, and dispute resolution. DBA Software Tools Database administration (DBA) tools encompass software products including systems management extensions for monitoring the health of databases, DBA tools for SQL tuning, space optimization, schema change management, back up and recovery products for files as well as database-aware recovery products, data warehouse administration tools, and certain database development tools often used by database administrators. This market could also be called the DBMS aftermarket. ERP II and Enterprise Application Suite The emerging next generation of ERP strategy is called ERP II by Gartner Dataquest. ERP II is an application and deployment strategy that expands out from ERP functions to achieve integration of an enterprise's key domain-specific, internal and external collaborative, operational and financial processes. Mobile and Wireless Packaged Applications Software The terms mobile application and wireless application are bandied about in the trade press, often used interchangeably, and can refer to simple stand-alone software or to internet-worked processes of great complexity. Mobile and wireless applications can mean anything from a system on a smart phone, a calendar or a tic-tac-toe game on a PDA to Internet/corporate e-mail connectivity up to a sales force automation order-entry system that updates back-end databases over a wireless link. Mobile and Wireless Infrastructure Software Platforms Here are development tools and deployment servers for creating brand new customer mobile applications or for "mobilizing" established conventional enterprise applications, e-mail and enterprise data stores. 65 6565 65 Order Management It is a business process and not a specific market. Much of the functionality attributed to order management is embedded within and touches components within the CRM (Customer Relationship Management), ERP (Enterprise Resource Planning) and SCM (Supply Chain Management) markets as it guides products and services through order entry, processing and tracking.  Product Life Cycle Management: At its highest definitional level, product life cycle management (PLM) is a process for guiding products from idea through retirement to deliver the most business value to an enterprise and its trading partners. PLM employs product information and business analysis to support product portfolio strategy, product life cycle planning, management of activities, and execution of those activities through each phase in a product's life. The applications that support the business activities enabled through PLM includes product ideation, design, engineering, manufacturing process management, product data management, and product portfolio management. Smart Enterprise Suites Include a significant combination of technologies, such as content management, team support, a portal framework and information retrieval. They may also include expertise location and management, community technology, process management, and multichannel access. Supplier Relationship Management There has been much ado for nearly two years about the user benefits of supplier relationship management (SRM). With much fanfare and accolades from the software industry, there is a still confusion and varying opinion on what exactly SRM is and what it should encompass. So, is there an SRM software market? No, not yet. There are a plethora of software applications that support SRM initiatives but, to date, no true SRM applications. SRM is a logical extension of SCM. SRM is the latest of a series of innovations within SCM and represents an incremental development. As such, SRM is a subset of SCM. SRM represents an evolutionary extension of SCM, driven by the need for enterprises to create a more comprehensive life cycle view of suppliers' operational contribution to the top and 66 6666 66 bottom lines. Consequently, SRM is an extension of, and builds on, SCM technologies and practices. Web Services Software Deploying Web services-enabled software will be an evolutionary process, not a revolutionary one. While the majority of software vendors have committed to supporting Web services software standards within their established product lines, it will take more than four years to evolve these immature standards, build up skills, and plan, build and test for new versions of software that gradually incorporate these standards. Web services standards will be deployed through multiple markets, such as integration suites, AD tools and some enterprise application segments. Other Markets  ASPs and Application Hosting: This is a service addressing the life cycle needs of the application from the initial IT infrastructure development to maintenance of a complete set of IT business applications. The provider offers software maintenance, conversion, enhancement and support in a hosted environment. This is considered an indirect channel for software delivery. This sector is also researched within Gartner Dataquest's IT services practices.  Open Source Software: The focus of Gartner is to measure the direct value of software markets. However, free software can and does have a significant influence on the dynamics of demand and supply, and it influences the Gartner´s research agendas.  Software Solutions Markets: Software products are often bought and sold as part of a larger package containing some mix of hardware, software, services, expertise, information content and financing service. To implement, operate and use the solutions requires investment in internal resources. The methodology behind of the market data analysis allows to Gartner to unbundle these elements so that they are counting or comparing similar things. Most of their solutions market research is clustered into analyst teams for global industry vertical market analysis and enterprise solutions. 67 6767 67  New Categories: New markets are always emerging, which are either the result of the bundling of several component markets or the arrival of a new layer of tools on top of established technology. Rather than continually reorganize the component segmentation, Gartner will address new markets as exceptional or fringe until they are clearly an established and welldefined market segment in their own right. The Gartner research covers software vendors worldwide by selected software categories. Based in this research, they develop and maintain a database of information on software supply by vendor, revenue, region and software segment. In addition they also analyze segment and vendor revenue by platform, vertical industry, enterprise size and sales channels (direct, indirect and others) for most of the markets. The definitions and factors for segmentation are revised, altered or expanded each year to reflect changes in software technologies and the software marketplace. As a result they have a very complete taxonomy of the entire market. It is very easy the navigability and find any related topic. In addition, we can find the dependencies or lapping of the segment with other segments. Next, we analize the taxonomy proposed by Gartner for Application Development: Gartner Application Development Taxonomy The categories for which application development software is analyzed are comprehensively defined here for the purpose of providing clarity and guidance. This taxonomy is available on internet, and we can search the actual research and products depend on our requirements of information. In other words, you can find very easy many products and papers related with your subject. 68 6868 68 GARTNER Application Development (2580) L1 L2 L3 L4 L5 Subcathegory 1 Application Development Tools (870) 1 1 Development Life Cycle Software (107) 1 1 1 Debugging and Defect Tracking Tools (6) 1 1 2 Software Configuration Management Tools (9) 1 1 3 Migration and Porting Tools (7) 1 1 4 Software Process Management (5) 1 1 5 Methodware(2) 1 1 6 Test Software (32) 1 1 6 1 Software Testing (47) 1 2 Development Enviroment and Suites Software (154) 1 2 1 Integrated Development Environments (20) 1 2 2 Modeling and Code Generation (18) 1 2 3 CASE Tools(3) 1 3 Programming Language Software (85) 1 4 Development Infraestructure Software (16) 1 5 Embedded Software Tools (72) 1 6 Rapid Application Development Tools (13) 1 7 Web Site Development Tools (135) 1 8 Web Services Production Platforms 2 Application Development Governance (104) 2 1 Application Development Metrics (16) 2 2 Capability Maturity Model (29) 2 3 Software Process Improvement (20) 3 Application Development Methodologies (482) 3 1 Legacy Application Extension Methodologies (135) 3 2 Object-Oriented Development Methodologies (12) 3 3 Reuse and Component-Based Methodologies (43) 3 4 Agile Development Methodologies (29) 3 5 Application-Specific Methodologies (215) 4 Application Deployment (51) 4 1 Application Deployment for Wireless and Voice (10) 4 2 Application Deployment for E-commerce and Internet (9) 4 3 Application Deployment for Legacy and Client/Server 4 4 Deployment and Distribution (94) 5 Application Development Project Management (261) 5 1 Projetc Management Office (16) 5 2 Service Level Agreements (7) 5 3 Software Configuration Management Tools (6) 5 4 Configuration Management Software (71) 5 5 Project Portfolio Management (171) 5 5 1 Professional Service Automation (45) 5 5 2 Service Optimization Management (38) 5 5 3 Portfolio Management Software (16) 5 5 4 Project Management Software (17) 5 5 5 Services Process Analytics and Forecasting (3) 6 Application Development Quality (132) 6 1 Software Testing (47) 6 2 Debugging and Defect Tracking Tools (6) 6 3 Test Software (32) 7 Application Architecture (582) 7 1 J2EE (33) 7 2 .Net (88) 7 3 Service-Oriented Architecture (85) 7 4 Service-Oriented Development of Applications (64) 7 4 1 Composite Applications (27) 7 5 Open Source Applications (85) 7 6 Enterprise IT Architecture (216) 7 7 Web Services (505) 7 7 1 Web Services Security (26) 7 7 2 Web Services Production Platforms (19) 7 7 3 Web Services Management Platforms (16) 8 Custom Application Development Services (131) 9 Software Configuration Management Tools (9) 10 Portfolio Management (60) 69 6969 69 INCOSE [2] INCOSE is an international organization formed to develop, nurture, and enhance the interdisciplinary approach and means to enable the realization of successful systems. INCOSE works with industry, academia, and government to: • provide a focal point for dissemination of systems engineering knowledge • promote collaboration in systems engineering education and research • assure the establishment of professional standards for integrity and in the practice of systems engineering • encourage governmental and industrial support for research and educational programs that will improve the systems engineering process and its practice They work in many areas, the most important for this report, is concerned with COTS tools. In that sense, they maintain a database with information related with COTS. They provide by means the Modeling and Tools Technical Committee MTTC the constituency with information regarding COTS systems engineering SE tools, as well as guidance regarding the development and use of models constructed with such tools. In addition, they are the resource center for tools standards--including tool exchange and emerging modeling standards. The MTTC consists of some seventy Software Engineers that are working within three technical areas supported by the following structure: • SE Tools Database Working Group: Deliver a tools comparison/information database for requirements management tools. • Tools Integration Working Group: Promote tools interoperability and provide concepts for integration of COTS SE tools, develop tool information exchange standards. • Model-Driven System Working Group: Develop and disseminate executable representations of the systems engineering process, including schemas for tools integration. • Soft Systems Engineering Working The Tools Database Working Group's is bringing online an automated tools survey that will allow the tool vendors to directly update their tool information (rather than wait for the TDWG to get together and post the information). The user is notified if the information was verified or not, because the valuation by the vendors can be “partial”) INCOSE shows (as a free access) a taxonomy based on a database of products. The taxonomies that they present (in fact, they arrange the information from his database by means standards like IEEE-1220) are so general. 70 7070 70 INCOSE (IMPIG TAXONOMY) Systems Engineering L1 L2 L3 L4 L5 Subcathegory 1 Management 1 1 Configuration Management Tools 1 2 Work Flow Management Tools 1 3 Risk Management Tools 1 4 Cost Estimating & Tracking Tools 1 4 1 Cost Estimating Tools 1 4 2 Cost Tracking Tools 1 5 Defect Tracking Tools 2 Engineering Tools 2 1 System Design Tools 2 1 1 System Modeling Tools 2 1 1 1 Structural Modeling Tools 2 1 1 2 Behavioral Modeling Tools 2 1 1 2 1 Static Behavioral Tools 2 1 1 2 2 Dynamic Behavioral Tools 2 1 1 3 HMI Prototyping Tools 2 1 2 Design Support Tools 2 1 2 1 Simulation Tools 2 1 2 2 Numerical Analysis Tools 2 1 2 3 Domain Specific Tools 2 1 2 4 Measures of Effectiveness Tools 2 2 Requirements Engineering Tools 2 2 1 Requirements Management Tools 2 2 1 1 Requirements Classification Tools 2 2 1 2 Requirements Capture & Identification Tools 2 2 1 2 1 Textual Requeriments Capture Tools 2 2 1 2 2 Tools for Elicitation of Requirements 2 2 1 3 Requirements Traceability Tools 2 2 2 Requirements Generation Tools 2 3 Design Validation Tools 2 3 1 Thread Analysis Tool 2 3 2 Test Validation Planning Tools 2 3 3 Scenario Validation Tools 2 3 4 Tools to Validate System Compliance/Requirements 2 3 4 1 Measurement Tools 2 3 4 2 Performance Analysis Tools 2 4 Specialty Engineering Tools 3 Information Sharing (and Process Tools) 3 1 Communication Tools 3 1 1 Interpersonal Communications Tools 3 1 2 Network Information Retrieval Tools 3 1 2 1 Directory Services 3 1 2 2 File Transfer 3 1 2 3 Information Services 3 1 2 4 World Wide Web 3 2 Data Analysis Tools 3 2 1 Spreadsheet Tools 3 2 2 Data Reduction Tools 3 2 3 Data Visualization Tools 3 3 Electronic Publishing Tools 3 3 1 Automatic Document Generation Tools 3 3 2 Technical Publishing System 3 3 3 Technical Ilustration Tools 3 3 4 File Format Converters 3 4 Electronic Viewing Tools 3 4 1 Database End User Viewers 3 4 2 Formatted Document Viewers 3 5 Tool Integration Facilities 4 Infrastructure Support 4 1 System Administration 4 2 Network Support 4 3 Product Data Management 4 4 Through a collaborative effort between the INCOSE Information Model & Process Interest Group (IMPIG) and the Tools Database Working Group they have merged the Tools Taxonomy graphics and descriptions with the Tools database of information 71 7171 71 related to Commercial off-the-shelf (COTS) and Government off-the-shelf (GOTS) software of interest to Systems Engineers. Definitions Related with the Construction the of IMPIG Taxonomy. Configuration Management Tools: Configuration Management is responsible for managing system baselines, both products of the engineering process and the tools used to create those products. Configuration Management incorporates version control, baseline control, change history, check-in check-out control, change and archiving capabilities of both process and product. Work Flow Management Tools: Work Flow Management tools are used to define and schedule tasks, and make work assignments. They help monitor progress, allow for prioritization of tasks, and support task review/approval. Workflow Management should also identify resource loads and critical paths. Automation can help enforce the Integrated Product Development Process through the use of pre-defined workflow models. Risk Management Tools: Risk Management techniques support qualitative risk identification and quantitative risk analysis and visualization. It is used to manage technical, cost, and schedule risks, including the ability to meet performance requirements and measures of effectiveness. Risk Management supports management decisions, identifies risk prioritized by program impact, and generates risk mitigation plans. Cost Estimating & Tracking Tools: Cost Estimation and Tracking techniques are used to estimate the cost of tasks and to roll those costs up to total project cost. They require input information that provides Basis of Cost parameters from prior experience. They are also used to track the cost of the project during development and must interface with the organization's financial recording and reporting system. Cost Estimating Tools: Develop system pricing considering design complexity, domain knowledge, historical cost information, and cost objectives. Cost Tracking Tools: Means of collecting costs, and estimating Budgeted Cost of Work Scheduled (BCWS), Budgeted Cost of Work Performed (BCWP), Actual Cost of Work Performed (ACWP), etc. Defect Tracking Tools: Defect Tracking techniques are used to record system defects and change requests found in product testing and in the field. These techniques track the date the issue was identified, assigned, removed, tested, and verified. They also record a description of the defect, its priority and severity, information about its method of removal, potential work-arounds if the defect can not be removed, etc. 72 7272 72 Behavioral Modeling Tools: Behavioral Modeling falls into two categories, static and dynamic. Behavioral Modeling helps model the functional capabilities of a system and its response to events. Static Behavioral Tools: Static Behavior Modeling presents a static description of the behavior of the system. Static implies that the model may represent dynamic behavior, but it is not executable. Examples of static behavioral models are Functional Flow Block Diagrams, State Transition Diagrams, and Object Interaction Diagrams. Dynamic Behavioral Tools: Dynamic Behavior Modeling provides a dynamic description of the behavior of a system. These models are executable through simulation and prototyping. HMI Prototyping Tools: Human Machine Interface (HMI) Prototyping techniques are used to develop or verify HMI design by modeling the interaction of operators or users with the system. This work is particularly useful when performed early and reviewed with users to verify requirements and assumptions about the system. Automation provides the capability to describe input/output screens, to depict parts of the system and to animate these presentations. Simulation Tools: Simulation techniques are used for detailed subsystem modeling. Since it is generally impractical to model the entire system to a detailed level, selective employment of these techniques for the purpose of minimizing risk is recommended. Domain Specific Tools: Domain Specific includes a range of general purpose methods and techniques that are directed at a specific physical phenomenon. The subclass includes thermal/heat transfer, fluid flow, power dissipation, satellite performance/orbit injection models, sonar performance models, etc. that do not fall under the category of general purpose numerical analysis. Many of these methods are applied to complex boundary value problems and apply finite element or finite difference methods. Measures of Effectiveness Tools: Measures of Effectiveness support the definition of a parts tree and the budgeting of performance attributes among the components in the tree. Evaluation of measures of effectiveness occurs during trade-off analysis. Agility for comparing various design options is helpful. Requirements Classification Tools: Requirements Classification Tools help the engineer classify the requirements based on work to be done so that the requirement analysis activity can be scheduled and tracked. They help the engineer classify based on how the requirements will be used in modeling so that completeness of traceability can be monitored. 79 7979 79 80 8080 80 References 1. The Gartner Group, available on-line at http://www4.gartner.com 2. INCOSE. “Software Engineering Tools Taxonomy”. http://www.incose.org/tools/tooltax/se_tools_taxonomy.html 3. J.-C. Mielnik, B.Lang, S.Lauriére, J.-G. Schlosser, V. Bouthors. “eCots Plattaform: An Inter-industrial Initiative for COTS-Related Information Sharing”. In Proceedings of 2nd International Conference on COTS-Based Software Systems (ICCBSS), LNCS 2580, 2003. 4. J.P. Carvallo, X. Franch, C. Quer, M. Torchiano. “Characterization of a Taxonomy for Business Applications and the Relationships Among Them”. Proceedings 3rd International Conference on COTS-Based Software Systems, ICCBSS´04, Redondo Beach (California). 5. A. I. Anton. “Goal-Based Requirement Analysis”. IEEE Proceedings of International Requirements Engineering Conference, 1996. 6. E. Yu. “Modelling Strategic Relationships for Process Reengineering”. Ph.D. thesis, also Tech. Report DBKS-TR-94-6, Department of Computer Science,University of Toronto,1995. 7. X. Franch, J.P. Carvallo. “Using Quality Models in Software Package Selection”. IEEE Software, January/February 2003. 8. J.P. Carvallo, X. Franch, C. Quer. “Defining a Quality Model for Mail Servers”. 2 nd International Conference on COTS-Based Software Systems (ICCBSS), Ottawa, Canadá, 2003. 9. Pere Botella, X. Burgués, Juan P. Carvallo, X. Franch, C. Quer. “Using Quality Models for Assessing COTS Selection”. Proceedings V Workshop on Requirements Engineering (WER’02), Valencia, Spain. November 2002. 10. A. Vam Lamsweerde. “Goal-Oriented Requirements Engineering: A Guided Tour”. Proceedings RE’01, 5 th IEEE International Symposium on Requirements Engineering, Toronto, August 2001. Pp 249-263. 11. A. I. Antón. “Goal Identification and Refinement in the Specification of Software-Based Information Systems”. Ph.D. thesis, Georgia Institute of Technology, June 1997. 12. International Data Corporation http://www.idc.com 13. ComponenSource http://www.componentsource.com 81 8181 81 14. http://searchvb.techtarget.com 15. Guide to the Software Engineering Body of Knowledge, SWEBOK, www.swebok..org 16. Roger S. Pressman. “Software Engineering: A Practitioner´s Approach” (European Adaptation, 5 th Edition). McGraw-Hill.. ISBN:0077096771. 17. CBSE Net. Component Based Software Engineering Network. http://www.cbsnet.org 18. ISO/IEC 12207-1995 19. Infrastructure Software Market Definitions for Application Development. Gartner, Dataquest Guide. 4 th June, 2003. http://www.gartner.com 20. Software Market Research Methodology and Definitions 2003-2004. Gartner Dataquest Guide. 16 th January, 2004. http://www.gartner.com 21. Information of products and vendors. http:// 22. http://www.rational.com 23. IEEE/EIA 12207.1-1997 24. IEEE Std 830-1998. 25. CBSE Net. “Application Domain Taxonomy ”. Available on-line (previous registration) at: http://www.cbsenet.org/pls/CBSEnet/ eco_ricerca_documenti.concept_search_frame.