<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
<title>Volumen 05 | Número 02</title>
<link href="http://sedici.unlp.edu.ar:80/handle/10915/388" rel="alternate"/>
<subtitle/>
<id>http://sedici.unlp.edu.ar:80/handle/10915/388</id>
<updated>2026-08-14T11:51:06Z</updated>
<dc:date>2026-08-14T11:51:06Z</dc:date>
<entry>
<title>The role of requirements engineering in the development of multi-agent systems</title>
<link href="http://sedici.unlp.edu.ar:80/handle/10915/9581" rel="alternate"/>
<author>
<name>Prado Leite, Julio César Sampaio do</name>
</author>
<id>http://sedici.unlp.edu.ar:80/handle/10915/9581</id>
<updated>2019-06-19T04:03:17Z</updated>
<published>2005-08-01T00:00:00Z</published>
<summary type="text">Articulo
Journal of Computer Science &amp; Technology; vol. 5, no. 2
There has been an increasing number of literature dealing with the software engineering aspect of building “agent oriented software”. In principle, agent oriented software is software implemented in platforms in which software pieces behave with a certain level of independence from other software pieces. An important characteristic of agent oriented software is the level of intelligence available for each software piece, or agent.&#13;
&#13;
&lt;i&gt;(Párrafo extraído del texto a modo de resumen)&lt;/i&gt;
</summary>
<dc:date>2005-08-01T00:00:00Z</dc:date>
<dc:description>There has been an increasing number of literature dealing with the software engineering aspect of building “agent oriented software”. In principle, agent oriented software is software implemented in platforms in which software pieces behave with a certain level of independence from other software pieces. An important characteristic of agent oriented software is the level of intelligence available for each software piece, or agent.&#13;
&#13;
&lt;i&gt;(Párrafo extraído del texto a modo de resumen)&lt;/i&gt;</dc:description>
</entry>
<entry>
<title>Requirements engineering-challenges from the agent-oriented approach</title>
<link href="http://sedici.unlp.edu.ar:80/handle/10915/9580" rel="alternate"/>
<author>
<name>Cysneiros, Luiz Marcio</name>
</author>
<id>http://sedici.unlp.edu.ar:80/handle/10915/9580</id>
<updated>2019-06-19T04:03:16Z</updated>
<published>2005-08-01T00:00:00Z</published>
<summary type="text">Articulo
Journal of Computer Science &amp; Technology; vol. 5, no. 2
Many methodologies have been proposed to systematize the software development process. Many of them have been widely adopted. However, the majority has focused on analysis and design. Requirements have frequently been forgotten or only superficially dealt with. In, fact in the past we have seen methodologies evolving from programming. That happened when structured analysis evolved from structured programming and more recently with Object-oriented analysis evolving from object-oriented programming.&#13;
&#13;
&lt;i&gt;(Párrafo extraído del texto a modo de resumen)&lt;/i&gt;
</summary>
<dc:date>2005-08-01T00:00:00Z</dc:date>
<dc:description>Many methodologies have been proposed to systematize the software development process. Many of them have been widely adopted. However, the majority has focused on analysis and design. Requirements have frequently been forgotten or only superficially dealt with. In, fact in the past we have seen methodologies evolving from programming. That happened when structured analysis evolved from structured programming and more recently with Object-oriented analysis evolving from object-oriented programming.&#13;
&#13;
&lt;i&gt;(Párrafo extraído del texto a modo de resumen)&lt;/i&gt;</dc:description>
</entry>
<entry>
<title>Requirement and analysis: where is the boundary if any?</title>
<link href="http://sedici.unlp.edu.ar:80/handle/10915/9579" rel="alternate"/>
<author>
<name>Pastor López, Oscar</name>
</author>
<id>http://sedici.unlp.edu.ar:80/handle/10915/9579</id>
<updated>2019-06-19T04:03:16Z</updated>
<published>2005-08-01T00:00:00Z</published>
<summary type="text">Articulo
Journal of Computer Science &amp; Technology; vol. 5, no. 2
Even if it seems to be at a first glance a simple question, this is really a very interesting one. For many years, Analysis has been the generic term to refer to those initial Software Production Process steps where design is not yet taken into account. In some way, the analysis phase has been considered as the natural step where Conceptual Schemas of an Information System are conceived and represented.&#13;
&#13;
&lt;i&gt;(Párrafo extraído del texto a modo de resumen)&lt;/i&gt;
</summary>
<dc:date>2005-08-01T00:00:00Z</dc:date>
<dc:description>Even if it seems to be at a first glance a simple question, this is really a very interesting one. For many years, Analysis has been the generic term to refer to those initial Software Production Process steps where design is not yet taken into account. In some way, the analysis phase has been considered as the natural step where Conceptual Schemas of an Information System are conceived and represented.&#13;
&#13;
&lt;i&gt;(Párrafo extraído del texto a modo de resumen)&lt;/i&gt;</dc:description>
</entry>
<entry>
<title>Requirements and analysis: where is the boundary if any?</title>
<link href="http://sedici.unlp.edu.ar:80/handle/10915/9578" rel="alternate"/>
<author>
<name>Oliveros, Alejandro</name>
</author>
<id>http://sedici.unlp.edu.ar:80/handle/10915/9578</id>
<updated>2019-06-19T04:03:14Z</updated>
<published>2005-08-01T00:00:00Z</published>
<summary type="text">Articulo
Journal of Computer Science &amp; Technology; vol. 5, no. 2
The concept of System Analysis was very common in the early stages of information systems. Different approaches to System Analysis share the goal of learning about the current system to establish the basis of the new system (Swanson, R., &lt;i&gt;An introduction to Business Data Processing and Computer Programming&lt;/i&gt;, 1967). These approaches drove the development of software systems through a long period of time. The vision of the systems was driven by the goals and needs of understanding the functional side of the systems.&#13;
&#13;
&lt;i&gt;(Párrafo extraído del texto a modo de resumen)&lt;/i&gt;
</summary>
<dc:date>2005-08-01T00:00:00Z</dc:date>
<dc:description>The concept of System Analysis was very common in the early stages of information systems. Different approaches to System Analysis share the goal of learning about the current system to establish the basis of the new system (Swanson, R., &lt;i&gt;An introduction to Business Data Processing and Computer Programming&lt;/i&gt;, 1967). These approaches drove the development of software systems through a long period of time. The vision of the systems was driven by the goals and needs of understanding the functional side of the systems.&#13;
&#13;
&lt;i&gt;(Párrafo extraído del texto a modo de resumen)&lt;/i&gt;</dc:description>
</entry>
<entry>
<title>Understanding the word "analysis" in the context of requirements engineering</title>
<link href="http://sedici.unlp.edu.ar:80/handle/10915/9577" rel="alternate"/>
<author>
<name>Prado Leite, Julio César Sampaio do</name>
</author>
<id>http://sedici.unlp.edu.ar:80/handle/10915/9577</id>
<updated>2019-06-19T04:03:13Z</updated>
<published>2005-08-01T00:00:00Z</published>
<summary type="text">Articulo
Journal of Computer Science &amp; Technology; vol. 5, no. 2
I have been teaching, in reality, preaching, the importance of a clear understanding for the word “analysis”. It is my conclusion, after years of exposure to the term “system analysis”, that it has mislead lots of young people how wishes to understand the process of software construction, in special the initial steps of the process. My main point is that you can only analyze something that you know. However, educators in the areas of information systems and software engineering always focused the “system analysis” as a modeling discipline, where specifications were written and formalization was sought at the very early stages of conceptions of a system. Based on this bias on modeling, analysis was a way of enforcing syntax rules of a given modeling language, which provide ways of applying verification protocols. As such, not enough emphasis was directed to the goal of really understanding the concepts involved and the needs of the clients.&#13;
&#13;
&lt;i&gt;(Párrafo extraído del texto a modo de resumen)&lt;/i&gt;
</summary>
<dc:date>2005-08-01T00:00:00Z</dc:date>
<dc:description>I have been teaching, in reality, preaching, the importance of a clear understanding for the word “analysis”. It is my conclusion, after years of exposure to the term “system analysis”, that it has mislead lots of young people how wishes to understand the process of software construction, in special the initial steps of the process. My main point is that you can only analyze something that you know. However, educators in the areas of information systems and software engineering always focused the “system analysis” as a modeling discipline, where specifications were written and formalization was sought at the very early stages of conceptions of a system. Based on this bias on modeling, analysis was a way of enforcing syntax rules of a given modeling language, which provide ways of applying verification protocols. As such, not enough emphasis was directed to the goal of really understanding the concepts involved and the needs of the clients.&#13;
&#13;
&lt;i&gt;(Párrafo extraído del texto a modo de resumen)&lt;/i&gt;</dc:description>
</entry>
<entry>
<title>Structural testing with use cases</title>
<link href="http://sedici.unlp.edu.ar:80/handle/10915/9576" rel="alternate"/>
<author>
<name>Carniello, Adriana</name>
</author>
<author>
<name>Jino, Mario</name>
</author>
<author>
<name>Chaim, Marcos Lordello</name>
</author>
<id>http://sedici.unlp.edu.ar:80/handle/10915/9576</id>
<updated>2019-06-19T04:03:12Z</updated>
<published>2005-08-01T00:00:00Z</published>
<summary type="text">Articulo
Journal of Computer Science &amp; Technology; vol. 5, no. 2
Understanding how a user interacts with a system is important if the goal is to deliver a product that meets the user's needs. Use cases constitute a primary source of requirements in a user-centered perspective and are often utilized to derive acceptance tests. Given such a critical role in requirements engineering, we introduce a novel set of testing criteria based on the use case specification with a two-fold objective: to assess the quality of test cases derived from use cases and to test the use case specification itself. Differently from previous approaches, the novel set of testing criteria requires that structural elements of the use cases be exercised at least once. To support the application of the new set of testing criteria, a testing coverage tool, called UCT - Use Case Tester, was developed. A case study using UCT shows that the new testing criteria are able to evaluate the quality of a test data set as well as to detect faults in use case specifications.
</summary>
<dc:date>2005-08-01T00:00:00Z</dc:date>
<dc:description>Understanding how a user interacts with a system is important if the goal is to deliver a product that meets the user's needs. Use cases constitute a primary source of requirements in a user-centered perspective and are often utilized to derive acceptance tests. Given such a critical role in requirements engineering, we introduce a novel set of testing criteria based on the use case specification with a two-fold objective: to assess the quality of test cases derived from use cases and to test the use case specification itself. Differently from previous approaches, the novel set of testing criteria requires that structural elements of the use cases be exercised at least once. To support the application of the new set of testing criteria, a testing coverage tool, called UCT - Use Case Tester, was developed. A case study using UCT shows that the new testing criteria are able to evaluate the quality of a test data set as well as to detect faults in use case specifications.</dc:description>
</entry>
<entry>
<title>Construction of a taxonomy for requirements engineering commercial-off-the-shelf components</title>
<link href="http://sedici.unlp.edu.ar:80/handle/10915/9575" rel="alternate"/>
<author>
<name>Ayala, Claudia</name>
</author>
<author>
<name>Botella, Pere</name>
</author>
<author>
<name>Franch, Xavier</name>
</author>
<id>http://sedici.unlp.edu.ar:80/handle/10915/9575</id>
<updated>2019-06-19T04:03:11Z</updated>
<published>2005-08-01T00:00:00Z</published>
<summary type="text">Articulo
Journal of Computer Science &amp; Technology; vol. 5, no. 2
This article presents a procedure for constructing a taxonomy of COTS products in the field of Requirements Engineering (RE). The taxonomy and the obtained information reach transcendental benefits to the selection of systems and tools that aid to RE-related actors to simplify and facilitate their work. This taxonomy is performed by means of a goal-oriented methodology inspired in GBRAM (Goal-Based Requirements Analysis Method), called GBTCM (Goal-Based Taxonomy Construction Method), that provides a guide to analyze sources of information and modeling requirements and domains, as well as gathering and organizing the knowledge in any segment of the COTS market. GBTCM claims to promote the use of standards and the reuse of requirements in order to support different processes of selection and integration of components.
</summary>
<dc:date>2005-08-01T00:00:00Z</dc:date>
<dc:description>This article presents a procedure for constructing a taxonomy of COTS products in the field of Requirements Engineering (RE). The taxonomy and the obtained information reach transcendental benefits to the selection of systems and tools that aid to RE-related actors to simplify and facilitate their work. This taxonomy is performed by means of a goal-oriented methodology inspired in GBRAM (Goal-Based Requirements Analysis Method), called GBTCM (Goal-Based Taxonomy Construction Method), that provides a guide to analyze sources of information and modeling requirements and domains, as well as gathering and organizing the knowledge in any segment of the COTS market. GBTCM claims to promote the use of standards and the reuse of requirements in order to support different processes of selection and integration of components.</dc:description>
</entry>
<entry>
<title>The use of UML activity diagrams and the i* language in the modeling of the balanced scorecard implantation process</title>
<link href="http://sedici.unlp.edu.ar:80/handle/10915/9574" rel="alternate"/>
<author>
<name>Haya, Mariela</name>
</author>
<author>
<name>Franch, Xavier</name>
</author>
<author>
<name>Mayol, Enric</name>
</author>
<id>http://sedici.unlp.edu.ar:80/handle/10915/9574</id>
<updated>2019-06-19T04:03:10Z</updated>
<published>2005-08-01T00:00:00Z</published>
<summary type="text">Articulo
Journal of Computer Science &amp; Technology; vol. 5, no. 2
Business management is a complex task that can be facilitated using different methodologies and models. One of their most relevant purposes is to align the organization strategy with the daily functioning of the organization. One of these models is the Balanced Scorecard (BSC). In this paper, we propose a modeling strategy for the BSC implantation process. We will model it using UML Activity Diagrams and Strategy Dependency models of the language i*. The Activity Diagrams allow determining the order in which involved activities must be performed, and at the same time, to identify which people has the responsability to carry them out. The Strategic Dependency model allows showing the intentional aspects of the actors involved in the most strategic activities of this process. Finally, relationships among the actors and the people involved in the BSC implantation process are modelled using again the language i*. Although this paper only considers the case study of the BSC implantation, our proposal can be generalized to other implantation processes of systems with a high strategic impact on the organization, like ERP or CRM systems.
</summary>
<dc:date>2005-08-01T00:00:00Z</dc:date>
<dc:description>Business management is a complex task that can be facilitated using different methodologies and models. One of their most relevant purposes is to align the organization strategy with the daily functioning of the organization. One of these models is the Balanced Scorecard (BSC). In this paper, we propose a modeling strategy for the BSC implantation process. We will model it using UML Activity Diagrams and Strategy Dependency models of the language i*. The Activity Diagrams allow determining the order in which involved activities must be performed, and at the same time, to identify which people has the responsability to carry them out. The Strategic Dependency model allows showing the intentional aspects of the actors involved in the most strategic activities of this process. Finally, relationships among the actors and the people involved in the BSC implantation process are modelled using again the language i*. Although this paper only considers the case study of the BSC implantation, our proposal can be generalized to other implantation processes of systems with a high strategic impact on the organization, like ERP or CRM systems.</dc:description>
</entry>
<entry>
<title>Estimate of the functional size in the requirements elicitation</title>
<link href="http://sedici.unlp.edu.ar:80/handle/10915/9573" rel="alternate"/>
<author>
<name>Bertolami, Mabel Angélica</name>
</author>
<author>
<name>Oliveros, Alejandro</name>
</author>
<id>http://sedici.unlp.edu.ar:80/handle/10915/9573</id>
<updated>2019-06-19T04:03:08Z</updated>
<published>2005-08-01T00:00:00Z</published>
<summary type="text">Articulo
Journal of Computer Science &amp; Technology; vol. 5, no. 2
Early measurement of software size allows to estimate costs and effort as well as to plan the development schedule. In previous reports, an approach which applies the Function Points Analysis to the derivative Scenarios of the Language Extended Lexicon was presented. In the process of the validation of that proposal, statistical techniques were applied on a subset of the obtained data from the measurement of several cases of study. In this article, a linear regression analysis which allowed establishing an estimate model of the scenarios functional size and the verification of the validity of that model is presented. The results are encouraging as for the feasibility of the model and its possible subsequent refinements.
</summary>
<dc:date>2005-08-01T00:00:00Z</dc:date>
<dc:description>Early measurement of software size allows to estimate costs and effort as well as to plan the development schedule. In previous reports, an approach which applies the Function Points Analysis to the derivative Scenarios of the Language Extended Lexicon was presented. In the process of the validation of that proposal, statistical techniques were applied on a subset of the obtained data from the measurement of several cases of study. In this article, a linear regression analysis which allowed establishing an estimate model of the scenarios functional size and the verification of the validity of that model is presented. The results are encouraging as for the feasibility of the model and its possible subsequent refinements.</dc:description>
</entry>
<entry>
<title>Evaluating methodologies: a requirements engineering approach through the use of an exemplar</title>
<link href="http://sedici.unlp.edu.ar:80/handle/10915/9572" rel="alternate"/>
<author>
<name>Cysneiros, Luiz Marcio</name>
</author>
<author>
<name>Werneck, Vera</name>
</author>
<author>
<name>Yu, Eric</name>
</author>
<id>http://sedici.unlp.edu.ar:80/handle/10915/9572</id>
<updated>2019-06-19T04:03:07Z</updated>
<published>2005-08-01T00:00:00Z</published>
<summary type="text">Articulo
Journal of Computer Science &amp; Technology; vol. 5, no. 2
Systems development methodologies continue to be a central area of research in software engineering. As the nature of applications and systems usage move increasingly towards open networked environments, not only are new methodologies required, but new ways for evaluating methodologies for these new environments are also required. The agent-oriented approach to software engineering introduces concepts such as pro-activeness and autonomy to achieve more flexible and robust systems for complex applications environments. A number of AOSE methodologies have been proposed. In order to evaluate and compare these methods in depth, we proposed the use of a common exemplar-a detailed application setting within which each of the methodologies will be worked out. The evaluation method emphasizes a requirements engineering perspective. In this paper we show how to apply this exemplar to evaluate three agentoriented methodologies.
</summary>
<dc:date>2005-08-01T00:00:00Z</dc:date>
<dc:description>Systems development methodologies continue to be a central area of research in software engineering. As the nature of applications and systems usage move increasingly towards open networked environments, not only are new methodologies required, but new ways for evaluating methodologies for these new environments are also required. The agent-oriented approach to software engineering introduces concepts such as pro-activeness and autonomy to achieve more flexible and robust systems for complex applications environments. A number of AOSE methodologies have been proposed. In order to evaluate and compare these methods in depth, we proposed the use of a common exemplar-a detailed application setting within which each of the methodologies will be worked out. The evaluation method emphasizes a requirements engineering perspective. In this paper we show how to apply this exemplar to evaluate three agentoriented methodologies.</dc:description>
</entry>
<entry>
<title>A pattern language to join early and late requirements</title>
<link href="http://sedici.unlp.edu.ar:80/handle/10915/9571" rel="alternate"/>
<author>
<name>Martínez, Alicia</name>
</author>
<author>
<name>Pastor López, Oscar</name>
</author>
<author>
<name>Estrada, Hugo</name>
</author>
<id>http://sedici.unlp.edu.ar:80/handle/10915/9571</id>
<updated>2019-06-19T04:03:06Z</updated>
<published>2005-08-01T00:00:00Z</published>
<summary type="text">Articulo
Journal of Computer Science &amp; Technology; vol. 5, no. 2
At present, the early phase of Requirements Engineering is a new research area in the Software Engineering field. This phase is concerned with the analysis of the organizational context in which a software system will be used. The models used in this phase allow us to describe an organizational environment using actors, goals, business processes and relationships. The late phase of Requirements Engineering, which is focused on representing the expected functionality of the software system, is more developed, so there are multiple techniques and tools to describe the software system that will be developed inside its operational environment. However, although there are methodologies which give separate support to each phase of requirements engineering, the development of methods to derive late requirements from the early requirements in a methodological way has been neglected in recent research works. This is due, in great measure, to the large difference between the abstraction levels of these two specification models. The objective of this paper is to propose a pattern language which allows us to reduce the abstraction level between early requirements and late requirements in a systematic way. This is done in an MDA-based approach.
</summary>
<dc:date>2005-08-01T00:00:00Z</dc:date>
<dc:description>At present, the early phase of Requirements Engineering is a new research area in the Software Engineering field. This phase is concerned with the analysis of the organizational context in which a software system will be used. The models used in this phase allow us to describe an organizational environment using actors, goals, business processes and relationships. The late phase of Requirements Engineering, which is focused on representing the expected functionality of the software system, is more developed, so there are multiple techniques and tools to describe the software system that will be developed inside its operational environment. However, although there are methodologies which give separate support to each phase of requirements engineering, the development of methods to derive late requirements from the early requirements in a methodological way has been neglected in recent research works. This is due, in great measure, to the large difference between the abstraction levels of these two specification models. The objective of this paper is to propose a pattern language which allows us to reduce the abstraction level between early requirements and late requirements in a systematic way. This is done in an MDA-based approach.</dc:description>
</entry>
<entry>
<title>Mapping Activity Theory Diagrams into i* Organizational Models</title>
<link href="http://sedici.unlp.edu.ar:80/handle/10915/9570" rel="alternate"/>
<author>
<name>Cruz Neto, Genésio Gomes da</name>
</author>
<author>
<name>Gomes, Alex Sandro</name>
</author>
<author>
<name>Castro, Jaelson Brelaz de</name>
</author>
<id>http://sedici.unlp.edu.ar:80/handle/10915/9570</id>
<updated>2019-06-19T04:03:06Z</updated>
<published>2005-08-01T00:00:00Z</published>
<summary type="text">Articulo
Journal of Computer Science &amp; Technology; vol. 5, no. 2
Modern requirement engineering approaches divide the elicitation process in two different stages: one focused on analyzing the context where the system-to-be will be used and another centered on designing software solutions appropriated to the context modeled. An adequate framework for assisting context analysis is offered by the Activity Theory, a philosophic and interdisciplinary structure to study different forms of human practice that adopts the activity as the basic unit of analysis. However, there are still no methods for integrating context analysis based on Activity Theory and traditional requirement specifications techniques. In a previous work, the authors presented a requirement engineering process that integrates ethnographic analysis based on Activity Theory with requirement specification techniques based on organizational modelling. In this work we present an evolution of the process proposed by including a set of mapping guidelines to systematically transform Activity Theory diagrams into i* based organizational models. Moreover, we apply the guidelines in the development of a virtual project based learning environment.
</summary>
<dc:date>2005-08-01T00:00:00Z</dc:date>
<dc:description>Modern requirement engineering approaches divide the elicitation process in two different stages: one focused on analyzing the context where the system-to-be will be used and another centered on designing software solutions appropriated to the context modeled. An adequate framework for assisting context analysis is offered by the Activity Theory, a philosophic and interdisciplinary structure to study different forms of human practice that adopts the activity as the basic unit of analysis. However, there are still no methods for integrating context analysis based on Activity Theory and traditional requirement specifications techniques. In a previous work, the authors presented a requirement engineering process that integrates ethnographic analysis based on Activity Theory with requirement specification techniques based on organizational modelling. In this work we present an evolution of the process proposed by including a set of mapping guidelines to systematically transform Activity Theory diagrams into i* based organizational models. Moreover, we apply the guidelines in the development of a virtual project based learning environment.</dc:description>
</entry>
<entry>
<title>Designing communication-intensive web applications: experience and lessons from a real case</title>
<link href="http://sedici.unlp.edu.ar:80/handle/10915/9569" rel="alternate"/>
<author>
<name>Perrone, Vito</name>
</author>
<author>
<name>Bolchini, Davide</name>
</author>
<id>http://sedici.unlp.edu.ar:80/handle/10915/9569</id>
<updated>2019-06-19T04:03:05Z</updated>
<published>2005-08-01T00:00:00Z</published>
<summary type="text">Articulo
Journal of Computer Science &amp; Technology; vol. 5, no. 2
Who uses requirements engineering and design methodologies besides the people who invented them? Are researchers -at least- actually trying to use them in real-world complex projects and not in "paper project"? In this paper, we dare to recount the experience and the lessons we gained in trying to use seriously and in-depth a requirements engineering method (called AWARE) combined with a conceptual user-centered design method (called W2000) for the development of a real-world web application. The project is recounted through the process followed and the artefacts produced, as well as by crystallizing our experience in using and transferring the method to industry in practical and methodological recommendations.
</summary>
<dc:date>2005-08-01T00:00:00Z</dc:date>
<dc:description>Who uses requirements engineering and design methodologies besides the people who invented them? Are researchers -at least- actually trying to use them in real-world complex projects and not in "paper project"? In this paper, we dare to recount the experience and the lessons we gained in trying to use seriously and in-depth a requirements engineering method (called AWARE) combined with a conceptual user-centered design method (called W2000) for the development of a real-world web application. The project is recounted through the process followed and the artefacts produced, as well as by crystallizing our experience in using and transferring the method to industry in practical and methodological recommendations.</dc:description>
</entry>
</feed>
