1st International Workshop on Hypermedia Development

Held in conjunction with Hypertext'98

  Building a Web-based Information System applying the Hypermedia Flexible Process Modeling Strategy

Luis OLSINA Faculty of Engineering, at Universidad Nacional de La Pampa, also at Ciencias Exactas, Universidad Nacional de La Plata Calle 9 esq. 110, (6360) G. Pico, La Pampa, Argentina E-mail olsinal@ing.unlpam.edu.ar

ABSTRACT

Despite the growing and renewed interest in the wide community of researchers and developers about Web-based Information Systems, hypermedia application developments still lack very documented lifecycles and process modeling mechanisms. This work provides a way to face aspects of the overall development process of an application pertaining to the Web-based hypermedia problem domain. In this purpose, we apply the Hypermedia Flexible Process Modeling strategy, that is, a broader engineering-based software approach that includes expression and analysis-oriented descriptive and prescriptive process modeling strategies. This work is ongoing both in the definition of some views´ components and in the development of an on-line guidance-oriented hypermedia process environment.

 KEYWORDS: Hypermedia, Strategy, Process Modeling, Prescriptive, Descriptive.

1. INTRODUCTION

This position paper provides a proposal of how to face aspects of the overall development process of an Academic Information System (AIS) applying the Hypermedia Flexible Process Modeling (HFPM) strategy. This is a broader engineering-based software approach that includes expression and analysis-oriented descriptive and prescriptive process modeling strategies [3, 7, 18].

On the one hand, we try to answer the question, how should hypermedia software be developed? To deal with the inherent complexity of hypermedia processes we have prescribed a set of views that represent key concepts such as task, artifact, resource, agent, role, process constructor and condition among others [13]. Our taxonomy embraces functional, methodological, informational, behavioral, and organizational views or perspectives. In this way, we globally propose to undertake the AIS project by means of:

1. Prescribing a set of phases and tasks (with regard to the functional view);
2. Applying a set of specific process constructors (e.g., OOHDM-based conceptual and navigational modeling method [16], use-case modeling method, prototyping strategy [11], etc., regarding the methodological view);
3. Planning to produce a set of artifacts (e.g., a plan model, a conceptual model, a navigational model, physical models, etc., regarding the informational view);
4. Considering aspects such as iterations, increments, parallelisms (as part of the behavioral view), and;
5. Taking into account issues such as agents' roles and skills, team organization, communication mechanisms, and other resources (regarding the organizational view).

On the other hand, we should consider the question, how is hypermedia software actually developed? This could allow us to control and improve hypermedia projects. One of the main goals in developing hypermedia applications is to produce artifacts of planned quality, which should be governed by a set of desired and measurable attributes, using for such an end the most effective processes and the most appropriate resources. We will present a reduced list of measurable attributes and exemplify the potentiality of improvements in the AIS project, by means of Goal-Question-Metric (GQM) approach [1].

The HFPM strategy potentially allows us to understand, to communicate, to control, and to improve those issues in hypermedia projects. Therefore, in the following section we discuss aspects of the overall development process to be applied to the sample problem (called Academic Department and proposed by workshop organizer). Next, we present mechanisms for prescriptive and descriptive process modeling customized to the hypermedia domain. Finally, we consider some concluding remarks.

2. ASPECTS OF THE DEVELOPMENT PROCESS TO SOLVE THE AIS PROBLEM

Despite the fact that the basically used strategy to develop hypermedia applications has been rather ad hoc, our proposal is to employ an engineering-based strategy in order to solve the AIS sample problem. One core objective of the HFPM proposal is to prescribe a set of views as previously stated, and with regard to the functional view, to prescribe a set of tasks for the different phases, with the purpose of supporting communication among participants, planning, and project managing. In Section 3 we will concentrate on specific aspect of HFPM and, in the following paragraph, we will focus on necessary tasks to solve this problem as well as on methodological and informational issues. Next, and concentrating on a medium-level of granularity, we show a prescribed list of task, namely:

• Software Requirement Modeling (this implies subtasks such as Initial Survey, Use-case Modeling, Glossary Modeling, Interface Modeling, Non-functional Requirement Modeling -e.g. performance, navigability, reusability, etc.)
• Project Planning (this implies, Analyze Project Plan, Specify Project Plan)
• Conceptual Modeling (this implies, Analyze Problem Domain, and Specify Domain Models -for instance, figure 1 represents an artifact that is the output of these sub-tasks)
• Navigational Modeling (this implies, Analyze Intended Users' Tasks, Identify Navigational Classes, Specify Navigational Classes and Schema, Analyze Navigational Transformations, and Specify Navigational Transformations -for instance, figures 2 and 3 show artifacts that are outputs of some of these sub-tasks)
• Abstract Interfaces Modeling (this implies, Analyze User Interface Models, Analyze and Specify Interface Perceptible Objects, Events and Transformations)
• Design Patterns Employment (this implies, Navigational Patterns Employment, User Interface Patterns Employment, Architectural Patterns Employment -for instance, design patterns [14] such as "Navigational Context", "Node as a Single Unit", "Page Creation Method", "Information-Interaction Decoupling", and "Behavioral Grouping" should be considered in the AIS problem).
• Multimedia Data Capturing and Editing
• Physical Modeling/Integration (these imply, Component Employment, Rapid-Functional Prototyping, Evolutionary Prototyping, Sketching -or Storyboarding-, and Component Integration)
• Validation/Verification
• Cognitive Criteria Employment (this implies, Coherence Criteria Employment, Orientation Criteria Employment, Navigation Criteria Employment [17])
• Quality Assurance (this implies, Analyze Quality and Improvement Strategies, Specify Quality Plan)
• Project Coordination and Management (in general, this implies Manage and Control Processes, Artifacts, and Resources)
• Documentation (this implies the set of tasks in order to document logical and physical models, evaluation, and tests among other issues)

As observed in this prescribed list there are technical, managerial, cognitive, and participatory tasks; this list is not intended to be extensive but rather to represent a potential set of necessary tasks for this kind of projects. Given the nature of the problem and, for the sake of conciseness, we will concentrate on a couple of these tasks, i.e. on Software Requirement task, and mainly on Conceptual, and Navigational Modeling tasks.

On the one hand, prior to beginning the development phase, we should highlight initial insight about the AIS problem and its alternative solutions. We have some initially-given user requirement specification to the problem to be solved (written in narrative natural language). For instance, we can observe that the final Web-site should take into account different user types, which imply different user information (and navigation) needs. The narrative says "the site has three main types of intended users: academic personnel, mainly professors and researchers from other institutions, current and prospective students, and research sponsors". We can use here some established methods so we can determine a set of action sequences that define the way in which different actors interact with the system, and thus build use cases. We can also develop a glossary model as a means to capture essential problem domain keywords. These keywords and their related concepts could be specified in a classified list, being an important technique to communicate key concepts in early stages between practitioners. From these specifications, we can later feed logical and physical models so that we can extract information of how users perform their tasks and we can recognize packages, user profiles, classes, relationships, nodes, navigational contexts, and other building primitives.

On the other hand, we should also consider the need of constructing a project plan from the initial survey task. This plan model should basically contain: descriptions of the goals and objectives of the site to be built; the intervening tasks; the scope of the intermediate and final products; developers and users involved throughout the project and their responsibilities; the selection of the working environment and tools; the developing and reuse strategies to be applied, and also the possibility to establish a quality plan, metrics, and improvement strategies. Figure 1 Conceptual Model Diagram for the Academic Information System.

Regarding the conceptual modeling task we propose to build a shared conceptual model from which three different navigational perspectives will be derived taking into account the three different user types; e.g. visitant researchers and professors, current and prospective students, and research sponsors. Figure 1 depicts the shared conceptual model diagram to the AIS sample problem. We are using an adaptation of the UML notation where attributes can be multi-typed (like "Location" in "Academic Entity" class) and diagrams emphasize the structure and relationships rather than behavior. The above diagram represents an artifact that is the output of the conceptual modeling task and is built by an extended OOHDM process constructor. The main goal of this task is to analyze and to specify the semantics of the problem domain. Other hypermedia process constructors may be used to the same description task, namely: RMM [6] or HDM [5]; however, we advocate the use of O-O primitives because well-known software engineering mechanisms such as generalization/specialization, aggregation and classification are embraced.

For the AIS sample problem we have found domain classes like "Academic Entity", "Department", "Student", "Equipment", "Sponsor", and packages (subsystems) like "Course", "Degree", "Personnel", "Laboratory", etc. and relationships like "has", "pertain", "teach" among others. Relationships in the figure express relations among classes intended to be navigated by generic final users, and will be translated into links in the navigational schema. We could also represent each package in separate diagram elicited from the given narrative specification (for instance, the "Course" subsystem that is not shown here), or from other sources. Finally, as observed elsewhere [15, 16] only the domain semantics are considered in this task not taking into account issues such as intended user tasks or profiles.

Although we have represented domain classes to the AIS problem into the conceptual model, this may be rather abstract in terms of user profiles, so we need a lower level of logical models. During the navigational modeling task the architects and developers work to design, to structure, and to specify navigational spaces in order to have a hypermedia application that considers a set of intended user profiles. Typical OOHDM classes or process constructors defined to this task are Node, Link, Anchor, Navigational Contexts, and Access Structures (like Index and Guided Tour). In figure 2 the reader may appreciate some specified navigational classes to the AIS problem using the card formalism [15] (these cards could take into account backward and forward traceability issues that potentially could improve reuse and maintenance tasks). Figure 2 Navigational classes specified with cards; the a) and b) cards represent two Node classes derived on conceptual model; the c) card represents an Access Structure class, and the d) card represents a Link class.

For instance, in figure 2, the two cards a) and b) represent two Node classes derived from the same-named classes of the conceptual model (see figure 1). Nodes are in general the basic information repositories in hypermedia applications. The attributes of a Node class derived from a domain class must be single typed; e.g., the "Location" attribute in the "Department" node is defined as "Image" type. If the designer wish to show the same attribute with the "String" type another node card should be specified.

As previously stated, we should consider a set of intended user profiles; this is, visitant researchers and professors, current and prospective students, and research sponsors. In this way, it should be noted that figures 2 and 3 are taking into account only the students' point of view. So that, to complete the specification task we should specify three navigational perspectives according to the three intended users profiles. For instance, from the research sponsor's view regarding the "Department" node card -figure 2a-, we should consider attributes such as "Name", "Location", "Comment", "Equipment", "Professors", and "R&D Projects". Attribute "Students" may be of little or no importance to this user profile. The reader should also keep in mind that nodes may be formed out as a combination of attributes form different domain classes or from part of a class and can also add access structures (such as index, guided tour) resulting so in a composite node. Finally, in figure 3, we depict a simplified navigational schema from the student's point of view. That gives us a snapshot of the classes to be navigated. Alternative navigational schema could be arranged according to the user interest. Figure 3 Simplified Navigational Schema from the Student's point of view

Ultimately, and considering the behavioral view, the proposed hypermedia development process (and any software process in general) proceeds on several directions respecting some partial order. A process model strategy gives us guidelines to help in making better choices in the development process at any time, but it should not prescribe rigid rules that will be valid for all circumstances. However, building hypermedia artifacts by the systematic, disciplined, and quantifiable utilization of a hypermedia process model is good enough [8, 10].

The customized hypermedia process, when instantiated and executed, is carried out in a mix of iterative, parallel and opportunistic style allowing the partitioning of a problem into sub-problems so as to attack incrementally portions of less complexity. This strategy could be use to solve the different issues of the overall lifecycle of the AIS problem. On the one hand, the iterative behavior is by definition the key of the flexible prototyping cycle: to iterate means that certain sub-tasks will be carried out more than once to reach models improvement. By each prototyping-demonstration-validation cycle the physical models are shown to users in order to discover additional requirements, to define architectural aspects, and to validate the usability of the prototype. We also say that the development process is incremental: this means that, by each iteration, there will be generic increments of the requirement, conceptual, navigational and abstract interface models as well as of the physical models. With each cycle the prototype will be refined and increased and after n iterations along the project, the requirements will be complete and the products will be in the operational phase.

On the other hand, this strategy also allows parallel activities between logical and physical models. In each cycle we can work in the prototype and update the specifications. Furthermore, at any moment there could exist parallelisms between navigational design sub-tasks and abstract interface design sub-tasks, and it is possible to work concurrently in rapid-functional prototypes while an evolutionary prototype is beginning to be enhanced. So, the parallelism is a consequence of the no secuentiality between certain tasks, of the problem partitioning strategy, and of the evolutionary approach. Finally, the opportunistic behavior is such that, as long as the developers are engaged in prototyping and specification tasks, they follow an order dictated neither by formalisms nor by rules, but rather by following a creative mental process, as is rightly observed by Nanard [9]. It is common that a hypermedia developer passes from prototyping an interface node to specifying a recently discovered navigational context (opportunistically). Then it starts to sketch it and next it goes to work in a RFP, and so on.

3. ISSUES IN PRESCRIPTIVE AND DESCRIPTIVE PROCESS MODELING APPROACHES

As stated in the Introduction Section, the HFPM is a broader engineering-based software strategy that embraces expression and analysis-oriented descriptive and prescriptive process modeling approaches. So we see the task of designing a process model as a two-dimensional workspace, i.e. observing and studying existing hypermedia development processes, and abstracting and prescribing desired processes and models. These activities evolve into feedback loops among those spaces feeding and enhancing the target approach (i. e. the HFPM approach). To explain generally this relationship between spaces and domains it will be good to write down some concepts and terminology used by Lonchamps [7]. "People dealing with software processes may adopt two different attitudes of mind:

Descriptive: they study existing processes to answer the question "how software is (or has been) actually developed?"

Prescriptive: they define desired processes to answer the question "how software should be developed?"..."

In order to describe processes in prescriptive and descriptive attitudes people can aim at:

"Expressing: the actual or desired process is just described more or less formally for understanding, communication, education, reuse, or standardization.

Analyzing: the description of the actual or desired process is studied through more or less formal techniques (such as validation, e.g. simulation, or property verification) for a deeper understanding, comparisons, improvement, impact analysis, or forecasting. "

In the following two sub-sections we will deepen some questions about prescriptive and descriptive process modeling approaches useful to take into account in the development of the AIS problem.

3.1 Functional View of the HFPM: an example of prescribed Task. Even if we have prescribed five views in HFPM (e.g. functional, methodological, informational, behavioral, and organizational views) we will solely discuss aspects of the functional view, and with regard to the "Task" class we have previously listed tasks essentially to the development phase. A phase is a grouping of strongly related tasks performed in certain order. There are three cohesive phases in the HFPM; these phases can be observed generally as common denominator of all defined software lifecycles, independently of the application type and of the size of the project. These are, namely: the definition phase (called exploration phase in our model), the development phase, and the maintenance phase (called operational phase in our model).

The exploration phase is wherein initial concepts and users' needs are elicited; next, if necessary, it is possible to perform a feasibility study and, then, we can preliminarily plan the hypermedia project.

The development phase is the core of the dynamic modeling. It is the essential phase for re-planning, eliciting and specifying final requirements, controlling, analyzing, designing, authoring, validating, integrating, quality assuring and documenting tasks.

The operational phase consists essentially of documentation, distribution, configuration and change management, artifact maintenance, and products evolution tasks.

The nature of hypermedia applications is characterized by interface-interaction-navigation behavior and by cognitive and aesthetic attributes, which affect the way we analyze, abstract, and perform hypermedia processes. Regarding the communication, standardization, and planning issues we have broken down the "Task" class into abstract subclasses. The quality of the produced artifacts relies on the quality of the used tasks. The interpretation of quality as in conformance with standard processes, has resulted in prescribed task templates, style guides, etc. To exemplify this, we present a static template for one task (see [13] for a broader work), representing the main goal, super-tasks, sub-tasks, inputs and outputs, and also some additional comments about methodological and informational aspects and concepts if necessary. This textual script does not comprise behavioral aspects among tasks such as iterations, increments, and parallelisms (that is part of the behavioral view), and also do not deal with aspects of agents' roles and skills, and detailed actions.

Figure 4 shows a template to prescribe the Navigational Modeling task. This essentially could improve the communication among practitioners (and can also be part of a guidance-oriented hypermedia process environment -that we are currently developing).

Task Class: Navigational Modeling

Goal: to design, to structure and to specify navigational spaces in order to have a hypermedia application that considers a set of intended user profiles

Super-tasks: Design Modeling, Domain Modeling

Subtasks: Analyze Intended Users' Tasks, Identify Navigational Classes, Specify Navigational Classes and Schema, Analyze Navigational Transformations, and Specify Navigational Transformations

Inputs: Use-Case Model, and Interface Model (from Software Requirement Specification), Architectural Design Specification, Conceptual Model, Physical Models, User and Task Analysis Model, Navigational Patterns Catalog

Outputs: Static and Dynamic Navigational Models

Input Criteria: To be in the Development Phase

Output Criteria: Documented Navigational Models

Comments: 1) The navigational context is a way to organize the navigation in an implementation-independent manner. It is a design pattern that is composed of nodes, links and other navigational contexts (maybe nested). This constructor allows to represent a coherent unit of related concepts and to establish appropriate semantic relationships fostering user orientation.

2) HDM model, and OOHDM, RMM and EORM methods offer process constructors supporting this task in a somewhat degree.

Figure 4. A template or script to specify the Navigational Modeling task

Ultimately, it is important to keep in mind that standards can provide a structure and guide to produce artifacts of quality but they do not guarantee the results by themselves. Quality processes combined with quality resources and process constructors, lead toward results of quality with higher probability.

3.2 Improvement and Control Mechanism for Processes, Artifacts, and Resources We argue that all development process in the context of an organization should continually take care of three essential objectives: to produce artifacts of quality, to use effective processes, and to assign appropriate resources. To do this, we should select a balanced mixture of observable characteristics that could contribute to the quality of entities. From the point of view of the evaluation, control, and improvement of processes, artifacts and resources, it is necessary to perform measurements on these characteristics. The interpretation and analysis of the gathered data can be used to evaluate, to feedback, to predict and to improve actual or desired entities.

Table 1 shows a reduced set of these observable characteristics [4] that derive in measurable attributes -or potentially measurable in some cases-, given the novelty of the hypermedia area.

Unfortunately, there is very few metrics investigated in the hypermedia so far. For instance, ones of the most formalized are contained in Botafogo et al. [2] where structural metric regarding hypermedia graphs complexity is dealt with. Other existent metrics lack enough experience to be fairly interpreted so to be effective.   Table 1 Reduced set of observable characteristics of the Artifact, Process, and Resource entities  

In the following paragraphs we will exemplify the discussed above using a mechanism to select metrics in function of goals and objectives. We can use GQM approach or a more specific mechanism such as Quality Template. Regarding the GQM approach we can define and plan desired situations so that, by means of the gathering of data, allow us further evaluation, control, and essentially improvements of processes, artifacts, and resources.

  Table 2 Template to register Goals, Questions, Metrics, and Comments  

We argue that the instantiated hypermedia development process is completed if we define some specific characteristic or attributes, as non-functional requirements (in the Software Requirement Modeling task), that represent units of concrete measure to observe and interpret. Given a selected set of goals to the AIS project in the context of an organization (and keeping in mind some characteristics selected from the table), a set of questions can be built and refined for each goal and, depending on each question the appropriate metrics can be chosen. The results of interpretations can be good enough to analyze, predict, understand, and improve processes, products, and resources (in this way primly feeding the descriptive modeling domains).

To show the employment of this approach and considering the AIS problem, let us suppose that the goal is "to improve the navigability of the site (or hyperdocument) from the student's point of view"; then, questions can be formulated and from these, metrics can be refined. Table 2 presents a similar template that utilized in [1] to capture this information.

Finally, a central issue in GQM approach is the interpretation of the captured data depending on the questions from which these measures were derived. For example, to the resulting navigational graph of the figure 3 and regarding the M111 metric one can interpret it as a value of node interconnectedness complexity. From the student's point of view a very high interconnectedness will indicate that each node has many starting points and connections to other nodes. This can act against the product quality (in the navigability attribute) by potentially allowing at the same time the choice of diverse destinations being able to cause user disorientation. In a completely interconnected hyperdocument the user doesn't have a structured path to complete a concept distributed in several nodes. The opposite case is also generally an indication of wrong design.

4. CONCLUDING REMARKS

Despite the growing and renewed interest in the Web-based hypermedia applications, very documented lifecycles and process modeling mechanisms are still missing. Since the early 90's, one of the major well-known breakthroughs has been the emerged methods and models such as HDM, RMM, EORM, and OOHDM. Even if an underlying hypermedia development process is recognized (mainly in RMM, EORM, and OOHDM), they rather focus on design and construction issues not dealing with early lifecycle or maintenance tasks, and not recognizing a clear division of concerns in views as we propose.

Therefore, we have a strong need for a wider engineering-based software approach. In this direction, the hypermedia research community has observed the necessity of having a disciplined, quantifiable, and systematic employment of software engineering principles and mechanisms to deal with hypermedia artifact development processes [8, 10, 12, among others]; so this subject area could be seen almost a new research concern. (In fact, this event will be the 1^st Workshop on Hypermedia Development Processes besides Methods and Models; as well other closely related workshops were recently held at ICSE 98 and WWW7).

Regarding the AIS problem and trying to answer the first settled question we have proposed a set of views (derived from key entities on the conceptual model [13]). They convey information about tasks, artifacts, resources, agents, roles, and process constructors. Our HFPM´ views classification embraces functional, methodological, informational, behavioral, and organizational perspectives. With regard to the functional view we can state the following:

1. it covers all the essential phases and activities of a hypermedia project;
2. this clear break down produces greater visibility that, ultimately, contributes to project planning and scheduling, and helps to establish milestones and metrics;
3. it considers a balanced use of logical and physical modeling, and;
4. it promotes human understanding and communication.

With regard to the HFPM methodological view, we have placed and integrated different methods to carry out different tasks. For instance, we have specified and produced artifacts of the Conceptual and Navigational Modeling tasks using OOHDM constructors (figures 1, 2, and 3).

On the other hand, and taking into account the second question, we have stated that one of the main goals in developing hypermedia applications is to provide mechanisms that allow evaluation, analysis, control, and improvement in hypermedia projects. In this way, we have presented a reduced list of measurable attributes and exemplified the potentiality of evaluations and improvements by means of GQM approach (tables 1 and 2). We have not shown aspects of an integrated framework whereby expression and analysis-oriented descriptive and prescriptive process modeling strategies can work. However, we have aimed at answering the questions of how software is (or has been) actually developed (the descriptive process modeling strategy side), and how hypermedia software should be developed (the prescriptive process modeling strategy side).

ACKNOWLEDGMENT

This research is conducted as part of the author's Ph.D studies under the valuable guide of Dr. G. Rossi. MS Luis Olsina is partially supported by the "Programa de Incentivos, Ministerio de Cultura y Educación de la Nación, Argentina". This work has also been partially supported by "SeCyT, Fac. de Ingeniería, UNLPam", and "Centro Regional de Educación Tecnológica, G. Pico, La Pampa, Argentina"

REFERENCES

1. Basili, V.R., Caldiera, C., Rombach, H.D., 1994, "Goal Question Metric Paradigm", Encyclopedia of Software Engineering, Vol. 1, John Wiley & Sons, pp. 528­532.

2. Botafogo, R. Rivlin, E., Shneiderman, B., 1992, "Structural Analysis of Hypertexts: Identifying Hierarchies and Useful Metrics, ACM Transactions on Office Information Systems, 10(2), pp. 142-180.

3. Curtis, B.; Kellner, M.; Over, J., 1992, "Process Modelling", Comm. ACM 35, 9; pp. 75-90.

4. Fenton, N.E.; Pfleeger, S.L., 1997, "Software Metrics: a Rigorous and Practical Approach", 2^nd Ed.

5. Garzotto, F.; Schwabe, D.; Paolini, P., 1993, "HDM, a model based approach to Hypermedia Application Design ", ACM Transaction on Information System, Vol. 11, 1, pp. 1-26.

6. Isakowitz,T.; Stohr, E.; Balasubramanian, P., 1995, "RMM: a methodology for structured hypermedia design", Comm. ACM 38, 8; pp. 34-48.

7. Lonchamps, J., 1993, "A Structured Conceptual and Terminological Framework for Software Process Engineering ", ICSP 2, Berlin, IEEE Press.

8. Lowe, D.; Ginige A., 1997, "Hypermedia Engineering: Processes for developing large Hypermedia systems", Tutorial, Hypertext 97, Southampton, England.

9. Nanard, J.; Nanard, M., 1995, "Hypertext Design Environment and the Hypertext Design Process", Comm. ACM 38, 8 (Aug 95) pp. 49-56

10. Olsina, L., 1997, "Systematic use of Flexible Process Model to build Hypermedia Artifacts". Poster Session, Hypertext 97, Southampton, England

11. Olsina, L., 1997, "Object-Oriented Flexible Prototyping to support Hypermedia Flexible Process Model". III Workshop em Sistemas Multimídia e Hipermídia (WoMH 97), pp. 3-14, Sao Carlos, Br.

12. Olsina, L., 1997, "Applying the Flexible Process Model to build Hypermedia Products", Hypertext and Hypermedia: Products, Tools, Methods (H2PTM´97), V. 1, pp. 211,221, Hermes Editorial, Paris, Fr.

13. Olsina, L., 1998, "Functional View of the Hypermedia Process Model, Fifth International Workshop on Engineering Hypertext Functionality at ICSE´98, Kyoto, Japan. (The papers are referenced by http://www.ics.uci.edu/~kanderso/htf5/papers/)

14. Rossi, G.; Garrido, A; Schwabe, D.; 1997, "Using Object-Oriented Models and Patterns in the WWW", Workshop on Software Engineering on the WWW, International Conference on SE, Boston, US.

15. Schwabe, D.; Rossi, G., 1995, "Building Hypermedia Applications as Navigational Views of Information Models", Proceedings of the Hawaii International Conference on System Sciences, Hawaii.

16. Schwabe, D.; Rossi, G., 1995, "The Object-Oriented Hypermedia Design Model", Comm. ACM 38,8.

17. Thüring, M.; Hannemann, J.; Haake, J., 1995, "Hypermedia and Cognition: Designing for Comprehension", Comm. ACM 38, 8; pp. 57-66.

18. Verlage, M; Webby, R; et. al., 1998, "The Spearmint Approach to Process Definition and Process Guidance", Workshop on Software Engineering over the Internet at ICSE´98, Kyoto, Japan. (The papers are referenced by http://sern.cpsc.ucalgary.ca/~maurer/ICSE98WS/ICSE98WS.html)

VITAE
 

Luis Olsina is a full professor in the Computer Department at Universidad Nacional de La Pampa, and head of the Software Engineering R&D group (GIDIS). He is working on hypermedia development lifecycle, particularly on the study of prescriptive and descriptive process modeling strategies, and is currently designing a guided-oriented hypermedia process environment (GOHyPEr project). He has also active interests in multimedia and O-O area mainly on the new approaches, techniques, and tools of the O-O technology for the Internet. He is a member of the IEEE Computer Society. He has also experience in IS and WIS consulting and training outside the Faculty.