A System Engineering Approach to e-Infrastructure

Technique, Idea Writing, Warfield’s Interpretive Structural Modeling, Checkland’s Soft System Methodology, Hitchins’ Rigorous Soft Method. The book "Systems Engineering: Practice and Theory" is a collection of articles written by developers and researches from all around the globe. Mostly they present methodologies for separate Systems Engineering processes; others consider issues of adjacent knowledge areas and sub-areas that significantly contribute to systems development, operation, and maintenance. Case studies include aircraft, spacecrafts, and space systems development, post-analysis of data collected during operation of large systems etc. Important issues related to "bottlenecks" of Systems Engineering, such as complexity, reliability, and safety of different kinds of systems, creation, operation and maintenance of services, system-human communication, and management tasks done during system projects are addressed in the collection. This book is for people who are interested in the modern state of the Systems Engineering knowledge area and for systems engineers involved in different activities of the area. Some articles may be a valuable source for university lecturers and students; most of case studies can be directly used in Systems Engineering courses as illustrative materials. following:


Soft system method approach
There are several Systems Engineering approaches to address a solution to a problem. Nevertheless, Hitchins (2007) argues that the approach that makes use of Soft System Methods is the one that investigates the problem to be treated, looking for practical experiences and interactions with the problematic situation, trying to develop an understanding about the nature of problem symptoms and to propose solutions.
The use of Soft System Methods -a Soft Systems Approach -both allows the System Engineer to understand the problem domain, and helps him with the identification of social and human dimensions present in the problem domain. The former is because the activity to understand the problem domain is essentially an activity in which the components are human activities, and the second because there is an intrinsic complexity for accurately identifying human and social dimensions all along the System life.
The approach to go beyond Human Factors, and deal with the humans dimensions, is the use of the Soft System Approach with an evolutionary approach strategy. This approach deals with the interaction between Reality and Thought, and the interaction between Problem and Solution, it is represented at Figure 1 and was proposed by Soares (1986) as a way to understand, design, and implement solutions to a problematic situation. From the two interactions -Reality x Thought and Problem x Solution, there are four actions that generate a cycle to treat a problem. These actions are: (i) Understanding: when the System Engineer develops an understanding, an abstract representation of the real problem, (ii) Design: when the System Engineer creates a response to the problem that satisfies the Problem in the Thought dimension, (iii) Implementation: the construction of the response to the problem in terms of Reality, (iv) Use: set up of a response to the Problem, in the environment of the Problem.
The set up of a response to a Problem may cause changes in Reality, emerging scenarios not previously determined, giving rise to new demands and a redefinition of the Problem. The treatment sequence of the problems leads to an Evolutionary Spiral as in Figure 1.
However, different from Soares, the authors of this chapter consider Solution not only as a response to a problem, but also as an overcoming restrictions, improvements in an existing Reality through actions to treat the problematic situation. Solution is an indicative of an improvement, a response that satisfies, but does not always solve, the problem, i.e., a response to the problem that is the best at that moment.
Although the identification of human and social dimension all along the System life is important to System success; the first action of the process -Understanding -is crucial.

Consensual methods
Understanding the Problem in the Reality dimension ( Fig. 1) is the first step to determine the System construction possibilities. A proposal to develop this understanding and reduce users' dissatisfaction -respecting the human and social dimensions -is the use of Consensual Methods Consensual Methods are not only about getting a consensus about a problem to be treated, it is also about getting the Systems Requirements from the people that have interests in the System. The consensual processes deal with the human activities involved in identifying the requirements and the human and social dimensions, reducing the discrepancy between the expected Systems features and the ones that will be perceived by the users.
Next, the Consensual Methods used by the authors in their work are listed. Hitchins (2007) stated that these methods are specifically meant to the front end of the Systems methodology, they are: Brainstorming, Nominal Group Technique, Idea Writing, Warfield's Interpretive Structural Modeling, Checkland's Soft System Methodology, Hitchins' Rigorous Soft Method.

Brainstorming
This method is an approach in which a selected group of people is encouraged by a moderator to come up with ideas in response to a topic or a triggering question.

Nominal Group Technique (NGT)
This method is similar to Brainstorming. A moderator introduces a problematic situation to a group of people and asks participants to write down their ideas about the problem on a sheet of paper. After a suitable time for people to generate their ideas, all participants read www.intechopen.com their ideas and the moderator, or an assistant, write them in a flip chart. With all the ideas written, the moderator conducts a discussion about these ideas, and then the participants are invited to rank all ideas. An idea-ordered list is generated and this constitutes the ideas that have been produced by the group as whole.

Idea writing
This method takes TGN a little farther. The moderator introduces the theme, and the participants are asked to write their ideas, suggestions, etc., on a piece of paper. After two or three minutes, the moderator asks each participant to pass his sheet on to another person, to pass the sheet to the second person on the left, for example. The one who receives the sheet can see the ideas already written, which may lead him (her) to a new set of ideas. After a short time, the moderator asks for the sheet recirculation, this time, to a different number of people. The process is repeated for about 30 minutes, or until the moderator notes that most people do not have any more ideas. There are two purposes in this strategy: encouraging ideas emergence within the working group and hiding the origin of a particular idea. The lists of ideas are worked later through Brainstorming or TGN to generate an action plan.

Interpretive Structural Modelling (ISM)
This method is similar to a computer-assisted learning process that enables individuals or groups to map complex relationships between many elements, providing a fundamental understanding and the development of action courses to treat a problem. An ISM session starts with a set of elements (entities) to which a relationship must be established. These entities are identified using any other method. The result of ISM is a kind of graph, where the entities are nodes and the relations are edges. The whole process can be time-consuming, especially when there are many divergences among the group members. Therefore, this time is important. It is essential for participants to understand and to recognize the each other' arguments, reaching a consensus.

Checkland's Soft Systems Methodology (SSM)
This method promotes the understanding of a problematic situation through the interaction between the people involved in the problematic situation. It promotes the agreement of the multiple problem views and multiple interests, and may be represented by a seven-stage model. Stages one and two explore the problematic situation (unstructured) and express it in a rich picture. Stage three is the root definition of the relevant systems describing six aspect of the problem, which are called CATWOE, they are: Customers, Actors, Transformation process, World view, Owner and Environment constrains. In stage four, the conceptual models of the relevant systems are developed, and, in stage 5, the conceptual model is compared with the perceptions of the real situation. In stage six, an action plan is developed for the changes, which are feasible and desirable; and in stage seven, the action plan is implemented. As a method developed from the Soft Systems Thinking, SSM does not produce a final answer to the problematic situation, it seeks to understand the problem situation and find the best possible response (Checkland, 2000).

Hitchins' Rigorous Soft Method (RSM)
As SSM, this method is based on the General-Purpose Problem-Solving Paradigm and is context free. The people who are experiencing a problem, and have knowledge about it, provide information about it in meetings with a coordinator. This investigation, which searches for dysfunction sources related to the problem, can create a lot of information and data. Differently from SSM, RSM employs tools and methods for treating, organizing and processing information; the action of "process" implies a gradual reduction of the problematic situation by ordering the data, transforming them into information for the treatment of the problem. RSM has seven steps: (1) Nominate Issue & Issue domain, in which the problem issues are indentified and a description of the situation is made; (2) Identify Issue Symptoms & Factors, that identifies the symptoms of the problem, and the factors that make them significant to be explored; (3) Generate implicit systems, each symptom implies the existence of at least one implicit system in the problem situation; (4) Group into Containing System: at this step, the implicit systems are aggregated to form clusters, one cluster for each symptom, named containing system, which can generate a hierarchy of systems, highlighting issues related to the problem; (5) Understanding Containing Systems, interactions, imbalances: at this step, the interactions between the containing systems are evaluated; (6) Propose Containing Systems Imbalance resolution: this step uses the differences between an ideal world, where the symptoms do not exist, and the real world, to propose Sociotechnical solutions to the imbalances identified in the previous step; (7) Verify proposal against original symptoms: at this step, the system model are tested to see if they would, if implemented, eliminate the symptoms identified at step two and the imbalance found at step six. This model could also be tested for cultural acceptability by the people that are experiencing the problem (Hitchins, 2007).

Perspectives of consensual method selection
The diversity of people involved in an e-Infrastructure System development is a reality that Engineering must deal with. Zhang (2007) states that it is impractical to limit the diversity of people involved in a process to get a consensus about a problem to be treated. However, the methods to develop Systems requirements are under the Engineer's control. Kossiakoff & Sweet (2003) stated that the function of System Engineering is to guide the Engineering of complex Systems, and that System Engineering is an inherent part of Project Management -the part that is concerned with guiding the Engineering effort itself. Kossiakoff and Sweet also propose a System Engineering life cycle model that corresponds to significant transitions in Systems Engineering activities, and it is the model adopted as the life cycle framework to this work. It has three broad stages: The use of Consensual Methods to get a consensus about the problematic situation is a System requirements elicitation process. Consequently, a Consensual Method is a technique to implement the Concept Development Stage; thus, to be adherent to the System life cycle, the Consensual Methods must also provide information to other phases that are dependent on the requirement definition process. The information that is demanded by the following phases, and its purpose, is presented in Table 1 Table 2 is illustrative, rather than comprehensive. It is based on empirical findings from the authors' experience. It provides a practical starting point for organizing an approach to identify the Consensual Method that complies with the demands of the System life cycle.

Case study: e-Infrastructure for an ALCUE unit
From the Perspective of Method Selection, RSM is the Consensual Method that provides more information for the phases of the System life cycle. As a Consensual Method, it promotes the consensus among people about the problem issues, so that people feel welcomed by the process. Of course, as Hitchins (2007)

The issue and its domain
KNOMA is designing an ALCUE Unit, and desires to develop and maintain an e-Infrastructure to support it.
As usually occurs in Engineering practice, the demand comes to the Engineer with words that are known by the people involved with the problematic situation, which the Engineer is still unaware of.

Issue
The concern about the e-Infrastructure to be developed and maintained is about what needs to be done. However, this depends on the features needed for an ALCUE Unit, which are not clear.

Domain
The Each project partner should develop and implement an ALCUE Unit (VERTEBRALCUE, 2011). These Units must operate independently from each other; however, they must be linked as "vertebras" of the framework, strengthening the academic cooperation networks that already exist between the project partners institutions, providing structural support for new partnerships and corporations networks. The Vertebralcue Project board stated that each ALCUE Units operate as an Information Center, broadcasting information about both the intuition and the region it belongs to. Likewise, the Unit must receive information from partner institutions for internal disclosure.
www.intechopen.com A System Engineering Approach to e-Infrastructure

285
The ALCUE Unit operation deal with information and policy, as an academic collaborative process consists of multiple academic partners working together for information exchange and development of policy cooperation. In this operation process, there are interests of multiple actors: students, professors, researchers, and academic and social institutions. In the scenario of ALCUE Unit as an information center, there may be a distortion of information due to political interests, which can occur with pressures related to the disclosure of information or not. Uncertainty, diversity, quality and quantity of information are factors that can lead to a variation between the expected (planned) for a ALCUE Unit and the actual situation, perceived by the people who interact with the Unit, this variation is called complexity in this study.

Symptoms and Issue factors
The e-Infrastructure required for an ALCUE Unit depends on the purposes of the people who interact with the Unit. In order to indentify these purposes, meetings have been held with diverse groups of people who had interest in an ALCUE Unit. Furthermore, the Vertebralcue Project documentation and documents about the EPUSP academic cooperation was studied.

A Socio-technical System
e-Infrastructures are Socio-technical Systems. The technology in these Systems does not have a purpose by itself; this technology must meet the purpose of the people and institutions that interact with it. The difficulty in identifying the purpose of an ALCUE Unit can be seen by the description of the domain of the problematic situation.
The existence of a relationship between ALCUE Units and academic cooperation networks is evidence that there are different people's and institutions' interests in the System. This diversity of institutions and people, possibly with different cultures, makes it difficult to identify the specific System goals. Consequently, the identification of e-Infrastructure technological requirement is also made difficult.

Information center
The demand for an ALCUE Unit to be an Information Center is vague. As an Information Center, the Unit must both generate and disclose the information, and receive information and publish it. Nevertheless, before defining how the information will be received or generated, and how access will be provided to this information, it is necessary to identify what information is of interest to the people involved with the ALCUE Unit and what information is of interest to the academic cooperation networks. All this information has been identified by a Brainstorming session with the topic: "What subjects related to academic cooperation would you like to know?" The Brainstorming session identified the following subjects: (i) Equivalence of titles between higher education institutions; (ii) Graduate and Undergraduate courses offered by institutions, including information about the disciplines and curriculum; (iii) Training programs and continuous education programs offered by institutions; (iv) Distance Learning; (v) Scholarships and funding of studies and research in institutions; (vi) Qualifications of faculty and researchers; and (vii) Mobility and exchange between institutions for faculty, students and researchers.
This list was not definitive; it was a first sample of what a group of people with interest in an ALCUE Unit had thought to be relevant at that stage of the problem treatment. Figure 2 presents the Brainstorming diagram that was created during the session. Diagrams were used in the Brainstorming session to improve communication and association of ideas. Fig. 2. Brainstorming diagram.

The relationships
The information, generated or received by the ALCUE Unit, occurs within a context with several institutions that have interests in academic cooperation. In order to identify some institutions, the Nominal Group Technique was used with the subjects that were identified in the Brainstorming session as a starting point. The Nominal Group session resulted in Table 2, in which the first column shows the identified institutions; the second column indicates if the institution is a funding institution, a support foundation, an academic institution, or an international cooperation institution. The third column was not identified in that session; it was identified only in the workshop that followed that session, and presents the characteristic of each type of institution.
The list of the institutions indentified in the Nominal Group session was used in a workshop, which aimed to build an institution chart and identify the relationship and information flow between them. In that workshop, the Interpretative Structural Modeling was used, and the work group decided to group institutions according to their characteristics -the results of which are present in the third column in Table 3. Figure 3 presents the institutions relationship and the information flow that was identified in the workshop.

ALCUE Units Academic Cooperation
Support academic networks at various levels: regional, national and international. Table 3. Institutions with interests in academic cooperation.

Threats, opportunities, weaknesses and strengths
When the System Engineer deals with a problem such as the design of e-Infrastructure Systems to support the ALCUE Unit, he must not only be concerned about the needs to have the System operating according to the demands at the moment when he understands the problem domain. If the Engineer only considers these needs, the product of the design may be a System in which the changes and the evolutions required to meet new demands will be impossible. Therefore, to identify future scenarios for the ALCUE Unit, a situational analysis tool was used: the TOWS Matrix. This Matrix is a tool that allows the formulation of a strategy for the future by examining the present.
In a single workshop, the ALCUE Unit internal factors -Strengths and Weaknesses -and external factors -Threats and Opportunities -were identified and the relationship between them were established. Table 4 presents the result of this workshop: the TOWS Matrix.

Implicit systems
The Symptoms and Issue Factors imply the existence of Implicit Systems 1 in problematic situations. At this point in the RSM process, the needs of the ALCUE Unit that indicate the existence of Implicit Systems in the e-Infrastructure System are indentified.
Usually, skilled System Engineering can indentify Implicit Systems by the analysis and synthesis of the content in Figure 3, a rich picture -as in SSM -and the content in Table 4, the TOWS Matrix. The Implicit Systems identified by the authors are:  System to store information: all the information obtained or generated should be stored for later access;  System to support static disclosure: a system that allows access to information when people want it;  System to support dynamic disclosure: a system that sends information to people who are interested in receiving them;  System to support relationship networks: a system that allows the construction and operation of social and thematic networks;  System for obtaining 2 information from FUSP: a system that accesses an interface at FUSP to retrieve information;  System for obtaining information from FAPESP: a system that accesses an interface at FAPESP to retrieve information;  System for obtaining information from Private Companies: a system that accesses an interface at a Private Company to retrieve information. There may be a different system for each Company that wishes to disclose information;  System for obtaining information from FDTE: a system that accesses an interface at FDTE to retrieve information;  System for obtaining and sending information to CRInt-POLI: a system that accesses an interface at CRInt-POLI to send and retrieve information;  System for obtaining and sending information to CCInt: a system that accesses an interface at CCInt to send and retrieve information;  System for obtaining and sending information to other ALCUE Units: a system that accesses an interface at another ALCUE Unit to send and retrieve information. There may be a different system for each ALCUE Unit.

Containing systems
The authors have decided not to use any special technique of clustering to group the Implicit Systems in containing sets. Therefore, the Implicit Systems have been grouped together according to partners indentified in their own characteristics, in order to get sets of systems grouped by the symptoms of the ALCUE Unit e-Infrastructure. System for obtaining and sending information to CCInt;  System for obtaining and sending information to other ALCUE Units.
The systems identified represent a perspective about the problematic situation in an ideal world. This means that they do not necessarily have to be designed and implemented in the real world. Furthermore, it does not mean that they are the only systems in the problematic situation. During the following phases of the System life cycle, new symptoms may appear that were not determined in this phase of the method execution, which can lead to a redefinition of the issue or the emergence of new issues. The sequence of treatments for these symptoms follows the concept of the previously mentioned Evolutionary Spiral.

Interactions and imbalances of containing systems
The interactions between Containing Systems always occur when there is an information related demand. These interactions are represented in Figure 4, in which the arrow indicates the direction in which information is being sent.
Following the concept of the Evolutionary Spiral (Fig. 1), a new workshop was held with the aim of assessing the interactions identified in reality dimension. At that meeting, it was identified:  The Disclosure Support System contains the Implicit System that supports relationship networks, and this Implicit System also generates information to be stored.


Two distinct Containing Systems -Information Gathering System and Information Gathering/Dispatch System -have Implicit Systems with the same characteristic: obtaining information in as institution. This scenario indicates a duplication of systems, even if the institutions are of different types, as identified in Table 2. Fig. 4. Containing Systems Interaction.

Treatment for Imbalance and impact of the proposal
The new symptoms, identified in the workshop commented above, were considered in a new proposal for the Containing Systems, in which the Information Gathering System was merged with the Information Gathering/Dispatch System. The proposal also considered the symptom that the Disclosure Support System demands interactions with the Storage System, generating information that should also be accessed later by the system. This new scenario is depicted in Figure 5, where the arrows indicate the direction in which information is being sent.

Proposal impact
Store and make available information generated by social networks organized by the ALCUE Unit does not affect the Storage Containing System. Store information already was its original function.
The merge of the Containing Systems that was implemented may cause internal systems imbalances at the resulting system, because the different institutions with which the Implicit Systems are connected may demand different connection properties. However, in this phase of the System life cycle, it is too early to determine clearly this dependence scenario of connection, and "how" these connections with the different institutions will be held.
The purpose duplication of distinct systems was resolved.

Potential solution
The e-Infrastructure systems that KNOMA wishes to develop and maintain to support the ALCUE Unit activities is composed of three Containing Systems, which interact between themselves always that information is demanded or disclosed. The interaction between these systems is shown in Figure 5, in which arrows indicate the direction in which information is being sent.

Contribution to next phases of project life cycle
The process of RSM identified the symptoms and treatments of the issue on to develop and maintain an e-Infrastructure for ALCUE Unit. RSM has been chosen because according to the perspective presented earlier, it is the consensual method that provides more information for the phases that follows the requirement elicitation phase. Table 5 presents the contributions that the application of RSM brings to the phases of System Engineering life cycle model proposed by Kossiakoff and Sweet (2003).

Conclusion
This chapter addressed the use of Consensual Methods to assist the authors in the process of understanding a problematic situation: Design an e-Infrastructure to be used by KNOMA ALCUE Unit of VertebrALCUE Project, from ALFA III Program. According to the perspective adopted, the use of RSM provides information to all the phases of Project life cycle and was adopted. The meetings organized by the authors enabled the engagement of people with interest in the ALCUE Unit development, reduce the people dissatisfactions about the requirement elicitation process and respect the human and social dimensions. This scenario allows the development of a e-Infrastructure that minimized the difference between what is expected and what will be verified in reality. The authors decisions about the development of a TOWS Matrix was supported by VertebrALCUE Project board, which after evaluating the results obtained, demanded to all ALCUE Units the development of a TOWS Matrix.

Acknowledgments
The research and scholarships are partially funded by the Vertebralcue Project (http://www.vertebralcue.org). An ALFA III Program Project that aims to contribute to the www.intechopen.com development process of the regional integration among Latin American Higher Education Systems (HES´s), and the implementing process of the Common Area of Higher Education between Latin America, the Caribbean and the European Union (ALCUE in Spanish), by exploring and strengthening different levels of articulation of Latin America-Latin America and EU-Latin America academic cooperation through the design and implementation of a cooperation infrastructure at institutional, national and regional level.