AnÆlisis de Requisitos Comunicativos

�

�

�

�

�

�

�

�

�

�

�

�

�

Análisis Análisis Análisis Análisis de Requisitos de Requisitos de Requisitos de Requisitos CCCCoooomunicativosmunicativosmunicativosmunicativos

i

1- REQUISITOS........................................................................................................ 1�

1.1� LA MOTIVACIÓN ___________________________________________________ 1�1.1.1� The Chaos Report (1995) __________________________________ 1�1.1.2� The Robbins-Gioia Survey (2001) ____________________________ 2�1.1.3� The Conference Board Survey (2001) _______________________ 3�1.1.4� The KPMG Canada Survey (1997) ___________________________ 3�1.1.5� The OASIG Study (1995) __________________________________ 3�1.1.6� IT Cortex Conclusion _____________________________________ 4�

1.2� EL ESTADO ACTUAL ________________________________________________ 5�

1.3� REQUISITOS SOFTWARE _____________________________________________ 6�1.3.1� Estructura de los requisitos________________________________ 7�1.3.2� Tipos de requisitos ______________________________________ 8�1.3.3� Necesidades y características ____________________________ 13�

1.4� ¿DONDE ESTÁ EL PROBLEMA? _______________________________________ 13�

1.5� ¿SOLUCIONES? __________________________________________________ 16�

2- REQUISITOS EN SISTEMAS DE INFORMACIÓN ........................................... 17�

2.1� ENTRADAS Y SALIDAS______________________________________________ 18�2.1.1� El SI como sistema de comunicaciones _____________________ 18�

2.2� EVENTOS Y OBJETOS ______________________________________________ 20�2.2.1� Percepción de Eventos e individuos. _______________________ 21�

2.3� ÁMBITOS DE LOS REQUISITOS ________________________________________ 22�2.3.1� El ámbito sistema______________________________________ 23�2.3.2� El ámbito de proceso. ___________________________________ 23�2.3.3� El ámbito de las interacciones comunicativas. ________________ 24�2.3.4� El ámbito de uso _______________________________________ 25�2.3.5� El ámbito de la infraestructura tecnológica ___________________ 26�

3- INTERACCIONES EXTERNAS ......................................................................... 27�

3.1� LAS INTERACCIONES COMO BASE DEL ANÁLISIS___________________________ 27�

3.2� LA EXTERNALIDAD ________________________________________________ 27�3.2.1� Refinamientos _________________________________________ 28�3.2.2� Confusión externa/interna ________________________________ 28�3.2.3� Refinamientos de interacciones externas e internas. ___________ 29�

3.3� LA UNIDAD ______________________________________________________ 30�3.3.1� Comunicaciones _______________________________________ 30�3.3.2� Sucesos______________________________________________ 32�3.3.3� Sucesos comunicativos__________________________________ 33�3.3.4� Criterios de unidad _____________________________________ 34�3.3.5� Criterios de unidad en los sucesos comunicativos _____________ 35�3.3.6� Estructuras de comunicación _____________________________ 39�3.3.7� Un ejemplo trivial_______________________________________ 39�3.3.8� Completando la visión comunicativa________________________ 42�

4- LA ORGANIZACIÓN DE LAS INTERACCIONES............................................. 45�

4.1� TÉCNICAS DESCRIPTIVAS ___________________________________________ 45�4.1.1� Introducción ___________________________________________ 45�4.1.2� Orientadas a objeto _____________________________________ 47�4.1.3� Orientadas a objetos de negocio___________________________ 48�4.1.4� BPMN _______________________________________________ 51�4.1.5� Casos de uso__________________________________________ 53�4.1.6� Diagramas de composición de interacciones _________________ 55�

4.2� DIAGRAMAS DE COMPORTAMIENTO ___________________________________ 57�4.2.1� Elementos básicos de los diagramas _______________________ 57�4.2.2� Estructura de comportamiento. ____________________________ 59�

4.3� GUÍAS DE DIAGRAMACIÓN. __________________________________________ 64�4.3.1� Trazado de comunicaciones. _____________________________ 65�4.3.2� Especialización.________________________________________ 67�

5- ANÁLISIS DE REQUISITOS Y PROCESOS DE NEGOCIO.............................71�

5.1� PERCEPCIONES DE LA REALIDAD _____________________________________ 71�5.1.1� Observación de eventos o de individuos_____________________ 73�5.1.2� Elementos del sistema objeto _____________________________ 74�5.1.3� Entradas y salidas: lo básico y lo derivado ___________________ 75�5.1.4� Niveles organizacionales_________________________________ 76�

5.2� PROCESOS Y OBJETOS. ____________________________________________ 77�5.2.1� Dinámica de los objetos derivados _________________________ 78�

5.3� ESTRATEGIAS DE ANÁLISIS DE INTERACCIONES___________________________ 78�5.3.1� Estrategias directas _____________________________________ 78�5.3.2� Estrategias inversas ____________________________________ 79�5.3.3� Estrategias internas_____________________________________ 80�

5.4� CRITERIOS DE UNIDAD EN LOS PROCESOS DE NEGOCIO _____________________ 81�

5.5� LOS REQUISITOS DEL ÁMBITO PROCESO ________________________________ 82�

5.6� ELEMENTOS DE UNA DESCRIPCIÓN DE REQUISITOS PROCESO ________________ 82�

5.7� ANÁLISIS DEL COMPORTAMIENTO COMUNICATIVO _________________________ 85�5.7.1� Análisis generativo _____________________________________ 85�5.7.2� Análisis de salidas vinculadas. ____________________________ 89�5.7.3� Consultores de auditoría _________________________________ 90�5.7.4� Constructores vinculados ________________________________ 91�5.7.5� Análisis de Objetos de negocio. ___________________________ 92�5.7.6� La busqueda de interacciones comunicativas a partir de objetos de negocio 93�

6- ESPECIFICACIÓN DE SUCESOS.....................................................................97�

6.1� REQUISITOS ASOCIADOS A UN SUCESO _________________________________ 97�

6.2� IDENTIFICACIÓN Y NOMINACIÓN DE SUCESOS. ____________________________ 97�

6.3� ESPECIFICACIÓN DE SUCESOS DE ENTRADA._____________________________ 98�6.3.1� DESCRIPCIÓN GENERAL _______________________________ 98�6.3.2� DESCRIPCIÓN DEL CONTACTO _________________________ 99�6.3.3� DESCRIPCIÓN DE LA COMUNICACIÓN __________________ 100�6.3.4� DESCRIPCIÓN DE LA REACCIÓN DEL SISTEMA ___________ 106�6.3.5� Requisitos comunicativos del ámbito de uso ________________ 110�

iii

6.3.6� Requisitos comunicativos del ámbito del suceso._____________ 110�

6.4� ESTRUCTURAS DE ADQUISICIÓN _____________________________________ 111�6.4.1� Notación para la definición de estructuras de mensajes _______ 111�6.4.2� Operaciones de adquisición de datos______________________ 112�6.4.3� Derivación de estructuras _______________________________ 114�6.4.4� Especialización _______________________________________ 121�

7- SUCESOS Y ESTADO..................................................................................... 123�7.1.1� Sucesos y Objetos ____________________________________ 123�7.1.2� Sucesos y Clases de Sucesos ___________________________ 125�7.1.3� Sucesos y estados ____________________________________ 125�7.1.4� Relaciones de Cardinalidad _____________________________ 126�7.1.5� Diagramas de sucesos y diagramas de estados _____________ 127�7.1.6� Especialización de comportamiento y estado. _______________ 129�

8- REQUISITOS DE USO..................................................................................... 131�

8.1� LOS SUCESOS EN EL ENTORNO DE USO _______________________________ 131�

8.2� SOPORTE A LA LOCALIZACIÓN. ______________________________________ 133�8.2.1� Localización de clases de funciones. ______________________ 133�8.2.2� Localización de instancias de objetos______________________ 135�

8.3� SOPORTE EDITORIAL______________________________________________ 135�8.3.1� Compatibilidad editorial: Contextos editoriales. ______________ 136�

9- EL ANÁLISIS........................................... ¡ERROR! MARCADOR NO DEFINIDO.�

9.1� ACTORES ______________________________________________________ 141�

9.2� FUENTES DE INFORMACIÓN. ________________________________________ 141�

9.3� ENTREVISTAS. __________________________________________________ 142�9.3.1� Consideraciones generales sobre las entrevistas ____________ 142�9.3.2� El proceso de la entrevista ______________________________ 143�

9.4� ENTREVISTAS Y ÁMBITOS DE LOS REQUISITOS. __________________________ 147�9.4.1� Las entrevistas iniciales ________________________________ 147�9.4.2� Las entrevistas del ámbito proceso________________________ 151�9.4.3� Cuestionarios. __________________ ¡Error! Marcador no definido.�

Requisitos

1

1111---- RequisitosRequisitosRequisitosRequisitos

1.1 ��

Cuando se justifica la necesidad de los requisitos encontramos dos argumentos en la literatura. El primero es externo. Se basa en la comparación con procesos constructivos de áreas ajenas al software. Concretamente con la arquitectura. Si los arquitectos usan planos y presupuestos ¿Por qué los informáticos no lo hacen? Nadie parece decepcionado con su casa.

El segundo tipo de argumento es interno. Se basa en un famoso y cuestionado informe de 1994. El Standish Group Chaos Report. La consultora IT Cortex recoge en su web diferentes informes sobre fracaso de proyectos. http://www.it-cortex.com

1.1.1 The Chaos Report (1995)The Chaos Report (1995)The Chaos Report (1995)The Chaos Report (1995)

The Chaos Report is the first survey made by the Standish Group. This report is �� landmark study of IT project failure. It is cited by everybody writing a paper or making a presentation were a reference is made of IT project failure.

1111 Scope of the Study Scope of the Study Scope of the Study Scope of the Study

The respondents to the Standish Group survey were IT executive managers. The sample includes large, medium, and small companies across major industry segments : banking, securities, manufacturing, retail, wholesale, heath care, insurance, services, and local, state, and federal organizations. The total sample size was 365 respondents representing 8,380 applications. In addition, The Standish Group conducted focus groups and personal interviews to provide qualitative context for the survey results.

� Key FinKey FinKey FinKey Findingsdingsdingsdings�

The Standish Group research shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost over 189% of their original estimates. The cost of these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity costs are not measurable, but could easily be in the trillions of dollars in the United States alone.

Based on this research, The Standish Group estimates that in 1995 American companies and government agencies will spend $81 billion for canceled software projects. These same organizations will pay an additional $59 billion for software projects that will be completed, but will exceed their original time estimates. The Standish Group estimates that almost 80,000 projects were cancelled in 1995. Risk is always a factor when pushing the technology envelope, but many of these projects were as mundane as a drivers license database, a new accounting package, or an order entry system.

On the success side, the average is only 16.2% for software projects that are completed on-time and on-budget. In the larger companies, the news is even worse: only 9% of their projects come in on-time and on-budget. And, even when these projects are completed, many are no more than a mere shadow of their original specification requirements. Projects completed by the largest American companies have only approximately 42% of the originally-proposed features and functions. Smaller companies do much better. A total of 78.4% of their software projects will get deployed with at least 74.2% of their original features and functions.

This data may seem disheartening, and in fact it is, 48% of the IT executives in our research sample feel that there are more failures currently than just five years ago.

Pero el Standish report no es el único informe de fracaso.

1.1.2 The RobbinsThe RobbinsThe RobbinsThe Robbins----Gioia Survey (2001)Gioia Survey (2001)Gioia Survey (2001)Gioia Survey (2001)

Robbins-Gioia, LLC, a provider of management consulting services located in Alexandria - Virginia, made a study over the perception by enterprises of their implementation of an E.R.P. (Enterprise Resource Planning) package.

Survey ScopeSurvey ScopeSurvey ScopeSurvey Scope�

232 survey respondents spanning multiple industries including government, Information Technology, communications, financial, utilities, and healthcare.

A total of 36 % of the companies surveyed had, or were in the process of, implementing an ERP system.

� Key FindingsKey FindingsKey FindingsKey Findings�

�� ! �� "�#$%��&��

� Comments on the RobinsComments on the RobinsComments on the RobinsComments on the Robins----Gioia SurveyGioia SurveyGioia SurveyGioia Survey�

Project failure is not defined by objective criteria but by the perception of the respondents. The advantage of a perception is that it naturally integrates multiple aspects. Its obvious disadvantage

Requisitos

3

is that it is inevitably partial: if the respondent has taken an active role in the project it will inevitably embellish the reality, whereas if the project has been "forced down his throat" he might cast a grimmer look at the project outcome.

1.1.3 The Conference Board SurveyThe Conference Board SurveyThe Conference Board SurveyThe Conference Board Survey (2001)(2001)(2001)(2001)

1111 Survey ScopeSurvey ScopeSurvey ScopeSurvey Scope

That survey interviewed executives at 117 companies that attempted ERP implementations �


&��'��!( �)��'��( )��! �*��+�� ,�� -� ��.��.��! /��0�� 1�� 0*��!

1.1.4 The KPMG Canada Survey (1997)The KPMG Canada Survey (1997)The KPMG Canada Survey (1997)The KPMG Canada Survey (1997)

In April 1997, KPMG Canada sent a survey questionnaire focusing on IT project management issues to Canada's leading 1,450 public and private sector organizations. The main purpose was to outline the reasons behind the failure of �nformation �echnology projects.

Survey ScopeSurvey ScopeSurvey ScopeSurvey Scope�Out of 1,450 questionnaires sent, 176 were analyzed. Of these, 61 % reported details on a failed IT project.

� Key Findings Key Findings Key Findings Key Findings �

Over 61 % of the projects that were analyzed were deemed to have failed by the respondents. More than three quarters blew their schedules by 30% or more; more than half exceeded their budgets by a substantial margin. Considering that an estimated $25 billion is spent on IT application development in Canada annually, the survey data clearly indicate that unbudgeted IT project expenditures must run into the billions of dollars.

1.1.5 The OASIG Study (1995)The OASIG Study (1995)The OASIG Study (1995)The OASIG Study (1995)

This study has been undertaken under the auspices of ��, a Special Interest Group in the UK concerned with the Organizational Aspects of Information Technology.

Scope of the StudyScope of the StudyScope of the StudyScope of the Study�

Information was collected in 1995 in the United Kingdom from a sample of 45 experts employed primarily by Universities or Consultancies. On average they have each over 20 years personal experience representing a cumulative knowledge base of over 900 years. Their drew their opinion from a sample of approximately 14,000 user organizations. 31 of these interviewees (69%)

include consultancy work as a major component of their work, and 27 (60%) include research; many do both. Their professional areas of expertise cover the domains of management, business, and social science. A small number of those interviewed have a background in engineering. Data were collected by interviewing researchers and consultants using a semi-structured interview schedule. Some preparation was required by them. Each interview lasted, on average, around 1.5 to 2 hours, though some lasted considerably longer.


The IT project success rate quoted revolves around 20-30% based on its most optimistic interviews. Bottom line, at best, 7 out of 10 IT projects “fail” in some respect.

1.1.6 IT Cortex ConclusionIT Cortex ConclusionIT Cortex ConclusionIT Cortex Conclusion

The statistics presented here all converge to establish that: an IT project is more likely to be unsuccessful than successful about 1 out of 5 IT projects is likely to bring full satisfaction the larger the project the more likely the failure

Requisitos

5

1.2 ��

La situación ha mejorado. Si nos atenemos a la opinión de David Rubisntein la mejora ha sido sustancial. Del cien por cien. Lo que nos sitúa en el 2006 en una tasa de éxito en proyectos del 35%.

Sin embargo, a pesar de no tener datos objetivos, la situación no es boyante. Los usuarios siguen pensando que los informáticos no les entienden. Los informáticos siguen pensando que los usuarios no saben lo que quieren. Se mantiene un desentendimiento continuo que se traduce en una actitud defensiva y medrosa por ambas partes.

Una persona que viaja en un globo aerostático se da cuenta de que se ha perdido. Hace descender el globo al ver una persona en un campo. Poco a poco se acerca y le pregunta: -Disculpe, ¿podría decirme donde estoy? -Sí. Esta usted en un globo aerostático a 8 metros de altura de este campo. El del globo replica. -Usted debe ser informático. -Sí, lo soy. ¿Cómo lo ha sabido? -Bueno, todo lo que me ha dicho es técnicamente correcto pero no me sirve para nada. -Ah! Pues usted debe ser consultor. -Sí, lo soy. ¿Cómo lo ha sabido? -Porque no sabe donde está ni donde va y espera que yo le ayude. Está en la misma situación en que estaba antes de preguntarme pero ahora la culpa es mía.

Algunas aplicaciones simples de complejidad baja o media se desarrollan adecuadamente. Tienen éxito las aplicaciones “universales” porque en ellas el usuario se adapta a la aplicación.

Cuando una organización ha sufrido diferentes fracasos acepta adaptarse a algo que por lo menos funcione. Las consultoras han acuñado el término “gestión del cambio” en realidad es un eufemismo que describe como las organizaciones se rinden ante la imposibilidad de definir su propia gestión.

Las aplicaciones adaptadas al usuario son cada vez más raras. Prácticamente ningún profesional propone un desarrollo a medida. Profesionales muy competentes temen este tipo de desarrollo y se cobijan en los ERP y en la integración. Los ERP proporcionan argumentos rotundos para rechazar los “caprichosos requisitos” de los usuarios: “No es posible hacerlo”. Este tipo de argumentación no es viable con el desarrollo a medida. Pero en la mayoría de los casos el usuario no quiere pagar lo que cuesta.

1.3 ��

La ingeniería de requisitos parte de una concepción ambigua del concepto de requisito. Cualquier manual sobre requisitos del software adopta las definiciones del glosario del IEEE “IEEE Standard Glossary of Software Engineering Terminology (1997)”. Según el cual un requisito se define como:

• Una condición o capacidad necesaria para un usuario para resolver un problema o alcanzar un objetivo.

• Una condición o capacidad que tiene que cumplir o poseer un sistema o una componente de un sistema para satisfacer un contrato, un estándar, una especificación o cualquier otro documento formalmente establecido.

• Una representación documentada de cualquier condición o capacidad como las dos anteriores

La primera definición se orienta a la necesidad del usuario. La segunda tiene un trasfondo defensivo. Responde a una necesidad de los desarrolladores por establecer los límites y alcance de su trabajo. En la visión contractual se busca definir las reglas del juego para que los costes de un proyecto no se disparen arbitrariamente. El frecuente desencuentro entre analistas y usuarios hace que cada parte intente resguardarse de los riesgos.

Requisitos

7

De modo que se ha acuñado el eufemismo “gestionar al cliente” para reflejar esta actitud de protección frente a la volubilidad del cliente. La gestión del cliente por parte del ingeniero de requisitos comprende la firma de un documento de requisitos que exima a la empresa de desarrollo de responsabilidades más allá de lo “razonable. Pero también incluye saber convencer al cliente que lo que pide debe mantenerse en lo “razonable”.

Lo razonable siempre suele estar vinculado a los resultados y capacidades que la empresa que desarrolla espera y ofrece.

Estas definiciones, por sí solas, no permiten establecer un concepto homogéneo, y por tanto de calidad, de requisito. La literatura de requisitos y el aprendizaje del concepto y de su uso metodológico se hace a través de ejemplos y discusiones. En realidad cualquier concepto utilizado en ingeniería de software o en el desarrollo de sistemas de información es siempre interpretado de forma amplia. En [Hulburt 1993] se estudian más de treinta formas de entender y aplicar los casos de uso. Esto significa que los términos y conceptos que estamos usando son ambiguos y favorecen la actitud subjetiva en detrimento de la norma y lo estándar.

En la actualidad la mayoría de autores coinciden en que los requisitos deben mostrar el carácter externo del sistema. El que será percibido por los usuarios. Esta idea ha sido recogida durante mucho tiempo en la frase “los requisitos deben mostrar qué hace el sistema y no el cómo”. Ni siquiera esta separación del qué y el cómo está clara. La disquisición que Alan Davis, la mayor autoridad en requisitos, hace del qué y el cómo le lleva a concluir que lo que para una persona puede ser el qué para otra es el cómo. De modo que de nuevo estamos ante una definición ambigua y subjetiva. Es por ello que Davis define el concepto de requisito como “función o “función o “función o “función o característica necesarias de un sistema que puede percibirse externamente”característica necesarias de un sistema que puede percibirse externamente”característica necesarias de un sistema que puede percibirse externamente”característica necesarias de un sistema que puede percibirse externamente”

Tom Gilb aporta una definición de requisito basada en el valor o en la utilidad. “Los requisitos son sentencias que identifican aquellas las necesidades esenciales de un sistema que hacen que tenga utilidad y valor. “

1.3.1 Estructura de los requisitosEstructura de los requisitosEstructura de los requisitosEstructura de los requisitos

Las técnicas de catalogación de requisitos proponen una estructura única y simple para los requisitos. La figura siguiente muestra una plantilla para la especificación de requisitos propuesta por la empresa Volere fundada por Tom de Marco. Esta empresa ofrece información en la web como soporte a la caracterización y búsqueda de requisitos.

��

Esta estructura sería idéntica para cualquier tipo de requisito. Además los requisitos se organizan mediante una lista numerada carente de orden o estructura.

Los requisitos se asociarían a sucesos o casos de uso, o a listas de ellos, para luego poder tener trazabilidad de satisfacción del usuario.

1.3.2 TiTiTiTipos de requisitospos de requisitospos de requisitospos de requisitos

La recomendación del estándar 830 del IEEE ofrece la siguiente tipología de requisitos.

1 Introducción 1.1 Propósito de la especificación 1.2 Alcance del producto 1.3 Definiciones, acrónimos y abreviaturas. 1.4 Referencias. 1.5 Descripción general del resto del documento.

2 Descripción general 2.1 Perspectiva de producto 2.2 Funciones del producto 2.3 Características de usuarios 2.4 Restricciones generales

3 Requisitos específicos 3.1 Requisitos funcionales

3.1.1 Requerimiento funcional 1 3.1.1.1 Introducción 3.1.1.2 Entradas 3.1.1.3 Proceso 3.1.1.4 Salidas

3.1.2 Requerimiento funcional 2 ... 3.1.n Requerimiento funcional n

... 3.2 Requisitos de interfaces externas

3.2.1 Interfaces de usuario 3.2.2 Interfaces hardware 3.2.3 Interfaces software 3.2.4 Interfaces de comunicación

3.3 Requisitos de rendimiento 3.4 Restricciones de diseño

3.4.1 Estándares 3.4.2 Limitaciones hardware

. . . 3.5 Atributos

3.5.1 Disponibilidad 3.5.2 Seguridad 3.5.3 Mantenimiento 3.5.4 Conversión

. . . 3.6 Otros requisitos

3.6.1 Base de datos 3.6.2 Operaciones 3.6.3 Adaptación de la instalación Apéndices Índice

��

Requisitos

9

La mayoría de textos proponen dos tipos de requisitos los funcionales y los no funcionales.

��

Para Ralph R. Young en “The Requirements Engineering Handbook” los requisitos pueden adscribirse a los siguientes niveles:

1 Business Requirements are the reason for developing systems and software in the first place. Business requirements are the essential activities of an enterprise. Business requirements are derived from business goals (the objectives of the enterprise or organization).

2 User Requirements Users are the individuals or groups that use a system or software in its environment.

User requirements are their verified needs for that system or

software.

3 High-Level or System-Level Requirements To enable comprehending a needed system, we refer to the high-level or

system-level requirements. This term relates to those requirements that

are foremost in importance, capture the vision of the customer, enable

defining the scope of the system, and allow estimating the cost and schedule

required to build the system. (Some system architects believe that the

requirements specification should contain every performance requirement.)

It’s recommended that a workable number of requirements (on the order of

50 to 200) system-level requirements be identified for a large system. In

Chapter 8, we will discuss a set of business drivers that may be considered

high-level customer requirements, which often are not expressed.

4 Business Rules Business rules2 provide the basis for creating the functional requirements.

They are as follows:

• The policies, conditions, and constraints of the business activities supported by the system;

• The decision processes, guidelines, and controls behind the functional requirements (e.g., procedures);

• Definitions used by the business;

• Relationships and workflows in the business;

• Knowledge needed to perform actions.

5 Nonfunctional Requirements Nonfunctional requirements specify system properties, such as reliability and safety.

6 Derived Requirements A derived requirement is one that is further refined from a higher-level requirement or a requirement that results from choosing a specific implementation or system element. In a sense, all requirements are derived from the system need; thus, the derived distinction tends to have little significance. However, many systems engineers distinguish between externally identified requirements and requirements that are derived under the control of the engineer.

7 Design Requirements and Design Constraints For most system development efforts, design requirements/constraints appear right at the beginning of the system formulation. Here are examples of why it’s difficult to separate requirements engineering from design activities:

• New systems are often installed in environments that already have other systems. The other systems usually constrain the design of the new system. For example, a requirement (design constraint) may be that the system to be developed must obtain its information from an existing database. The database has already been designed and parts of its specification will usually be included in the requirements document.

• For large systems, some architectural design is often necessary to identify subsystems and relationships. Identifying subsystems means that the requirements engineering process for each subsystem can go on in parallel.

• For reasons of budget, schedule, or quality, an organization may wish to reuse some or all existing software systems in the implementation of a new system. This constrains both the system requirements and the design.

• If a system has to be approved by an external regulator (e.g., systems in civil aircraft), it may be necessary to use standard certified design that has been tested in other systems.

8 Performance Requirements One of the most difficult challenges in system development is defining and meeting the performance requirements (sometimes referred to as dependability requirements). The performance requirements define how well the functional requirements must perform. Performance requirements analysis components are beyond the scope of this book, but are described by Jeffrey O. Grady in Systems Requirements Analysis [8, pp. 238, 313, and 324]. Grady also provides a set of guidelines helpful in the identification of performance requirements [8, pp. 323–324]. Dependability requirements correspond to system-level needs for availability, security, performance, reliability, and safety.

9 Interface Requirements Another difficult challenge in system development is finding and defining the interface requirements. Interface requirements analysis identifies physical and functional relationships among system elements and between system elements and the system environment. One project team member should be assigned principal responsibility for assuring coordination of interface requirements. See [8, pp. 270–297] for a good discussion of interface analysis and techniques.

10 Verified Requirements Verified requirements are real requirements that are met or satisfied in the design solution.

11 Validated Requirements Validated requirements are requirements that are implemented in the delivered system. See Jeffrey O. Grady’s System Validation and Verification [9] for clear definitions of these terms,

Requisitos

11

detailed information concerning how to use these fundamental problem-solving tools, and practical methods for each step of the process.

12 Qualification Requirements Qualification refers to the verification or validation of item performance in a specific application and results from design review, test data review, and configuration audits.

Para Robin F. Goldsmith en “Discovering Real Business Requirements For Software Project Success” existen requisitos del negocio y requisitos del sistema. El problema para Goldsmith es más de enfoque. De intención descriptiva. De nuevo estamos ante un caso del qué y el cómo. Del problema y de la solución.

Para Karl E. Wiegers (1999) en “Software Requirements“ existen tres niveles de requisitos. Requisitos de negocio, Requisitos de usuario y Requisitos funcionales y no funcionales. Estos niveles de requisitos estarían alineados con la aproximación de RUP.

Los requisitos de negociorequisitos de negociorequisitos de negociorequisitos de negocio conducirían al documento de visión y alcance que contiene los objetivos de alto nivel que la organización requiere del producto.

Los requisitos de usuariorequisitos de usuariorequisitos de usuariorequisitos de usuario describen las tareas que los usuarios deben acometer con el producto. Los requisitos de usuario se capturan mediante descripciones de casos de uso o escenarios.

Por último los requisitos funcionalesfuncionalesfuncionalesfuncionales definen la funcionalidad del software que deben construir los desarrolladores para acometer sus tareas satisfaciendo los requisitos de negocio.

Wiegers define una característicacaracterísticacaracterísticacaracterística (feature) como “un conjunto de requisitos funcionales lógicamente relacionados que proporcionan una capacidad al usuario que permite satisfacer un requisito de negocio”.

Lo que algunos autores proponen como requisitos de negocio solo son requisitos genéricos o con mayor nivel de abstracción. Por ejemplo Wiegers [Wiegers 1999 pag 9] propone el siguiente requisito de negocio “los usuarios serán capaces de corregir los errores ortográficos en un documento de forma eficiente”.

La sentencia contiene dos aspectos. Una funcionalidad genérica que deberá descomponerse en un conjunto de funciones básicas que la satisfagan. Pero además contiene una palabra que no debería ser aceptada como parte de un requisito “eficiente”. Eficiente es una calificación cuya métrica es subjetiva y por tanto su satisfacción depende del usuario que en cada momento se relaciones con la aplicación.

Los requisitos presentan varias facetas. Una es su genericidad. Los requisitos pueden ser genéricos o específicos. A su vez los requisitos genéricos pueden ser refinables o propagables. Así el requisito anterior propuesto por Wiegers es genérico. Deberá refinarse en toda la variedad de funciones necesarias para dar cuerpo a un corrector ortográfico.

Otra faceta de los requisitos es su validabilidad o testeabilidad. Un requisito puede ser objetivamente testeable o no. Cuando un requisito es objetivamente testeable existe un método para evaluar su satisfacción independiente del usuario. Un requisito no es objetivamente testeable si su satisfacción depende de la interpretación de cada usuario. Obviamente la diferencia es importante. En un caso la testeabilidad es una propiedad del requisito. En el otro es una propiedad de la relación entre el requisito y el usuario.

Requisitos

13

1.3.3 Necesidades y característicasNecesidades y característicasNecesidades y característicasNecesidades y características

Algunos autores de manuales de casos de uso vinculados a RUP han añadido dos niveles sobre los requisitos. Se trata de necesidades y características. El manual de Dean Leffingwell “Managing Software requirements with Use Cases” es uno de ellos.

Para Leffingwell una característica es “a service that the system provides to fulfill one or more stakeholder needs.” Pero en el capítulo 9, dice “Features are a convenient way to describe functionality without getting bogged down in detail”.

Por lo tanto las features serían la funcionalidad en un determinado nivel de abstracción.

1.4 ��

No hay una verdadera visión externaNo hay una verdadera visión externaNo hay una verdadera visión externaNo hay una verdadera visión externa

Hay un error en el enfoque. Que al final haya que construir una aplicación no significa que los requisitos deben ser determinados desde el punto de vista de cómo se usará la aplicación. Los casos de uso son especialmente perjudiciales en esta visión. Sacralizan la definición de cómo se hacen las cosas y de cómo reaccionará el sistema por encima de qué hay que hacer.

A pesar de que todas las propuestas consideran la importancia del usuario el lenguaje de los requisitos es inmanejable para el usuario.

Los Los Los Los requisitosrequisitosrequisitosrequisitos no pueden ser una lista desestructurada no pueden ser una lista desestructurada no pueden ser una lista desestructurada no pueden ser una lista desestructurada

Hay una pobreza a la hora de estructurar los requisitos. Las listas planas de requisitos son totalmente inapropiadas para sistemas de información. Esta pobreza estructural se intenta mejorar con la nueva idea de trazabilidad. Solo se trata del problema detrás del problema. Como no se ha sabido estructurar adecuadamente los requisitos se ofrece una herramienta que relaciones requisitos, necesidades, características... Es un error para corregir un error.

Imagine que un usuario debiera aceptar la construcción de su casa en base a una lista de requisitos del tipo:

...

Los diferentes tipoLos diferentes tipoLos diferentes tipoLos diferentes tipos de sistemas tienen tipos de s de sistemas tienen tipos de s de sistemas tienen tipos de s de sistemas tienen tipos de requisitosrequisitosrequisitosrequisitos diferentes y formas de diferentes y formas de diferentes y formas de diferentes y formas de investigarlos diferentes.investigarlos diferentes.investigarlos diferentes.investigarlos diferentes.

Hay un error al creer que las interacciones de información son equiparables a las interacciones de materia y energía. Los requisitos para artefactos no se analizan igual que los requisitos para describir el conocimiento humano. No tiene nada que ver el problema físico de beber una taza de café con el problema lógico de representar la información de un pedido. Los vendedores de herramientas de requisitos pretenden que los requisitos para construir un velero son equiparables a los requisitos para construir una gestión de pedidos.

El concepto es ambiguoEl concepto es ambiguoEl concepto es ambiguoEl concepto es ambiguo y los ejemplos o casos asociados no aportan claridad. Hay una increíble dejadez a la hora de mostrar ejemplos de requisitos. El significado de los conceptos se basa tanto en el propio concepto como en las instancias que asociamos a él. Los ejemplos de requisitos son instancias del concepto de requisito. Lo que se ve por ahí es de muy poca calidad. Por ejemplo, el libro de Leffingwell ofrece pocos ejemplos de requisitos. Existe un desarrollo parcial en el anexo y ciertas referencias indirectas cuando se trata de ver los atributos de los requisitos. Los requisitos que se muestran a continuación están extraídos del libro de Leffingwell. Estos requisitos ni son problemáticos ni son representativos del verdadero trabajo de un ingeniero de requisitos. No supone ningún problema obtenerlos y no hace falta escribir un libro para explicarlos. Pueden suponer menos del 1 por mil de los requisitos de un sistema.

Requisitos

15

Es también curiosa la explicación que aparece en el caso de estudio propuesto para el curso “Rational Requirements Management with Use Cases Version 5.5”. El caso de estudio es un ejemplo de un ascensor. En la segunda página contiene la siguiente nota:

“Disclaimer: This is a fictitious system and does not claim to be a model for a good Software Requirement Specification. It is used for exercise purpose only.”

Bueno, si uno vende una herramienta con un curso lo menos que puede hacer, ya que la herramienta es cara, es proporcionar espléndidos ejemplos.

La especificación que se propone es un modelo de cómo no deben hacerse especificaciones.

La realidad es que toda la literatura de requisitos, toda, se propone para resolver el desarrollo de sistemas complejos y, en el mejor de los casos, se escenifica con ejemplos que ni son complejos ni son problemas. No se conoce software problemático de cajeros automáticos ni de ascensores. El software problemático siempre es de otro tipo de sistemas. Los sistemas de información en los que las interacciones están vinculadas a interpretaciones significativas para las personas humanas.

Como consecuencia de todo lo anteriorComo consecuencia de todo lo anteriorComo consecuencia de todo lo anteriorComo consecuencia de todo lo anterior se produce un error generalizado en la forma de abordar los requisitos en el desarrollo de sistemas de información. Un sistema de información intercambia información, en forma de mensajes, con su entorno. Ni más ni menos. Los requisitos esenciales de un sistema de información son el conjunto de mensajes que el sistema requiere. Esto no parece preocuparle al mundo de los casos de uso.

1.5 ��

El problema de la ausencia de visión externaausencia de visión externaausencia de visión externaausencia de visión externa es difícil de solucionar. Puede llegarse a una solución aproximada. Si por ejemplo hablamos de sistemas de información la visión externa está definida por las necesidades de información de los usuarios. No por como manipulan un programa. Pero, incluso con una visión comunicativa y externa, no es fácil establecer las verdaderas necesidades de información que una persona requiere para su trabajo. Entramos en el mundo de los significados, de la semiótica y hacen falta consideraciones no técnicas para resolver este problema.

Frente al problema de la no estructuración de los requisitos sería no estructuración de los requisitos sería no estructuración de los requisitos sería no estructuración de los requisitos sería bueno disponer de una taxonomía de requisitos que permitiera clasificarlos y estructurarlos adecuadamente. Que permitiera conocer cuales son las omisiones. Por dónde puede encaminarse la búsqueda. Qué estamos dejando de lado.

Frente al problema de los diferentes tipos de sistemas diferentes tipos de sistemas diferentes tipos de sistemas diferentes tipos de sistemas sería conveniente ofrecer estrategias de análisis diversas. No es posible que exista un método universal que sirva para todo.

Frente al problema de la ambigüedad de ambigüedad de ambigüedad de ambigüedad del concepto l concepto l concepto l concepto sería bueno disponer de definiciones menos ambiguas. Más rigurosas. Que permitieran que los ingenieros adquirieran seguridad en el uso de los conceptos. Toda definición subjetiva de un concepto como “un requisito define el qué hace el sistema y no el como” impide fundamentar actividades de ingeniería. Si cada persona puede interpretar de forma diferente el mundo que observa no podemos hablar de una ingeniería de requisitos. Más bien se trataría de una artesanía. Lo que realmente es. Las especificaciones de requisitos dependen más de la capacidad de las personas que de los métodos existentes.

Requisitos en Sistemas de Información

17

2222---- Requisitos en SistRequisitos en SistRequisitos en SistRequisitos en Sistemas de Informaciónemas de Informaciónemas de Informaciónemas de Información

Los requisitos no tienen la simplicidad estructural ni la homogeneidad que proponen la mayoría de manuales. Se definen en diferentes ámbitos y con diferentes niveles de detalle. Consideraremos las siguientes facetas para tipificar requisitos:

1. Entradas y salidas: Los requisitos de un sistema de información están esencialmente constituidos y organizados entorno a los mensajes de entrada y de salida que el sistema requiere para cumplir sus funciones.

2. Eventos y objetos: Los requisitos de un sistema de información pueden derivarse de expresiones que describen de dos maneras la realidad. Expresiones en las que se describen los fenómenos del mundo como objetos a través de sus propiedades características o expresiones sobre los cambios que se producen en los objetos del mundo.

3. Los ámbitos: definen diferentes niveles desde los que se pueden considerar los requisitos. Todo requisito debe adscribirse a un tipo de componente o encapsulamiento sistémico. En principio consideraremos tres ámbitos distinguidos: áreas de negocio, procesos de negocio e interacciones comunicativas.

4. Genericidad de un requisito: Los requisitos se expresan en un cierto ámbito pero pueden ser genéricos o específicos. Los requisitos de cualquiera de los ámbitos presentados deben concretarse mediante requisitos más específicos. Existen dos formas de concreción de requisitos: la propagación y el refinamiento.

• Un requisito es propagable cuando afecta a una clase de elementos de un ámbito. Por ejemplo:”en el proceso de facturación todos los importes se calcularán con una precisión de 9 decimales” es un requisito expresado en el ámbito del proceso de facturación propagable a todas las definiciones de dominio para atributos de importe.

• Un requisito es refinable cuando se puede concretar mediante una colección de requisitos de ámbito menor. Por ejemplo, un requisito de un mensaje de entrada (Suceso 3 “El sistema permitirá la asignación de vehículos y conductores a las hojas de expedición”) se debe refinar mediante requisitos que definan la comunicación y la reacción del suceso. Un suceso es un requisito. Lo que ocurre es que es un requisito

complejo. Los requisitos complejos se refinan dando lugar a una estructura compleja de requisitos.

5. Criterios de satisfacción

• Objetivos: Independiente de las personas que la verifican. En ese caso existe alguna métrica específica, algún procedimiento normado para comprobar que el requisito se ha satisfecho.

• Subjetivos: Dependiente de la persona que aplica el criterio. El criterio es interpretable. Ya no es una propiedad del requisito sino una propiedad de la relación entre la persona y el requisito.

2.1 ��

El problema del análisis de requisitos es tan trivial como preguntar a los usuarios que información necesitan conocer y como quieren verla.

La necesidad de una organización es la información, el disponer de ella. El jefe de compras de una empresa querrá saber las previsiones de ventas de las próximas semanas para poder establecer la política de compras. El jefe de fabricación querrá conocer el detalle de los pedidos existentes para poder planificar las órdenes fabricación. El director comercial querrá conocer la variación en las tendencias de pedidos de sus clientes para poder gestionar eficazmente su política de ventas.

La información es requerida por diferentes miembros de una organización para poder tener un mejor control y eficacia en las funciones que debe acometer.

Si todas estas personas pudieran prescindir de la informática serían felices. Su necesidad es saber su problema como poder disponer de este conocimiento. Es decir un sistema de información tiene valor porque ofrece información adecuada para el desempeño de las funciones de la organización. El sistema de información tiene el inconveniente de que requiere que se le comuniquen todos aquellos hechos que luego se quieren conocer. Esas suele ser, desde el punto de vista de los usuarios, el mayor inconveniente. Introducir los datos.

Es decir, la esencia de un sistema de información son los mensajes de salida que tiene que proporcionar a los miembros organización para facilitar les su trabajo.

Para poder suministrar estos mensajes de salida habrá que definir que mensajes entrada son necesarios. Es decir cómo queremos disponer de información habrá que organizar una red de chivatos que se ocupen de capturar y obtener la información que necesitamos

2.1.1 El SI como sistema de comunicacionesEl SI como sistema de comunicacionesEl SI como sistema de comunicacionesEl SI como sistema de comunicaciones

Un SI es un subsistema de un sistema social responsable de proporcionar a los actores que lo requieran los datos necesarios para poder acometer sus funciones.

Existen dos intenciones de comunicación en el ámbito del sistema de información.

� Poner en conocimiento del sistema la existencia de nuevos fenómenos que han ocurrido

en el sistema objeto. Se trata de los mmmmensajes de entradaensajes de entradaensajes de entradaensajes de entrada o sucesos constructores.

� Obtener información sobre los hechos conocidos por el sistema. Los mmmmensajes de salidaensajes de salidaensajes de salidaensajes de salida

o sucesos consultores.

Los procesadores de entrada y salida que propone el modelo ISO son responsables de entablar estas comunicaciones.


19

��!� "��#�� $� �� %�� &��%�'��(�

Los mensajes de entrada se obtienen mediante la red de adquisición de información que el sistema despliega. Supone el estudio, a diferentes niveles comunicativos, de los modos, tiempos y recursos más adecuados para captura la información. El subsistema de adquisición de información debe estar adaptado al quehacer organizacional.

El sistema de información debe tener mecanismos que le permitan conocer los cambios que se producen en el sistema objeto.

��)� *�%��'�'�� '��'��%��+#��

Cuando un cambio se ha producido en el sistema objeto, cuando algo sucedesucedesucedesucede, , , , cuando ocurre un sucesosucesosucesosuceso, algún agente del sistema debe informar de lo sucedido. En ocasiones puede transcurrir un tiempo entre la ocurrencia de las cosas y su comunicación al sistema. En cualquier caso la información sobre lo sucedido debe llegar de alguna forma a la frontera del sistema de información. Debe llegar a su entorno que pertenecerá al sistema social.

Hablaremos de mensajes de salida o sucesos de consulta para referirnos a las comunicaciones que el sistema ofrece a los diferentes actores sociales cuando lo solicitan. En tal caso el sistema se convierte en un emisor que transmite a los actores representaciones del conocimiento que acumula. Aquí la comunicación no viene determinada por la observación directa del sistema objeto. Se trata de una necesidad de información para el desempeño de alguna función específica.

��,� *�%��'�'�� '��'�%��'�%�� %�� &��%�'��

Es de gran importancia para el análisis de sistemas de información la conciencia de las actitudes comunicativas. El analista debe comprender el contexto de los mensajes comunicados entre usuarios y sistema. Es decir, debe comprender el significado que cada mensaje tiene para los diferentes tipos de usuario.

2.2 ��

Los fenómenos que observamos del mundo son complejos y de carácter dinámico. Los seres humanos observan estos fenómenos sabiendo que son procesos pero los perciben y describen estáticamente. Nuestras limitaciones cognitivas nos llevan a considerarlos de forma estática o discreta. La evidencia del carácter dinámico de las cosas está presente desde los filósofos presocráticos.

��( Taxonomía de procesos de Sowa

Una observación sobre el mundo es una correspondencia entre procesos y propiedades. Aunque el mundo pueda estar constituido por procesos sólo sabemos describirlo en términos de objetos y propiedades.

Para Jon Sowa los procesos pueden ser continuos o discretos. Estos últimos están constituidos por los eventos y por los estados.

El único aspecto que percibimos de los procesos es su variabilidad. Variabilidad que detectamos pero que no siempre identificamos. Cuando observamos una catarata somos conscientes de percibir un proceso. Sin embargo no somos capaces de identificar estados. Nuestra capacidad descriptiva está limitada por nuestra capacidad de identificación de cosas. Como no disponemos


21

de identificadores para las gotas de agua no podemos dar una descripción de estado compositiva de la catarata. Nuestra percepción se limita a predicar propiedades estadísticas de las componentes como el caudal.

2.2.1 Percepción de Eventos e individuos.Percepción de Eventos e individuos.Percepción de Eventos e individuos.Percepción de Eventos e individuos.

La composición de objetos y propiedades es una forma de ver o intuir los procesos. Un proceso es un fenómeno dinámico en el que somos capaces de percibir objetos relacionados. Percibimos que existen patrones de relaciones entre objetos que se repiten en el tiempo con ciertas analogías. Esa percepción es nuestra intuición de los procesos. No sabemos si existe un único proceso universal. Creemos que existen diferentes procesos que no se influyen o que están débilmente influidos.

Nuestra observación se limita a aislar aquellas características relacionadas que pensamos que describen un proceso. Nuestras limitaciones cognitivas se traducen en una fragmentaciónfragmentaciónfragmentaciónfragmentación continua de los fenómenos.

Dos son las percepcionespercepcionespercepcionespercepciones que tenemos de los procesos: Eventos e individuos.

Un individuo, un objeto, es el resultado de la observación de un proceso en el que no somos capaces de percibir fluctuaciones o no tenemos la capacidad o el interés de constatarlas (aunque a veces podamos suponer que ese individuo podrá cambiar en otras observaciones). Así percibimos una montaña como un individuo, un objeto estático. Aunque sabemos que un monte como el Everest está cambiando continuamente.

Un evento es el resultado de una observación de un proceso en la que somos capaces de percibir fluctuaciones que describimos mediante propiedades.

Cuando una organización se dota de un sistema de información los fenómenos en el sistema objeto pueden ser percibidos de forma estática o dinámica. Incluso un mismo tipo de fenómenos puede ser percibido estáticamente por unas personas o dinámicamente por otras.

Ambos tipos de fenómenos están relacionados. Todo fenómeno estático es siempre generado por, al menos, un fenómeno dinámico. Podemos considerar a las personas como un fenómeno estático (una entidad persona) o como el resultado de fenómenos dinámicos (nacer... morir).

Las percepciones dependen de su relación con los tipos de fenómenos en cuestión.

Individuos y eventos son formas complementarias de nuestra percepción del mundo.

2.3 ��

��-� .%+�� (�


23

2.3.1 EEEEl ámbito sistemal ámbito sistemal ámbito sistemal ámbito sistema

Las descomposiciones iniciales de un sistema tienen siempre la intención de reducir la complejidad. Este tipo de refinamientos se denomina también functional breakdowns.

Cuando refinamos un sistema podemos utilizar criterios diversos. Orgánicos: las interacciones que se dan en un determinado departamento. Funcionales: las interacciones que pueden ocurrir para llevar a cabo una determinada gestión. Temporales: las interacciones que tienen lugar antes de que se celebre un evento, las que pueden ocurrir durante su celebración y las que pueden ocurrir una vez finalizado. Objetuales: las interacciones que afectan a un tipo de objeto dado. Es posible, incluso, cambiar el criterio cada vez que procedemos a un refinamiento.

La intención de reducción de complejidad conduce a subsistemas cuyas componentes no son interacciones básicas, no son sucesos, ni requieren un orden temporal entre ellas, aunque pueda existir. Por ejemplo en una organización el subsistema o área de comercial compuesta por la gestión de pedidos, la gestión de compras y la gestión de incidencias nos permite abordar el estudio de cada una de ellas de forma prácticamente independiente de las otras, satisfaciendo así el criterio de reducción de complejidad.

2.3.2 El ámbito de proceso.El ámbito de proceso.El ámbito de proceso.El ámbito de proceso.

Los procesos de negocio están siempre vinculados a eventos e individuos. Un proceso describe el conjunto de cambios, sucesos comunicativos, a los que se somete un determinado individuo que denominamos objeto de negocio. El término objeto de negocio no coincide con el concepto de objeto que se utiliza para el modelado de datos. Los objetos de datos, las clases de objetos, son formas fragmentarias mediante las cuales podríamos representar un objeto de negocio. Un objeto de negocio es una estructura de información compleja que para los usuarios adquiere sentido por su composición y propiedades y por los procesos que lo manipulan.

Pueden ser objetos de negocio un pedido, una factura, un expediente de licitación o un préstamo. Cada uno de estos objetos de negocio podría ser descrito mediante un modelo de datos compuesto por varias clases de objetos. En realidad los objetos de negocio corresponderían más bien al concepto de esquema externo o de vista utilizado en las bases de datos.

El proceso supone una ordenación en el tiempo de los diferentes cambios que puede sufrir el objeto de negocio hasta que se considera finalizado.

En el ámbito de los procesos consideraremos por lo tanto dos aspectos complementarios:

• El conjunto de cambios, aportaciones de valor o eventos que un objeto puede sufrir

• La estructura y características, es decir el estado, del objeto de negocio que se procesa

Los requisitos asociados a un proceso están constituidos fundamentalmente por mensajes de entrada y mensajes de salida.

o Las diferentes entradas que informan de los cambios que se producen en un objeto de negocio.

o Las diferentes salidas que informan de estos cambios a quien lo necesite.

o Las diferentes salidas que dan una visión del estado de los objetos de negocio que están siendo o han sido procesados en algún momento dado.

.1.1.1.1 Sistema, Areas y Procesos.Sistema, Areas y Procesos.Sistema, Areas y Procesos.Sistema, Areas y Procesos.

Sistemas, áreas y procesos constituyen una forma de descomponer un sistema mediante diferentes niveles de abstracción. Los sistemas pueden componerse de áreas. Las áreas pueden componerse a su vez de otras áreas menores o de procesos. Sistemas, áreas y procesos se utilizan cuando los sistemas son complejos y necesitamos compartimentar obteniendo partes más pequeñas y manejables.

La delimitación de las áreas es subjetiva. Diferentes personas podrían ver diferentes organizaciones de áreas en una misma organización.

La delimitación de los procesos es también subjetiva. Diferentes personas podrían incluir más o menos interacciones en cada proceso.

Pero los procesos marcan un nivel de fractura importante en el sistema. Contienen como elementos componentes las interacciones comunicativas básicas del sistema. Esas interacciones ya no pueden descomponerse más sin pérdida de sentido.

2.3.3 El ámbito de las interacciones comunicativas.El ámbito de las interacciones comunicativas.El ámbito de las interacciones comunicativas.El ámbito de las interacciones comunicativas.

Delimitar adecuadamente el ámbito de las interacciones es de gran importancia para el establecimiento de los requisitos. En sistemas de información para la gestión, las interacciones entre el sistema y el entorno son comunicaciones que se establecen intercambiando mensajes.

Estos mensajes están asociados a sucesos constructores que comunican la ocurrencia de nuevos acontecimientos en el sistema objeto que interesa a una organización. Los procesos de negocio tienen que ver sobre todo con los cambios que se producen en un objeto de negocio y, por tanto, con los sucesos constructores que informan de los cambios que se producen en el mundo.

En las comunicaciones que se establecen entre el entorno y el sistema de información aparecen, de forma esencial, tres de las funciones comunicativas establecidas por el lingüista ruso Roman Jakobson.

• La función de contacto porque la comunicación de todo mensaje requiere el establecimiento previo de una conexión, una toma de contacto.

• La función descriptiva porque el objetivo de las comunicaciones en los sistemas de información es describir fenómenos que ocurren en el sistema objeto.

• La función de influencia porque la organización diseña sus comunicaciones para poder reaccionar, según sus propósitos, ante los fenómenos que ocurren.

Cada interacción comunicativa es un requisito para el sistema que habrá que desarrollar. Es un requisito genérico que debe ser refinado a través de una estructura dictada por esas tres funciones: contacto, descripción e influencia.

Esos tres aspectos están vinculados a la idea de evento o suceso habitual en el modelado conceptual.

Un suceso comunicativo es una interacción de comunicación entre el entorno y el sistema de información. El suceso comunicativo tiene lugar porque algo ha ocurrido en el sistema objeto de interés que la organización observa. Algún agente del entorno organizacional ha tenido conocimiento del fenómeno ocurrido y lo comunica a la organización que dispondrá de un canal específico para ello. Cuando la organización conoce esta comunicación reacciona según reglas y protocolos establecidos.

Un suceso comunicativo, una interacción comunicativa requiere:

• Que un agente contacte con el sistema para establecer una comunicación. Es lo que

denominamos estímulo o disparodisparodisparodisparo del suceso.

• Que el agente confeccione una descripdescripdescripdescripciónciónciónción del fenómeno que ha observado o del que ha

tenido noticia y la transmita por el canal establecido.

• Que el sistema reaccionereaccionereaccionereaccione como esté establecido al conocer que ese fenómeno que le

interesaba ha ocurrido.


25

2.3.4 El ámbito de usoEl ámbito de usoEl ámbito de usoEl ámbito de uso

Suponga que usted acude al servicio de correos para poner un telegrama. Lo primero que tiene que hacer es localizar dónde puede realizar esta gestión. Posiblemente deba usted además proveerse del formulario correspondiente.

Una vez haya localizado el entorno adecuado es posible que requiera usted ciertas informaciones previas que podrían afectar a la forma o al contenido de su mensaje. Por ejemplo la lista de precios. Imagínese que los precios van por bloques de palabras. Usted intentará maximizar el uso del bloque.

Comenzará un proceso editorial en el que usted participará como aportador de información escribiendo el mensaje en el formulario previsto para ello.

El proceso editorial continuará con la colaboración de alguna persona de correos que procederá a un cambio de formato introduciendo el texto que usted le proporcionó mediante un teclado en algún artefacto específico.

Esta persona realizará ciertas validaciones. Comprobará, por ejemplo, que la población a la que usted quiere enviar su mensaje existe o que el país al que usted pretende enviarlo dispone de servicio telegráfico.

Calculará el importe contando las palabras y aplicando la tarifa correspondiente. Registrará en algún soporte los datos que la organización de correos considere necesarios. Probablemente registre los datos del emisor, del receptor, el importe cobrado, la fecha y día de la operación.

Por último emitirá un recibo y una copia del mensaje enviado que le serán entregados para acreditar la operación.

La serie de actividades descritas en este ejemplo son habituales en cualquier interacción de un sistema de información; independientemente de los tipos soportes.

Como vemos en el ejemplo anterior, la descripción de sucesos tiene dos ámbitos descriptivos: los requisitos del dominio del problema y los requisitos del entorno de uso.

Cuando nos movemos en el ámbito del problema la cuestión se centra en identificar las interacciones, los mensajes asociados y la reacción del sistema frente a esos mensajes.

Cuando trabajamos en el ámbito de la solución la cuestión se centra en ofrecer un soporte eficiente a la comunicación. Pero podemos observar que aparecen requisitos que en el domino del problema, en el modelo del negocio, ni se plantean. ¿Cómo encuentra un usuario de mi servicio la ventanilla adecuada? ¿Cuantos recursos son necesarios para cumplimentar un cuestionario? El entorno de uso incorpora aspectos pragmáticos que en el entorno del negocio resultan accesorios.

Una de las principales características del entorno de uso es facilitar la edición de los mensajes. Hasta tal punto que una interfaz puede considerarse un mero editor de estructuras. De hecho es lo que el usuario percibe. El usuario no desencadena sucesos sino más bien procesos editoriales que permiten construir mensajes que se comunican al sistema. La mayor parte del tiempo que un usuario pasa ante una interfaz la dedica a la edición. Por ello el concepto base de nuestra aproximación es el contexto editorialcontexto editorialcontexto editorialcontexto editorial.

Un contexto editorial identifica un editor de estructuras para uno o más sucesos de usuario. Cuando un contexto editorial se utiliza para varios sucesos de usuario es porque existe compatibilidad estructural entre ellos. El caso más típico de un contexto editorial es la agrupación de los sucesos de alta, consulta, modificación y borrado para una clase.

De forma general consideraremos que los requisitos del entorno de uso tienen que ver con los tres aspectos siguientes:

• �� /�� +��'��0��'�� '��'��1�'�� %��#��'�%��'��234�$��1��'��56��'��0��'�� +#��'��&��'��23�'��0��

��'��7��(8(56(� �� '��0��'��9�� %�� %��#��$:��1�0�'�� :�'�%��'��%�(�

• �� /��1��0�� '��&��%�'��'�� &��'��''�� 2��'��6(��'��'��1�� '��1�� $:��:�� +��;�� &��'�� $� �� <� ��'��%�� $� �� '�%+�� %��%��#��(�

• �� /�� '��4��&��0� �� '�� '�%��'�'��&�'��1�� %��#��1�'�� ''�� %�(�

2.3.5 El ámbito de la infraestructura tecnológicaEl ámbito de la infraestructura tecnológicaEl ámbito de la infraestructura tecnológicaEl ámbito de la infraestructura tecnológica

Las aplicaciones requieren de un soporte sobre el que se despliegan e instalan que deben garantizar parte de esa continuidad. Por soporte físico entendemos el hardware, el software de base (sistema operativo, sistemas de gestión de base de datos, servidores de aplicaciones, etc.) y las relaciones entre todos ellos. La infraestructura tecnológica tiene al menos dos aspectos. La arquitectura lógica de componentes software, que supone la elección de un determinado framework para el desarrollo y la arquitectura física en que se ubican estas componentes.

En el momento actual la arquitectura para infraestructura es objeto de amplio debate y existen diferentes propuestas al respecto.

Quizá uno de los criterios a establecer es el diseño de acceso a los datos, el control de redundancia y la optimización de base de datos.

Aquí la problemática está guiada por dos aspectos:

• Uno que afecta directamente a los usuarios. El rendimiento: la forma en que elegimos las componentes físicas y lógicas para que se adecuen a los requisitos de rendimiento.

• Otro que afecta a los desarrolladores pero también, a la larga, a la economía de los clientes. El diseño: la elección que hacemos de la arquitectura de componentes para disponer de un sistema cohesivo y poco acoplado. Es decir fácilmente modificable o mantenible.

Interacciones externas

27

3333---- Interacciones externasInteracciones externasInteracciones externasInteracciones externas

3.1 ��

El objetivo esencial de una especificación de requisitos es definir el conjunto de interacciones externas que el sistema requiere. Para que el concepto de interacción externa tenga calidad es necesario separarlo de todos los aspectos internos. Pero además es necesario saber cual es la granularidad mínima o la unidad de las interacciones externas. Por ejemplo “entrar nombre” ¿debe considerarse una interacción externa? Posiblemente no. Es externa pero carece de unidad comunicativa si siempre va acompañado de la comunicación del cif, los apellidos y la dirección.

El nombre no constituye una intención comunicativa sin el recurso de los demás datos.

En los sistemas existe un nivel de fractura externo/interno que debe aclararse conceptualmente. Las interacciones de un sistema requieren dos características:

• La externalidad: la interacción se establece entre el sistema y algún elemento del entorno. No entre diferentes componentes del sistema.

• La unidad: la interacción tienen sentido en sí misma y se considera completa. No se trata de una parte de otra interacción mayor.

3.2 ��

Un sistema es en sí un encapsulamiento, una forma de “poner cosas juntas” o de agregar fenómenos. También lo son los subsistemas en que decidamos descomponerlo. Cada vez que consideramos algo como un encapsulamiento es porque no queremos considerar su interior y decidimos fijarnos en sus relaciones externas.

3.2.1 RefinamientosRefinamientosRefinamientosRefinamientos

Para tratar con sistemas complejos recurrimos a la descomposición. Una de las formas más conocidas y utilizadas para descomponer sistemas es el método de los refinamientos sucesivos. Esto produce una jerarquía de descomposiciones.

��

��

��

��

��

��

��

��

��

��

��

�� =��;�� &��%��

Cuando refinamos un sistema podemos utilizar criterios diversos. Orgánicos: las interacciones que se dan en un determinado departamento. Funcionales: las interacciones que pueden ocurrir para llevar a cabo una determinada gestión. Temporales: las interacciones que tienen lugar antes de que se celebre un evento, las que pueden ocurrir durante su celebración y las que pueden ocurrir una vez finalizado. Objetuales: las interacciones que afectan a un tipo de objeto dado como un pedido o una factura. Es posible, incluso, cambiar el criterio cada vez que procedemos a un refinamiento.

La descomposición de complejidad, el refinamiento de un sistema, define una jerarquía de subsistemas donde cada uno de ellos tiene un criterio particular de encapsulamiento. Como siempre los criterios de encapsulamiento de un subsistema responden a alguna intención. Por ejemplo, si agrupamos funciones organizacionales con un criterio orgánico nuestra intención es establecer una política de responsabilidades y competencias respecto a los recursos organizacionales.

El nivel de los procesos de negocio determina el último nivel de refinamiento posible para interacciones externas de un sistema.

3.2.2 Confusión externa/internaConfusión externa/internaConfusión externa/internaConfusión externa/interna

Imagínese que acude a un restaurante y en el menú aparecen líneas que se refieren a platos que usted puede pedir y líneas que corresponden a componentes de algún plato.

Por ejemplo:

• Arroz tres delicias

• piñones

• Bistec al oporto

• una cucharadita de jerez


29

• Ensalada de brotes de soja

• Zanahoria rallada y rodajas de remolacha

El menú está mezclando interacciones -arroz tres delicias, bistec al oporto, ensalada de brotes de soja- con componentes -jerez, zanahoria, piñones. Al cliente le interesa saber cual puede ser su elección. Al cocinero le interesa saber para cada elección cual es su composición.

Esta confusión de intenciones es habitual en la mayoría de técnicas que usamos. La confusión de interacciones y componentes sólo puede conducir a dificultar la comprensión del sistema.

Si pensamos por ejemplo en sistemas información, el refinamiento de la diversidad nos lleva a la definición de todas las opciones requeridas por el sistema. Lo que podríamos llamar el menú de la aplicación.

En la figura inferior aparece una descripción basada en la técnica del análisis estructurado [DeMarco 1979]. Esta técnica propicia la confusión de interacciones y componentes.

��>� *��&�� ''��$�'�%��(�

La figura muestra un refinamiento de un proceso superior: gestión de actividades. El refinamiento debería haber conducido a tres interacciones: alta de actividad, baja de actividad y listar actividades. El diagrama mezcla relaciones externas y relaciones internas.

Imagínese que un libro de cocina tuviera una página que se denominará arroces de pescado. Y que en esta página se describieran al mismo tiempo y de forma entremezclada tres recetas diferentes de arroz. El sentido común del lector debería saber cuando cada instrucción se refiere a cada una de las tres recetas. Eso es exactamente lo que muestra el gráfico anterior.

El caso del análisis estructurado es especialmente singular. El diseño estructurado ha convertido esta confusión conceptual en un cuerpo de recomendaciones heurísticas que gozan de crédito en muchos planes de estudio de informática.

3.2.3 Refinamientos de interacciones externas e internas.Refinamientos de interacciones externas e internas.Refinamientos de interacciones externas e internas.Refinamientos de interacciones externas e internas.

Cuando un sistema es complejo utilizamos técnicas para reducir la complejidad y tratar con subconjuntos de interacciones menores y más manejables. Esto es una descomposición. Pero no una descomposición del sistema en sus elementos constituyentes sino una partición de "todas las interacciones del sistema" en conjuntos menos complejos de interacciones.

El contrasentido proviene de la ambigüedad del término descomposición. Descomponer tiene, al menos, dos acepciones.

La composición constitutiva o agregada en la que un conjunto de componentes se organizan o estructuran para dar lugar a una componente compleja. La composición constitutiva requiere coincidencia espacio-temporal.

La composición varietal o electiva en la que se consideran todas las posibles variedades de interacciones que puede admitir un sistema. Las variedades que pueden darse en un sistema no requieren la coincidencia en el espacio y en el tiempo.

La composición varietal tiene que ver con la elección, con la abstracción de generalización-especialización. La composición constitutiva tiene que ver con la constitución con la abstracción de agregación/descomposición.

Por ejemplo, formular un pedido y dar de alta una maquina en un taller son dos componentes posibles de un sistema. Pero no se requieren mutuamente. No necesitan coexistir en un momento y lugar. Puede darse una interacción sin que se de la otra. Dar de alta una máquina en un taller lo consideramos un fenómeno completo. Puede ocurrir sin el recurso de otros fenómenos.

Un pedido se compone del cliente que lo formula y de los productos que solicita. Esta composición es estricta. No podemos prescindir de ninguno de los elementos sin que pierda sentido el todo. Las componentes “cliente que formula el pedido” y “productos solicitados en el pedido” no son independientes y deben coexistir en el espacio y en el tiempo. El pedido está constituido por todos esos elementos o componentes. Si alguno no está presente el pedido no puede considerarse un fenómeno completo.

Cuando describimos la composición de un coche suponemos que todas las componentes están presentes en el mismo instante y lugar para que el sistema coche mantenga su significado pleno. Un coche sin motor, sin ruedas o sin puertas está incompleto. El cliente de un concesionario de automóviles difícilmente aceptará que le entreguen un coche incompleto.

Cuando vamos a un concesionario de automóviles y nos entregan un catálogo no pensamos que el catálogo sea una composición. Más bien lo vemos como una oferta de posibles elecciones. Son las variantes de interacción. Nuestra interacción de compra supondrá elegir uno de los modelos que oferta el catálogo. Es posible que nos entreguen un catálogo viejo, que no contenga el último modelo o que no esté totalmente actualizado. Sin embargo seguiremos considerándolo un catálogo. El hecho de que no esté actualizado sólo será un ligero inconveniente. Sobre todo si no afecta a la serie de modelos que nos interesa. Así como todos los clientes rechazarían un coche sin puertas la inmensa mayoría aceptaría un catálogo desactualizado. Puesto que se trata de un procedimiento de elección la ausencia de partes no invalida el proceso. Sólo bajo requisitos estrictos de optimización sería problemática la ausencia de partes.

3.3 ��

3.3.1 ComunicacionesComunicacionesComunicacionesComunicaciones

A finales del siglo XIX un lingüista llamado Charles Sanders Peirce sugiere que las palabras que intercambiamos tienen un significado que no está en ellas mismas sino que depende de la relación entre las entidades que se comunican. Las ideas de Peirce constituyen el origen de la semiótica [Peirce 1894]. Peirce establece tres grados de percepción sobre las palabras, sobre los signos. Las palabras nos interesan en una forma primaria por sí mismas, tiene además un interés secundario porque actúan como indicadores de otras cosas y tiene un tercer grado de interés en la medida en que se relacionan con nuestras ideas. Peirce denomina esta tercera forma de percibir


31

“mediación”. El significado de las palabras depende de la relación que tienen con nuestras ideas, con nuestro conocimiento.

En 1948 Claude Shanon propone el modelo de Sistema de Comunicación [Shanon 1948].

�� "� �� %�� '�%��'�'�� 4��

Un sistema de comunicación, según el modelo de Shanon, tiene cinco partes esenciales: la fuente, el transmisor/codificador, el canal, el decodificador/receptor y el destinatario. La visión de Shanon que trabaja como ingeniero en una compañía telefónica, se preocupa solo de la transmisión de mensajes y no de su significado. Pero su modelo está en la base de los modelos que actualmente utilizamos. Toda comunicación requiere un emisor (la fuente), un receptor (el destinatario) y un medio (el canal). Es necesario que el emisor codifique el mensaje que quiere comunicar usando algún sistema de codificación, un lenguaje, compartido entre el emisor y el receptor. Los mensajes adoptan por tanto una forma codificada convencional que se transmite por un canal.

��

"��#��

�� 8��'�%��'�'��%� ��'��

En 1960 otro lingüista, Roman Jackobson, propone un modelo comunicativo que asume las ideas anteriores. Señala la importancia del contexto social como base del significado. Proponiendo un modelo basado en la existencia de un contexto compartido entre los participantes en la comunicación. El significado del mensaje no está en el propio mensaje sino que depende de convenciones sociales.

El concepto de contexto social se conoce hoy día como conocimiento compartido (shared knowledge). El significado del mensaje depende del conocimiento compartido entre emisor y receptor. Solo en la medida en que emisor y receptor compartan las percepciones e ideas que tiene sobre los fenómenos es posible alcanzar un significado compartido.

�� '��9��'�%��'��'�%��'�%��

Por eso para Langefors el SI se limita a adquirir, almacenar o diseminar expresiones lingüísticas. El SI solo es el soporte de la comunicación. El significado de esas expresiones lingüísticas variará en función del conocimiento de quien las interprete.

Jackobson propone además seis intenciones para caracterizar las funciones del mensaje.

��'�� '�� #�%��?��'��1�� ?��'��+��:� ��&��%��(� ��

��(��@��1��

�%��1��

�9�� %�� '�� %��(�

A"� �� B� ��@� �1�� 1�0��

��&��'�� &��'�%��%�� '��(��

�� 1��(��

*��'�� +�'�� %�� '��'��(��1C�� +�'��'�%��'�'��@�&��'�� (�

D��'��1��%�$�+��&�'��E�

"��F;��'�� G�&�� 0�� '�� %��#�(�?��'��+�� %��#�(�

��&��%�� %��(�

��C��'�� G�� '��'��;��'�� 9�� %��#�(� � G��0�'�� F��'��+�'��%��@&��(�

8�� '�� %��@��%��(�

3.3.2 SucesosSucesosSucesosSucesos

El concepto de suceso comienza a utilizarse en el área de Sistemas de Información a partir de la publicación del método Merise auspiciado por el Ministerio de Industria francés. Su Modelo Conceptual de Tratamientos es la primera técnica orientada a suceso conocida en el área de Sistemas de Información.

Merise utiliza el término “évènement” para denotar un disparo o una condición de disparo de un tratamiento.

Los eventos en Merise son condiciones persistentes o instantáneas. Siempre tiene que existir al menos una condición instantánea que actúe como estímulo disparador del tratamiento.

El informe ISO/TC97/SC5/WG3 [Van Griethuysen 1982] estableció la base terminológica para sistemas de información que la comunidad científica adoptaría en la década de los 80. El informe define un evento como:

“The fact that something has happened in either the universe of discourse, or the environment, or the information system.”

En la revisión que Edward Yourdon hace del análisis estructurado, el “Análisis Estructurado Moderno”, introduce el término evento (llamado acontecimiento en la traducción al español [Yourdon 1989]).

“Un acontecimiento es un estímulo que ocurre en el mundo exterior al cual el sistema debe responder”

En 1990 se publica la primera versión del informe Frisco [Frisco 1990] que supondría la revisión terminológica más rigurosa conocida en el área.

Para Frisco un evento es

“An abstraction of a change of state in the organizational domain.”


33

En sistemas de tiempo real o en sistemas empotrados viene utilizándose desde hace tiempo en un sentido más general. En los sistemas de control no se trata sólo de estímulos externos al sistema sino también de los internos.

En los entornos de programación el término evento designa cualquier estímulo o interrupción posible en la actividad de las componentes. Como el clic del ratón o el fin de la lectura de los registros de una tabla.

En la orientación a objeto, donde prima la arquitectura de componentes, la visión del evento es también generalizada.

“Un estímulo individual proveniente de un objeto y que llega a otro es un suceso” [Rumbaugh 1991].

“En el contexto de las máquinas de estados, un evento es la aparición de un estímulo que puede disparar una transición de estado” [Booch1999].

3.3.3 Sucesos comunicativosSucesos comunicativosSucesos comunicativosSucesos comunicativos

El término evento está siempre vinculado a la comunicación. Ya sea comunicación entre componentes, entre objetos o entre el entorno y el sistema de información. Las diferentes definiciones de evento denotan una o más de las funciones comunicativas de Jackobson.

En todas las definiciones aparece una función fáctica, el contacto o establecimiento de la comunicación. El evento es el responsable del inicio de la comunicación. Es un desencadenante, un estímulo, un disparo, la causa de que se inicie un determinado comportamiento en una componente.

También aparece una función conativa que se asocia a la influencia del mensaje en el comportamiento del receptor. Refiere por tanto la respuesta del sistema ante el evento: "puede disparar una transición de estado”, “el sistema debe responder”.

Sin embargo la función denotativa, la esencia comunicativa, aparece soslayada. La definición del informe ISO es la que contiene mayor carga denotativa.

El aspecto descriptivo asociado al evento es al que menos importancia se le da. En prácticamente todas las definiciones tienen mayor preponderancia los aspectos fácticos, el disparo, y conativos, la reacción.

La mayoría de técnicas descriptivas actuales describen los mensajes por la forma en que el sistema reacciona ante ellos pero no por los mensajes en sí mismos.

La técnica de especificación de requisitos de usuario por excelencia, los casos de uso, caracteriza la reacción del sistema describiendo las acciones minimizando el carácter denotativo de las interacciones.

Utilizaremos la denominación suceso comunicativo para enfatizar la esencia descriptiva de las interacciones en los Sistemas de Información.

Esta denominación recoge la idea de que

• algún fenómeno de interés para un sistema de información ha ocurrido,

• existe una descripción conveniente de ese fenómeno

• algún agente externo conocido está dispuesto a comunicarlo a través de un canal

preestablecido en el sistema de información

• el sistema tiene prevista una respuesta para el tipo de fenómeno informado.

3.3.4 Criterios de unidadCriterios de unidadCriterios de unidadCriterios de unidad

En las diferentes definiciones de suceso podemos observar que las caracterizaciones más precisas, las que permiten prescripciones metodológicas, son las que recurren a la delimitación del suceso a partir de la respuesta que desencadena en el sistema.

No es por tanto de extrañar que los criterios de unidad del suceso se basen en los criterios de unidad de la respuesta asociada.

Cada suceso define una respuesta. En la práctica suceso y respuesta pueden considerarse una misma cosa. Si existe una relación biunívoca entre sucesos y respuestas es lo mismo hablar de las relaciones entre sucesos que de relaciones entre respuestas.

La unidad, la granularidad de los sucesos podemos también encontrarla en las respuestas asociadas.

La definición que ofrece Merise de la respuesta reactiva se recoge en el concepto de operación:

“Una operación es un conjunto de tratamientos que pueden ser ejecutados de manera continua, es decir, que tienen una misma unidad de acción y no necesitan que ocurran otras operaciones” [Collongues 1989].

Esta definición de operación contiene tres criterios:

• El designado por “de manera continua” responde al concepto de sincronismo. Las acciones

invocadas se realizan de forma continua por lo tanto deben ser capaces de comunicarse

síncronamente entre ellas. Las acciones que no puedan ocurrir síncronamente no podrán

formar parte de una misma operación. Es la interrupción de la actividad la que marca el fin de

la reacción.

• El designado por “una misma unidad de acción” introduce el criterio de un objetivo funcional

único. Es equivalente al concepto de unidad de la cohesión funcional del diseño estructurado.

[Stevens 1974]

• El designado por “no necesita que ocurran otras operaciones” establece un criterio de

impenetrabilidad modular. Una operación no se compone de operaciones. No admite

refinamientos. El criterio de continuidad o de sincronismo conduce a una visión física del suceso. Las limitaciones físicas de los entornos de procesamiento pueden forzar la terminación de la reacción. El criterio de sincronismo está condicionado a una determinada elección de los agentes de soporte de las funciones del sistema.

La definición siguiente destaca el carácter físico del criterio de sincronismo.

“Un suceso es un conjunto de actividades (de adquisición, almacenamiento, procesamiento, recuperación o distribución) de información que se realizan de forma completa e ininterrumpida, con ocasión de un estímulo externo” [González 2002]

Cuando definimos la unidad basándonos en el sincronismo estamos definiendo sucesos que reflejan actividades básicas del sistema de información. Como por ejemplo el envío de información, el almacenamiento, la validación, o los cambios de formato.

Si utilizamos criterios meramente comunicativos la unidad de la reacción está asociada a la unidad del mensaje comunicado.

Un suceso comunicativo está constituido por uno o más sucesos físicos que tienen un mismo objetivo comunicativo. Los sucesos comunicativos se asocian a los mensajes de entrada y de salida del sistema de información.

Un suceso comunicativo comprende tres actividades básicas: El estímulo, la edición del mensaje y la reacción. Cuando se trata de mensajes de entrada los procedimientos editoriales pueden ser largos y resolverse mediante diferentes sucesos físicos.


35

Los sucesos comunicativos son importantes respecto a los sucesos físicos porque se centran en las intenciones comunicativas del sistema y no en las limitaciones de la solución existente.

3.3.5 Criterios de unidad en los sucesos comunicativosCriterios de unidad en los sucesos comunicativosCriterios de unidad en los sucesos comunicativosCriterios de unidad en los sucesos comunicativos

Hemos denominado sucesos constructores a las interacciones comunicativas de entrada. Inicialmente describiremos estas interacciones por los tres aspectos comunicativos básicos: contacto, mensaje y significado es decir quién dispara, qué nueva información comunica y cómo reacciona el sistema frente a ello.

Delimitar adecuadamente el ámbito de las interacciones es de gran importancia para el establecimiento de los requisitos. En sistemas de información para la gestión las interacciones entre el sistema y el entorno son comunicaciones que se establecen intercambiando mensajes. Mensajes de entrada y mensajes de salida.

En las comunicaciones que se establecen entre el entorno y el sistema de información aparecen, de forma esencial, tres de las funciones comunicativas establecidas por el lingüista ruso Roman Jakobson.

• La función de contactocontactocontactocontacto porque la comunicación de todo mensaje requiere el establecimiento previo de una conexión, una toma de contacto.

• La función descriptivadescriptivadescriptivadescriptiva porque el objetivo de las comunicaciones en los sistemas de información es describir fenómenos que ocurren en el sistema objeto.

• La función de influenciainfluenciainfluenciainfluencia porque la organización diseña sus comunicaciones para poder reaccionar, según sus propósitos, ante los fenómenos que ocurren.

Cada interacción comunicativa es un requisito para el sistema que habrá que desarrollar. Pero es un requisito genérico que debe ser refinado a través de una estructura dictada por esas tres funciones: contacto, descripción e influencia.

Esos tres aspectos están vinculados a la idea de evento o suceso habitual en el modelado conceptual.

Un suceso comunicativo es una interacción de comunicación entre el entorno y el sistema de información. El suceso comunicativo tiene lugar porque algo ha ocurrido en el sistema objeto de interés que la organización observa. Algún agente del entorno organizacional ha tenido conocimiento del fenómeno ocurrido y lo comunica a la organización que dispondrá de un canal específico para ello. Cuando la organización conoce esta comunicación reacciona según reglas y protocolos establecidos.

Un suceso comunicativo, una interacción comunicativa requiere:

• Que un agente contacte con el sistema para establecer una comunicación. Es lo que

denominamos estímulo o disparodisparodisparodisparo del suceso.

• Que el agente confeccione una descripcióndescripcióndescripcióndescripción del fenómeno que ha observado o del que ha

tenido noticia y la transmita por el canal establecido.

• Que el sistema reaccionereaccionereaccionereaccione como esté establecido al conocer que ese fenómeno que le

interesaba ha ocurrido.

Estos tres aspectos de la comunicación ayudan a considerar los criterios de unidad de un suceso.

�( Unidad de estímulo. Cada comunicación que se establece con el sistema de información está provocada por la ocurrencia de un único fenómeno. El estímulo o el establecimiento de contacto será responsabilidad de un único agente. Es posible que la comunicación sea el resultado de la deliberación o la cooperación de un grupo. Pero en este caso el grupo suele nombrar un responsable o portavoz que se responsabiliza de la comunicación.

Las formas coordinadas o sincronizadas de disparo son poco frecuentes. Pueden aparecer en protocolos de alta seguridad como las dobles llaves para el disparo de artefactos nucleares para el mantenimiento de la paz por naciones bien intencionadas.

�( Unidad de descripción. Un suceso describe un fenómeno que ha ocurrido en el entorno. El mensaje comunicado tiene una unidad que no se puede fragmentar porque no describiría de forma completa el fenómeno. La unidad del mensaje no la determina la forma en que lo tratamos sino el fenómeno que describimos. Cuando vamos a un club a darnos de alta no tienen lugar varias comunicaciones del tipo “leer y validar_dni”, “anotar y comprobar teléfono”, etc. Hay un único mensaje que describe toda la información necesaria para poder darnos de alta en ese club.

�( Unidad de reacción. La llegada de un mensaje a la organización desencadena un conjunto de actividades “que se realizan de forma completa e ininterrumpida”. Las actividades que desencadena un suceso son síncronas. Tienen lugar en el mismo tiempo y entorno comunicativo.

Imaginé la siguiente descripción:

La administración autonómica ha organizado un procedimiento para recoger solicitudes para ayudas por daños causados por un incendio que ha asolado grandes extensiones de cultivo de almendros y frutales. Cada propietario cumplimenta una instancia con sus datos, los datos de las parcelas afectadas y el número de árboles dañados en cada parcela. Esta instancia la entrega en el ayuntamiento de su localidad dentro de los plazos establecidos. Finalizado el plazo cada ayuntamiento remite a la Conselleria las instancias recibidas. La Conselleria entrega las instancias a una empresa para que digitalice los datos. La empresa devuelve los datos y las instancias al departamento de explotación de la Conselleria que revisa los datos digitalizados y corrige los posibles errores existentes. Posteriormente se incorporan las solicitudes a la base de datos.

�� '��&;��'��


37

Podemos describir directamente los sucesos comunicativos que relata el caso. Serían los sucesos físicos que manipulan y transportan la información almacenándola, temporalmente, hasta que llega a su destino final. Se trata de los sucesos comunicativos desde el punto de vista del modelo de Shanon o del modelo de los agentes soporte. EL modelo físico.

Pero en la descripción anterior existe un único hecho comunicativo. Poner en conocimiento del sistema los daños reclamados por un propietario. Este suceso comunicativo aparece como un conjunto de sucesos físicos tal como se describe en la Figura 13 .

Es posible considerarlo un único suceso lógico tal como aparece en la Figura 14 EL analista debe ser consciente de que una organización eficiente de los soportes comunicativos debe aproximarse al modelo lógico.

Presentar Informe de Daños

Propietario

��!� ��'��'��

El mensaje existe desde el momento en que el propietario cumplimenta la instancia. El resto de sucesos físicos existen porque los soportes de adquisición son rudimentarios. Un formulario en Internet podría eliminarlos todos. A partir del primer suceso conocemos una información que ninguno de los sucesos posteriores debería alterar. Ninguno de esos sucesos añade valor comunicativo.

La unidad reactiva, la que conduce a los modelos físicos, está limitada por criterios de unidad basados en la organización de los soportes comunicativos. No deberían formar parte de un mismo suceso físico

�( Las actividades que ocurren en intervalos de tiempo diferentes y no conexos. Salvo que sincronicemos los estímulos.

• Si la actividad A ocurre a las 10 de la mañana y la actividad B ocurre a las 5 de la tarde A y B no se pueden sincronizar salvo que se modifiquen y se hagan coincidir sus estímulos. “Todas las mañanas se envía un listado de precios de compra medios del día anterior a los proveedores y al final del día se envía el resumen de ventas de cada proveedor”

• Si la actividad A debe ocurrir para que otra B pueda ocurrir y no suceden siempre al mismo tiempo no pueden formar parte de un mismo suceso. “El comité asigna el proyecto a la empresa que presenta el historial más competente y la empresa entrega una redacción preliminar del proyecto.”

• Siempre que podamos ordenar dos actividades en el tiempo y entre sus ocurrencias exista un intervalo de tiempo se trata de dos sucesos diferentes. “Las semillas se plantan en marzo en semilleros. A las tres semanas se replantan en macetas.”

�( Las cosas que ocurren en entornos comunicativos aislados. Salvo que unifiquemos los entornos.

Sobre un hecho comunicativo pueden establecerse competencias de validez y autoridad. Debemos diferenciar tres posibilidades.

• En el nivel más bajo el problema es meramente de soporte al canal de comunicación y a la codificación. Se penaliza el proceso de adquisición. Existen muchos costes en la codificación del mensaje, se utilizan varios procesos de codificación o el canal de comunicación es rudimentario. Es el caso del ejemplo anterior sobre el sistema de ayudas.

• En un nivel intermedio el problema es de asignación de competencias.

Supongamos que en una empresa se toman pedidos en el departamento de atención al cliente. Los pedidos pasan luego a almacén que los clasifica según hayan o no existencias. Si hay existencias el pedido se considera válido y puede pasar a fabricación.

Los sucesos tomar pedido y validar pedido ocurren en entornos diferentes y en tiempos diferentes. Pero es posible que se puedan unificar. Todo depende si la clasificación del pedido requiere o no de alguna interacción externa. Si el criterio de validez del pedido depende solo de la información que el sistema dispone, las existencias conocidas, los sucesos son unificables. Si se mantienen separados es por una decisión de política organizacional.

• En el nivel más alto la cuestión es de valor comunicativo aportado.

Existen sucesos que tienen una contribución comunicativa mínima. Su propio nombre es el mayor valor comunicativo, aunque siempre identifican un objeto y un instante. Por ejemplo “aprobar un proyecto”, “resolver una concesión”, “autorizar un gasto”. Se trata de sucesos donde interviene la autoridad o la competencia de un actor organizacional. Las organizaciones establecen protocolos de autorización en sus procedimientos. Determinadas decisiones deben ser refrendadas por personas con los niveles de responsabilidad adecuados. Estos actos añaden valor a la comunicación. Cuando hacemos un presupuesto para un cliente el cliente lo acepta o no. La decisión del cliente no parece aportar nada nuevo al presupuesto. Sin embargo el inicio de obras no debería ocurrir sin que haya ocurrido un suceso de aceptación. El presupuesto aceptado tiene un valor comunicativo diferente al del presupuesto sin más.

A diferencia del aparatado anterior aquí la decisión es externa y no previsible por el sistema. No podemos considerar que elaborar un presupuesto y aceptar un presupuesto sean realizaciones de sucesos físicos sobre un mismo hecho comunicativo.


39

3.3.6 Estructuras de comunicaciónEstructuras de comunicaciónEstructuras de comunicaciónEstructuras de comunicación

En el análisis de sistemas de gestión es muy importante caracterizar la estructura de información que aporta o produce cada suceso. Para ello usaremos las Estructuras de Comunicación. Se trata de una notación regular similar a la propuesta por el Análisis Estructurado para describir los flujos de información. Los constructores de que se disponen son los siguientes:

< + > Secuencia o composición

[ | ] Alternativa o especialización

{ } Iteración

Supóngase un suceso de confección de un pedido en una tienda de ordenadores; el comercial rellena el formulario de la Figura 17 a partir de la información que le proporciona el cliente; con el fin de que el cliente se pueda llevar una copia impresa que le sirva como presupuesto, se simulan los cálculos de importes que se harían en una factura. Al lado se presenta la estructura de datos correspondiente.

G��HH�� IJK ��%(�� L��&�'4�� L��&��%��L*8�� J��K '� ('��L��&L��%+��L�� ''��L��'� (��L��1��'��L��%��ML��8��J��NK '� (�� '��L�� '��'��L��'�� L

��'��L ��'��L

��%��MOL��+��%��+�L��%��1�L��&�'��L��M

��)� �#�%�� &��%��

Al esqueleto estructural de la información aportada en el suceso de confección del presupuesto podemos añadirle más contenido; dependiendo de la fase del proyecto en que nos encontremos, los elementos de la estructura de comunicación podrán tener asociada diversa información.

3.3.7 Un ejemplo trivialUn ejemplo trivialUn ejemplo trivialUn ejemplo trivial

Supongamos una descripción trivializada de las interacciones que recibe el sistema de información de una biblioteca. Es el típico ejemplo que jamás ocurre de esta forma en el mundo real pero que constituye una simplificación adecuada para presentar conceptos de forma básica.

El diagrama de la figura siguiente describe el comportamiento mediante cuatro interacciones. Existen interacciones iniciales. Mensajes que ocurren sin necesidad de que previamente haya ocurrido algo. Los mensajes asociados al deseo de una persona de inscribirse como socio y al hecho de que ha llegado un nuevo libro. Para que una persona se asocie a esta biblioteca no es necesario que nadie comunique nada previamente. Ni siquiera es necesario que se hayan registrado libros. Pero para que alguien pida un libro prestado si que son necesarias dos cosas. Que previamente se haya asociado y que el libro que pide haya sido previamente registrado.

El siguiente tipo de interacción comunicativa que puede tener lugar es la devolución de un libro. Para ello es necesario que previamente alguien se lo hubiera llevado prestado. Nótese que también es necesario que la persona que devuelve el libro sea socio y que el libro se haya registrado. Pero nos basta con expresar la condición de ocurrencia del préstamo porque si ha ocurrido el préstamo seguro que han ocurrido los sucesos anteriores. Nunca reflejamos las relaciones transitivas.

��,� ��'��'��%�� %��#��

Pero además estas interacciones están asociadas a mensajes. De hecho tenemos los siguientes tipos de mensaje:

1- Una persona se hace socio

a. Contacto: La persona que se quiere asociar

b. Comunicación: Los datos de la persona.

Persona= < Dni+ Nombre+ Dirección+ Población+ CP+ Teléfono+ Equipo+ Experiencia > Persona

c. Reacción: se registra la persona en el sistema informático. Se genera un número de socio. Se le da un carné de socio.

2- Administración registra un nuevo libro

a. Contacto: Llega un paquete de libros de la distribuidora.

b. Comunicación: los datos del libro.

Libro= < Referencia+ Título+ Autor+ Editorial+ Año de Edición+ Páginas+


41

Encuadernación+ ISBN > Libro

c. Reacción: abrir una ficha de libro, catalogarlo, colocarlo en la estantería correspondiente

3- Un socio solicita un libro

a. Contacto: El socio que solicita el préstamo

b. Comunicación: identificación del socio , identificación del libro, fecha y hora

Préstamo= < SOCIO(id)+ fecha de préstamo { LIBRO(id) } > Préstamo

c. Reacción: verificar los préstamos pendientes del socio, verificar que los libros están disponibles, buscarlos entregarlos al socio, registrar los datos del préstamo en el sistema.

4- Un socio devuelve un libro

a. Contacto: el socio que devuelve el libro

b. Comunicación: fecha de devolución e identificación de los libros que devuelve

Devolución= < fecha de devolución + { LIBRO(id) } > Devolución

c. Reacción: recoger los libros, guardarlos en la estantería correspondiente y registrar los datos de la devolución.

Fíjese que hemos utilizado las mayúsculas y la forma OBJETO (id) para indicar que, de alguna manera, identificamos elementos que ya son conocidos por el sistema. Se trata de referencias al contexto, a instancias que pertenecen al conocimiento compartido que almacena el sistema de información.

Note que no es necesario decir más. No aportamos el nombre del socio cuando se hace un préstamo. Solo comunicamos que un socio, en una cierta fecha se lleva determinado libros. Es todo lo que el sistema necesita saber para poder actuar.

Otra cosa diferente es cómo identificamos al socio. La solución que adoptemos nos puede proporcionar varias formas distintas para identificar a un socio que ha olvidado su número de socio. La esencia de la comunicación es el mensaje aportado. Los mecanismos de “ayuda editorial” para la construcción de ese mensaje forman parte del entorno de uso.

3.3.8 Completando la visión comunicativaCompletando la visión comunicativaCompletando la visión comunicativaCompletando la visión comunicativa

Pero nos interesa otra visión en la que el valor comunicativo adquiere todavía mucha más importancia.

Un Sistema de Información interacciona con su entorno mediante mensajes de entrada y mensajes de salida.

Los mensajes de entrada suponen la comunicación de nueva información que el sistema desconocía hasta ese momento. Pero cuando analizamos e identificamos un mensaje de entrada también debemos interesarnos en quién está interesado en la nueva información aportada.

De esta forma aparecen diferentes mensajes de salida vinculadas a la entrada.

.1.1.1.1 Mensajes de salidas previos a una comunicación de entrada.Mensajes de salidas previos a una comunicación de entrada.Mensajes de salidas previos a una comunicación de entrada.Mensajes de salidas previos a una comunicación de entrada.

Cuando el mensaje que tiene que comunicar un actor está asociado a una decisión puede ser necesario disponer de salidas previas que le ayuden a la toma de esa decisión. Por ejemplo, una asignación de personal a un proyecto puede requerir un listado de la ocupación del personal. La asignación de pedidos a líneas de fabricación requiere un listado de la carga existente en las líneas y un listado de la demanda de pedidos organizada por tipo de producto.

.2.2.2.2 Consultores acreditativos de constructorConsultores acreditativos de constructorConsultores acreditativos de constructorConsultores acreditativos de constructor

El suceso requiere una salida o comunicación a agentes externos. Se trata de un consultor que “certifica” la transacción realizada, normalmente será una copia de los datos capturados. Es lo que antiguamente se denominaba impresión “hardcopy”. Puede ser la expedición de un recibo, la copia de un pedido…

.3.3.3.3 Consultores informativos de un constructorConsultores informativos de un constructorConsultores informativos de un constructorConsultores informativos de un constructor

Los consultores informativos suponen la comunicación a agentes organizacionales del contenido del mensaje comunicado por un suceso.

Deberá establecerse para quién es importante conocer la nueva información o quién tendrá que reaccionar frente a esa información. En definitiva a quién es necesario y a quién conviene informar. Las preguntas básicas se formulan en este sentido.

¿Qué personas es necesario que conozcan esta información de forma inmediata?

¿Quién está interesado en conocer el contenido de este suceso?


43

��-� *��1��'�� '��'��(�

Los consultores informativos pueden tener dos objetivos diferentes. Provocar que el actor que los recibe inicie otro suceso o informar del estado de los asuntos sin responsabilidad inmediata para la ejecución de sucesos.

La organización de las interacciones

45

4444---- La organización de las interaccionesLa organización de las interaccionesLa organización de las interaccionesLa organización de las interacciones

4.1 � ��

4.1.1 IntroducciónIntroducciónIntroducciónIntroducción

Las publicaciones en el área de sistemas de información presentan la noción de comportamiento como un aspecto dinámico-temporal.

En UML el concepto de comportamiento se asocia a métodos, interacciones, colaboraciones e historias de estado:

“Behavioral models (also known as dynamic models) emphasize the behavior of objects in a system, including their methods, interactions, collaborations, and state histories.”

UML permite descripciones de comportamiento mediante cuatro elementos lingüísticos diferentes.

“The Collaborations package specifies a behavioral context for using model elements to accomplish a particular task. The Use Case package specifies behavior using actors and use cases. The State Machines package defines behavior using finite-state transition systems. The Activity Graphs package defines a special case of a state machine that is used to model processes. The Actions package defines behavior using detailed model of computation.”

El concepto de comportamiento está relacionado con diferentes técnicas expresivas. En la mayoría de los casos se asocia a aspectos temporales. Pero existen aspectos de comportamiento donde lo temporal no es tan obvio.

El comportamiento externo define relaciones entre interacciones externas. Normalmente se utilizan órdenes parciales para reflejar secuenciación temporal.

Los órdenes parciales de actividades organizacionales no son nuevos en el análisis de sistemas de información. El Modelo Conceptual de Tratamientos de Merise constituye la primera aproximación rigurosa al uso de ordenaciones temporales de sucesos.

La OMG ha propuesto una notación para modelado de procesos de negocio. Se trata del Business Process Modelling Notation o BPMN.

En general cualquier propuesta de modelado dinámico que se base en el uso de Redes de Petri puede ser utilizada para expresar órdenes parciales entre sucesos. La técnica de DFD permite un uso muy similar al modelo conceptual de tratamientos de Merise a los diagramas de workflow o a los diagramas de procesos de negocio. Los diagramas de actividad de UML admiten este mismo uso.

�� I��0�'�� '�%�� @%�'��

Es importante diferenciar entre comportamiento interno y externo. En el comportamiento externo relacionamos interacciones externas. En el comportamiento interno relacionamos componentes internas. Se trata de la misma diferencia establecida en el capítulo anterior entre composición constitutiva o agregada y composición varietal o electiva.

Pero además las interacciones externas pueden organizarse de dos formas.

Una es lo que se define de forma amplia como comportamiento. La ordenación en el tiempo de las interacciones externas.

Otra propone organizaciones de interacciones según criterios espaciales y no temporales. Esta forma de organizar se introduce en el apartado II.5 Diagramas de composición de interacciones.

Los diagramas de Casos de Uso, por ejemplo, constituyen una forma espacial de organización. No buscan organizar en el tiempo las componentes externas.

La especificación de los casos de uso puede ser realizada mediante organizaciones temporales. Por ejemplo un diagrama de secuencia o una secuencia de acciones según la plantilla propuesta por Dereck Coleman.

Las organizaciones de componentes dinámicas se sitúan en un área del cuadrante de la Figura 18 .

Pero además estas organizaciones de componentes agrupan las componentes de los diagramas según diferentes criterios. Es decir, una cosa es qué tipo de relaciones entre componentes


47

estamos estableciendo y otra diferente con qué criterio decido las que entran a formar parte de un determinado diagrama.

Los criterios a este nivel, se trata de subsistemas, son esencialmente dos. La orientación a objeto y la cohesión por objetivos de negocio.

4.1.2 Orientadas a objetoOrientadas a objetoOrientadas a objetoOrientadas a objeto

Las ordenaciones de sucesos localizadas por identificador u orientadas a objeto se utilizan en el análisis de sistemas de información desde las técnicas estructuradas.

• Basadas en diagramas de transición de estado:

La información representada debe contener:

� La identificación de la clase de objetos afectada

� Los estados posibles

� Las transiciones de estado asociadas a cada suceso.

��>� ?��%�� '��

� Basadas en expresiones regulares: Las Entity Life History (ELH) de Jackson [Jakcson 1983].

También recogidas en METRICA II como “historia vital de entidad”. Constituye otra

estructuración “orientada a objeto” de sucesos. La forma de describirlas se basa en los

constructores de expresiones regulares: secuencia, iteración, alternativa. Cada ELH representa una entidad del sistema. Jackson propone estructurar los sucesos que afectan a la entidad. En la parte izquierda aparecerá el suceso generativo, en el centro las incidencias que puede sufrir la entidad y por último el suceso destructivo que supone la “muerte” de la entidad.

�� P��1�� =�?�

4.1.3 Orientadas a objetos de negocioOrientadas a objetos de negocioOrientadas a objetos de negocioOrientadas a objetos de negocio

Un diagrama temporal de sucesos permite expresar, mediante relaciones de precedencia o sucesión, un orden parcial entre sucesos independientemente de la homogeneidad de identificación.

La capacidad expresiva de todos estos lenguajes es muy similar.

Todos se basan en Redes de Petri, es decir en hipergrafos dirigidos, para definir el orden entre sucesos.

.1.1.1.1 MeriseMeriseMeriseMerise

El Modelo Conceptual de Tratamientos de Merise se basa en los conceptos de evento (disparo o estado), sincronismo de eventos (la lógica de condiciones) y tratamiento.

�� %�� "� ��*��'�� %�� "��

Cada tratamiento puede tener una jerarquía de especialización de resultados. En el caso más simple se reflejan dos alternativas. El resultado en caso de que todo sea correcto o el resultado en caso de error. Pero un tratamiento puede conducir a una jerarquía más compleja.

�1��

��'��%��

��%��

�1��

��


49

�� =��;�� '��0�'�� (�

Merise organiza los sucesos mediante relaciones de precedencia y estructurándolos mediante los sincronismos.

Se puede observar que Merise utiliza el término evento para representar tanto los estímulos externos como estados resultantes que son “condiciones de disparo” pero no el estímulo en sí.

�� "� ��*��'�� %�� "��

Es importante destacar que todo modelo Merise tiene una expresividad equivalente mediante diagramas DFD.

La propuesta de [Gane 1980] para Análisis Estructurado contiene una notación para estructurar flujos (“*” para “y”, “+” para “o exclusivo”) lo que resolvería el problema del sincronismo. Téngase en cuenta que el sincronismo sirve para estructurar las relaciones entre sucesos.

Los eventos que utiliza Merise serán en DFD o una entidad externa (eventos puramente externos) o un archivo (eventos de condición).

La siguiente figura muestra una visión dual del mismo fragmento de una secuencia de sucesos.

��!� ��1��'��9��1�� "��$��@��'�� (�

De hecho algunas herramientas CASE comerciales permiten usar ambas notaciones.

La cuestión para el analista no es por tanto qué técnica de diagramación utiliza sino en qué conceptos se basa para poder expresar lo mismo en diferentes técnicas.


51

.2.2.2.2 Diagramas de actividadDiagramas de actividadDiagramas de actividadDiagramas de actividad

Los Diagramas de Actividad de UML permiten también expresar órdenes temporales de sucesos. Lo que en Merise se expresa mediante el sincronismo (la estructura de relaciones) en Diagramas de Actividad se expresa mediante constructores explícitos: el paralelismo o fork (el yyyy lógico en Merise) y la decisión o branch (el oooo exclusivo en Merise).

��)� ?��%�� '��1� � �

Los diagramas de actividad son menos expresivos que el modelo de Merise. Entre otras cosas, el concepto de sincronizador permite estructurar las relaciones de forma compleja. Por ejemplo puede permitir la inhibición (A y no B) o cualquier formula proposicional aplicada a los eventos.

4.1.4 BPMNBPMNBPMNBPMN

En junio de 2005 el OMG (Object Management Group) y BPMI (Business Process Management Initiative) se han fusionado en una única organización (BMI Business Modelling & Integration http://bmi.omg.org) proponiendo la notación BPMN (Bussiness Process Modelling Notation). Esta notación ha sido adoptada, entre otras organizaciones, por la WfMC (Workflow Management Coalition http://www.wfmc.org), WARIA (Workflow And Reengineering International Association http://www.waria.com).

La notación BPMN incorpora una gran riqueza descriptiva que permite, por ejemplo, distintos grafismos para cualificar los eventos.

��,� �� 1��'��Q"��

Al igual que Merise diferencia entre eventos iniciales y finales (resultantes).

��-� �� 1��&��Q"��

La notación permite los conectores de flujos habituales. Distingue las alternativas (xor) inducidas por los datos o inducidas externamente por eventos.

Incluye también los conectores complejos en los que permite asociar una expresión lógica a un conjunto de flujos. Los conectores complejos son equivalentes al concepto de sincronismo en Merise.

�� *��'�� &�#��Q"��


53

Distingue los flujos de secuencia en dos tipos: flujos normales y flujos de mensajes. Los flujos normales sirven para indicar el orden de precedencia. Los flujos de mensajes suponen comunicación.

Los flujos además pueden adornarse con matices de control para indicar que un flujo es opcional o que es el flujo por defecto.

Flujo normal

Flujo opcional

Flujo por defecto

Flujo de mensaje

4.1.5 Casos de usoCasos de usoCasos de usoCasos de uso

Hurlburlt R. “A Survey of Approaches for describing and formalizing use cases”. Expertech Ltd. 1997. Recoge más de 30 variantes de Casos de Uso.

Una de ellas los casos de uso orientados a meta de Cockburn. Los casos de uso conducidos por metas constituyen una forma intermedia de organización de sucesos. El caso de uso contiene la secuencia "principal" de interacciones. Es posible describir secuencias alternativas.

System under discussion:System under discussion:System under discussion:System under discussion: the insurance company Primary Actor:Primary Actor:Primary Actor:Primary Actor: the claimant GoalGoalGoalGoal: Get paid for car accident StepsStepsStepsSteps: 1. Claimant submits claim with substantiating data. 2. Insurance company verifies claimant owns a valid policy 3. Insurance company assigns agent to examine case 4. Agent verifies all details are within policy guidelines 5. Insurance company pays claimant ExtensionsExtensionsExtensionsExtensions: 1a. Submitted data is incomplete: 1a1. Insurance company requests missing information 1a2. Claimant supplies missing information 2a. Claimant does not own a valid policy: 2a1. Insurance company declines claim, notifies claimant, records all this, terminates proceedings. 3a. No agents are available at this time 3a1. (What does the insurance company do here?) 4a. Accident violates basic policy guidelines: 4a1. Insurance company declines claim, notifies claimant, records all this, terminates proceedings. 4b. Accident violates some minor policy guidelines: 4b1. Insurance company begins negotiation with claimant as to degree of payment to be made. VariationsVariationsVariationsVariations: 1. Claimant is a. a person

b. another insurance company c. the government 5. Payment is a. by check b. by interbank transfer c. by automatic prepayment of next installment d. by creation and payment of another policy


55

4.1.6 Diagramas de composición de interacciones Diagramas de composición de interacciones Diagramas de composición de interacciones Diagramas de composición de interacciones

Alternativamente existen formas de estructurar interacciones externas que no están basadas en el tiempo. Son agrupaciones espaciales de interacciones sin contenidos de especificación o con bajos contenidos de especificación. La técnica de casos de uso es un modo de composición de interacciones externas, aunque las relaciones extend e include incorporan aspectos internos.

��>� *�%��'�� ''��9��(�

Las jerarquías de acciones que propone Martin [Martin 1989] o los árboles de refinamiento de funciones de Wieringa estructuran interacciones externas espacialmente. La cuestión es qué considera cada cual una función, qué criterio de unidad se está proponiendo.

En la figura siguiente se muestra un ejemplo de un árbol de refinamiento de funciones.

�� .�+�� &��%�� &��'��(�

El Análisis Estructurado Moderno [Yourdon1989] no propone ninguna forma especial de organizar los sucesos. De hecho propone la “lista de sucesos” es decir una simple relación de todos los sucesos de un sistema. Cuando tratamos con sistemas complejos una lista de sucesos es poco conveniente. La validación por parte del usuario es más difícil. Siempre será más fácil para un usuario encontrar omisiones en una estructura ordenada de sucesos que en una lista secuencial sin ningún criterio estructural.


57

4.2 ��

4.2.1 Elementos básicos de los dElementos básicos de los dElementos básicos de los dElementos básicos de los diagramasiagramasiagramasiagramas

Para el modelado de procesos de negocio es necesario como mínimo poder describir:

• Encapsulamientos dinámicos (funciones, tareas, actividades...). Habitualmente representadas

por formas rectangulares. Con frecuencia presentan los cantos redondeados.

�� %�� '��Q"��

• Relaciones de temporalidad entre encapsulamientos dinámicos. Habitualmente representadas

mediante arcos dirigidos que indican el orden temporal entre elementos. En BPMN se

denominan flujos de secuencia.

�� #�� '��'��

• Estructuradores o constructores de relaciones temporales complejas. Normalmente se ofrecen

tres constructores: el paralelismo o y-lógico, la alternativa u o-exclusivo y la opcionalidad u o-

inclusivo.

�� *��'��?:�RIG�$�IG��'��Q"��

La Figura 21 muestra estos constructores en la notación BPMN pero los diagramas de actividad de UML proponen una barra negra para el AND y un rombo para el XOR. La opcionalidad se consigue combinando el paralelismo con flujos opcionales representados con trazo discontinuo.

• Disparos o eventos. En el caso de sucesos comunicativos el disparo se representa siempre

mediante una entidad externa o actor primario que comunica al sistema algo que ha ocurrido.

Los diagramas de actividad no contemplan este hecho. La notación BPMN asocia el disparo al

evento. Lo representa mediante un círculo pequeño y denota que algo ha ocurrido en el

exterior del sistema.

��!� ?�� Q"��

Un disparo es una relación entre una entidad externa que comunica un mensaje al sistema y la reacción que desencadena.

��)� �� '�%��'��'�%��'��1��

• Mensajes. Los mensajes intercambiados entre los actores y el sistema los representaremos

mediante flechas de trazo grueso. A ser posible distinguiremos claramente el color de los

mensajes de entrada y de los mensajes de salida.

��,� "��#�� $� ��

• Entornos de proceso. Las actividades que se realizan en el sistema de información con motivo

de la comunicación de un suceso tienen lugar en un entorno de proceso. La forma más

extendida para representarlo es mediante el uso de calles o “swimlanes”.


59

��-� H�� S�%��

4.2.2 Estructura de comportamiento.Estructura de comportamiento.Estructura de comportamiento.Estructura de comportamiento.

Para reflejar la estructura de comportamiento todas las técnicas recurren a constructores que permiten expresar el paralelismo, la opcionalidad o la alternativa.

Se trata del uso de las conectivas lógicas tradicionales. El ’y’’y’’y’’y’ lógico asociado al paralelismo, el ’o’ ’o’ ’o’ ’o’ inclusivo asociado a la opcionalidad y el ’o’ ’o’ ’o’ ’o’ exclusivo asociado a la alternativa.

.1.1.1.1 OpcionalidadOpcionalidadOpcionalidadOpcionalidad

La opcionalidad siempre se suele basar en el etiquetado de aristas. En el caso de los diagramas de actividad se recurre al uso de guardas. Otras técnicas proponen marcar las aristas opcionales mediante trazo discontinuo.

�� G��'�� '��

Poco frecuente es el uso de la negación o de la inhibición. Sólo Merise, que permitía expresar mediante conectivas lógicas las condiciones de disparo de cada suceso, contemplaba la negación.

.2.2.2.2 La especialización en los diagramas de La especialización en los diagramas de La especialización en los diagramas de La especialización en los diagramas de comportamiento.comportamiento.comportamiento.comportamiento.

Usamos la especialización en los diagramas de comportamiento para indicar alternativas en las trayectorias de sucesos. La aparición de trayectorias alternativas nace de diferentes formas.

Puede surgir asociada la diversidad estructural de los mensajes asociados a un suceso. La denominaremos especialización característica. Se induce externamente y, en la práctica, el actor que comunica los hechos ya conoce la variedad comunicativa.

Puede surgir asociada a las diferentes alternativas de disparo que pueden ocurrir tras un suceso. Supone una toma de decisión por parte de algún actor que el que opta por la alternativa elegida. La denominaremos especialización electiva. El caso más simple es la decisión entre los sucesos de aprobación o de rechazo que pueden seguir a un suceso de propuesta.

En principio puede parecer que la distinción entre las dos formas no es nítida. Podríamos pensar que en el caso de la aprobación o del rechazo se trata de un mismo suceso que adopta mensajes alternativos.

Existe sin embargo una pequeña diferencia. La especialización característica unos supone elección por parte de un actor. Por eso es característica.

Si cuando una persona entre urgencias de un hospital el formulario de entrada es diferente según se trate de un niño con un adulto no se trata de un problema de elección. La persona que entra no elige ser una cosa u otra. Es algo característico en ella y no lo puede cambiar al menos en ese instante.

Si el médico que atiende el ingreso opta por la hospitalización del paciente que ingresa está decidiéndose por una de las alternativas posibles de tratamiento.

Existe una forma de la especialización característica que no presenta alternativas estructurales sino que está basada en los valores comunicados. Mediante reglas organizacionales podemos tipificar diferentes alternativas de un suceso. Supongamos por ejemplo que una empresa define tres posibles alternativas en su gestión de pedidos. Se importe del pedido es inferior a 1000 € pasa directamente a planificación de producción. Si el importe es superior a 1000 € pero inferior a 12.000 debe ser aprobado por el responsable comercial. Si el monto superior es necesaria la autorización del director comercial.

Se trata de especialización característica en el sentido de que no cabe elección. La trayectoria a elegir está definida por características del mensaje.

La especialización característica define estados resultantes en un suceso a partir de los cuales pueden surgir trayectorias diferentes. Las alternativas están asociadas al suceso en el que se produce la caracterización. Esta caracterización condiciona las trayectorias subsecuentes.

La especialización electiva no está previamente determinada por ningún suceso. Simplemente muestra las alternativas elección que aparecen a partir de un instante dado.

.3.3.3.3 Formas gráficas de los comportamientos especializadosFormas gráficas de los comportamientos especializadosFormas gráficas de los comportamientos especializadosFormas gráficas de los comportamientos especializados

Los modelos de especificación de comportamiento utilizan diferentes variaciones sintácticas para dar cuenta de trayectorias de sucesos alternativas. El conector más utilizado es el rombo.


61

��>� ��'��0�'��?��%�� '��1� � �

Merise utiliza una expresividad asociada a la operación o tratamiento para dar cuenta de la especialización. Un tratamiento tiene asociado diferentes posibles resultados que pueden reflejar una jerarquía de especialización.

��!�� '��0�'��"��

La notación que permiten tanto las herramientas de workflow como los diagramas de actividad no contempla la unidad. En la notación Merise o la notación de diagramas de Venn el suceso genérico y los especializados están en un mismo encapsulamiento.

��!�� '��0�'��%� �� %��

La opción de diagramas de actividad obliga a mezclar dos conceptos de interacción la relación temporal y la relación espacial.

��!�� '��0�'��'��

En el diagrama de la figura no está definido si las actividades pertenecen a un mismo suceso o deben considerarse sucesos diferentes. Por no hablar de casos realmente complejos en los que la jerarquía de especialización puede tener varios niveles.

��!�� '��0�'��'��'��;��'��'�� $��'��

Pero esto sólo es un problema cuando hablamos de especialización característica. Porque en realidad las dos formas son necesarias.

En el caso de especialización característica la forma encapsulada es más conveniente. Permite mantener la unidad del suceso y es gráficamente más simple.

En el caso de especialización electiva la forma externa es más conveniente pues permite reflejar con claridad las alternativas de elección que se presentan a partir de un suceso determinado.

.4.4.4.4 Bucles, iteracionesBucles, iteracionesBucles, iteracionesBucles, iteraciones

Los bucles en los diagramas de sucesos aparecen siempre vinculados a la especialización. Un bucle en un diagrama de comportamiento indica la decisión de repetir una trayectoria ya realizada; normalmente para subsanar un error o defecto.

3

El comercial confecciona un

presupuesto

4.2

El cliente rechaza el presupuesto

4.1

El cliente acepta el presupuesto

5.1

El Jefe de Área cancela el proyecto

5.2

El Jefe de Área propone confeccionar un nuevo presupuesto

��!!� Q�'��%�� '�%��%��

No debe presentarse como bucles las iteraciones o trazas repetitivas. En un esquema de comportamiento pueden aparecer los sucesos alta de socio y alta de huertos de un socio.

A cada suceso alta de socio le pueden suceder múltiples sucesos alta de huertos. De la misma forma que a un suceso alta de cliente le pueden suceder múltiples sucesos un cliente solicita un pedido. En ningún caso se define un bucle sobre estos sucesos. En realidad no existe tal bucle. Tras el suceso de solicitud de pedido no es necesario que ocurra otra instancia del mismo.

Sin duda podríamos optar por una especialización electiva y un bucle para reflejar el hecho de que tras la solicitud de un pedido puede ocurrir otra solicitud de pedido o alternativamente que se


63

tramite el pedido. Esta precisión no es conveniente por la complejidad que incorporaría en los diagramas. Además no deja de ser una representación de un hecho que puede expresarse de forma más simple. Se trata en definitiva de un problema de paralelismo. Tras el suceso alta de cliente o alta de socio pueden iniciarse n ocurrencias de los sucesos subsiguientes. Si quisiéramos expresarlo es más práctico y sobre todo más simple recurrir al concepto de cardinalidad entre ocurrencias.

��!)� G��'�� '��'��%T��(�

4.3 ��!��"�

Scott Ambler [Ambler 2005] ha publicado un libro sobre guías de estilo en UML. Propone las siguientes guías para el trazado de diagramas de actividad:

1- Coloque el punto inicial en la parte superior izquierda de la hoja

2- Coloque algún punto final.

3- Simplifique lo máximo posible.

A continuación propone el siguiente ejemplo

��!,� ?��%��'��%�� +� �%��(�

a- El eje temporal debe desarrollarse en una sola dimensión

Utilizando la norma de mantener un eje temporal único, el diagrama se trazaría en la forma que muestra la figura siguiente.

��!-� ?��%��%�� %��

En el gráfico de la Figura 33 el tiempo se “dobla” comienza transcurriendo verticalmente para luego desarrollarse horizontalmente. Esto dificulta la comprensión del diagrama e incrementa el tiempo dedicado a comprenderlo. Existen dos razones básicas para seguir esta recomendación. La primera es que en la cultura occidental tendemos a leer de arriba abajo y de izquierda a derecha. Cuando aparece información escrita nuestra percepción tiende a seguir esta pauta. En el primer diagrama es necesario invertir más tiempo porque para entender las diferentes unidades de texto es necesario realizar en paralelo una lectura vertical y otra horizontal.

La segunda porque según muestran los trabajos de [Barsalou 1998] sobre formación de conceptos la mente humana asigna a los conceptos espaciales representaciones gráficas específicas. Puesto


65

que el tiempo es una dimensión su representación debe ser unidimensional y no bidimensional como en la primera figura.

En este diagrama cuesta menos tiempo comprender que la actividad “Obtain help to fill out the forms” es una actividad opcional que transcurre entre “Fill out....” y “Enroll in University”

4.3.1 Trazado de comunicaciones.Trazado de comunicaciones.Trazado de comunicaciones.Trazado de comunicaciones.

b- Las relaciones de comunicación deben desarrollarse en dimensión perpendicular al eje temporal

��!�� %�� 1��'��$�'�%��'�'��4��0��(�

Las comunicaciones con el entorno del sistema información pueden reflejarse de dos maneras. Una Consiste en vincular cada comunicación con una actividad comunicativa. Habitualmente la actividad suele tener un nombre formado por un verbo como enviar, recibir, remitir, comunicar, y un complemento directo designando el documento que se comunica un complemento indirecto que indica la persona o departamento a quien se envía. Es la que suele utilizarse en la mayoría de flujogramas o en las propuestas de workflow.

Otra posibilidad es asociar las comunicaciones a flujos de datos. Las acciones específicas que generarían esta información se consideran vinculadas a un mensaje de entrada. Esta opción simplifica los diagramas.

c- Diferencie los grafismos de comunicación y las relaciones de precedencia.


67

4.3.2 EspecializaciónEspecializaciónEspecializaciónEspecialización....

Use la especialización/generalización cuando sea necesario.

d- Solo se debe especializar si los caminos temporales son diferentes para cada variante de la especialización.

��!>� ��'��0�'��'��'�%�� (�

e- Puede aparecer especialización asociada a salidas diferentes. Pero debe evitarse si se trata de un mismo documento con contenidos variantes.

Por ejemplo, todos los meses se envía una carta felicitando a los empleados que han superado la media de ventas y otra invitando a mejorar a los que están por debajo de la media. El documento es el mismo. Varía el contenido. No debería usarse especialización de comportamiento.

f- Evite especializar las comunicaciones por diferencias en los soportes.

Si algo llega por teléfono o por e-mail pero el contenido del mensaje y la reacción asociadas son iguales no afecta al comportamiento comunicativo. Solo es un matiz. Se puede poner mediante adornos del mensaje (un teléfono, un e-mail...).

g- Use especialización encapsulada cuando tras un suceso puedan darse variantes alternativas de un mismo hecho comunicativo.

��

��

��

��

� ��

� !��

"��

��

��

��)�� '��0�'��'�� (�

h- Use especialización no encapsulada cuando tras un suceso puedan darse variantes que dependen de lo que ocurra en el futuro. Pero esas variantes no sean alternativas de un mismo hecho comunicativo.

��)�� '��0�'��'�� (�

En la figura anterior tras haber emitido la factura pueden ocurrir dos cosas. Que se reemita la factura porque contenía errores o que se proceda al pago y emisión de facturas a proveedores. El que ocurra una u otra no depende del suceso Gesco FAC5 sino de cual es el primer mensaje que llega a la organización.

Además entre refacturar y emitir pago a proveedor no existe ninguna relación comunicativa. No son dos alternativas comunicativas relacionadas sino independientes.

i- Cuando aparecen bucles debe aparecer especialización.

Cuando aparece un bucle debe existir algún camino alternativo para salir de él. La forma de hacerlo está siempre vinculada a la especialización. Aparece un suceso especializado que constituye la ruptura del bucle.

��)�� '��0�'��$�+�'��(�

La especialización se induce no solo en el suceso que constituye la ruptura del bucle


69

��)�� '��0�'��$�+�'��(�

Cuando en un suceso “entran” diferentes “caminos temporales” o flujos de precedencia. Será necesario considerar que los tratamientos internos del suceso comunicativo requerirán especialización.

Internamente las comunicaciones de incidencias deberán diferenciar dos modalidades comunicativas, las incidencias nuevas y las incidencias provenientes de una solución incorrecta.

Análisis de Requisitos y Procesos de Negocio

71

5555---- AnálisisAnálisisAnálisisAnálisis de Requisitos y Procesos de Negocio de Requisitos y Procesos de Negocio de Requisitos y Procesos de Negocio de Requisitos y Procesos de Negocio

5.1 ��

Los usuarios de los sistemas de información describen sus percepciones de manera diversa. Los analistas tienen que enfrentarse al modelado de fenómenos en función de estas formas de describir. Filósofos y científicos discuten hace milenios sobre la realidad y la percepción. En cierta forma da igual de qué esté constituido el mundo, cual sea su esencia, su ontología. Lo importante es qué perciben los humanos y cómo lo describen.

Wolgfang Hesse presenta la siguiente reflexión en el informe Frisco [FRIS98]:

“We live in the age of ��. Data processing - and particularly data modelling - techniques even enforce this tendency by �� (i.e. giving static descriptions) of actions and processes. But nevertheless, there are �� in our conceived world which are not completely grasped by these techniques but only in a reduced, snapshot-like manner.”

“Dynamic "things" must not be confused with static descriptions of their results or of intermediate and resulting states.”

Cuando una organización se dota de un sistema de información los fenómenos en el sistema objeto pueden ser percibidos de forma estática o dinámica. Incluso un mismo tipo de fenómenos puede ser percibido estáticamente por unos usuarios o dinámicamente por otros.


La visión de los usuarios depende de su relación con los tipos de fenómenos en cuestión.

72

?��'�� '��UI?�>!V��'��+#��&��%�� 1��%�� %��'��3��'��'��4�%�� %�� @��'��%@��+@��'��&�� %�� @%�'�(��%+��9�� '�'�� '��5(�� '�'��;��&��&;��:��'��&��&�'��''� �� '�� 1��+��+��%+��%�$��;�� #��(��

�� '�� @��'��@��'��$��%C�� 4�� 9�%�'��+#��(�8��@��'��$�� @%�'��1��'�%��'�%��%�� (�3Q��'��0�� +��4��'��'��4��+#�'��4��%� ��4��$��%��'��5��UP�G >)V(�

W�&�� 4�+�� ;�� &�� %�� '��'��0�'�� %�� (� 8��+�� '��;�� '��$��+�� '��'�� 1��(��'�%+��'��'��;��'��'�� 9��'��(��1C�� '�%+��'�+�%��C�%�� '��$�� (�

“The external thing selected and referred to as an object is never existentially given in experience, but is cognitively given in the sense that it is interpreted and revealed.” [SELL34]

La justificación existencial de nuestras cogniciones no es evidente.

“Los colores no son ‘clases naturales’ precisamente porque� son el producto de la evolución biológica, que tiene tolerancia por fronteras desdibujadas entre categorías que horrorizaría a un filósofo aficionado a ideas claras y distintas. Si la vida de una criatura dependiera de empaquetar juntos la luna, el queso azul y las bicicletas, tengan la seguridad de que la Madre Naturaleza encontraría una manera para hacerle ‘ver’ estas cosas como ‘intuitivamente la misma y cabal clase de cosa’ ”. [DENN98]

Frente a la tendencia actual, introducida por la orientación a objeto, que manifiesta que “El mundo está formado por objetos” debe oponerse una expresión más dinámica:” El mundo está formado por procesos”

Los seres humanos observan estos procesos. Las limitaciones cognitivas nos llevan a considerarlos de forma estática o discreta. Pero la evidencia del carácter dinámico de las cosas está presente desde los filósofos presocráticos.

Una observación sobre el mundo es una correspondencia entre procesos y propiedades. Sólo sabemos describir el mundo en términos de objetos y propiedades. El único aspecto que percibimos de los procesos es su variabilidad. Variabilidad que detectamos pero que no siempre identificamos. Cuando observamos una catarata somos conscientes de percibir un proceso. Sin embargo no somos capaces de identificar estados. Nuestra capacidad descriptiva está limitada por nuestra capacidad de identificación de cosas. Como no disponemos de identificadores para las gotas de agua no podemos dar una descripción de estado compositiva de la catarata. Nuestra percepción se limita a predicar propiedades estadísticas de las componentes como el caudal.

Como decíamos en el capítulo anterior: “Dos son las percepciones que tenemos de los procesos: Eventos e individuos.” Es decir objetos y los cambios que se producen en ellos.

Un evento es el resultado de una observación de un fenómeno en la que somos capaces de percibir fluctuaciones que describimos mediante propiedades.

Un individuo es el resultado de la observación de un proceso en el que no somos capaces de percibir fluctuaciones o no tenemos la capacidad o el interés de constatarlas (aunque a veces podamos suponer que ese individuo podrá cambiar en otras observaciones).

Los actores de un sistemas de información describen sus percepciones de manera diversa. Los analistas tienen que enfrentarse al modelado de fenómenos en función de estas formas de


73

describir. Da igual de hecho de qué esté constituido el mundo. Lo importante es qué perciben los humanos y cómo lo describen.

Cuando una organización se dota de un sistema de información los fenómenos en el sistema objeto pueden ser percibidos de forma estática o dinámica. Incluso un mismo tipo de fenómenos puede ser percibido estáticamente por unas personas o dinámicamente por otras.


Las percepciones dependen de su relación con los tipos de fenómenos en cuestión.

5.1.1 Observación de eventos o de individuosObservación de eventos o de individuosObservación de eventos o de individuosObservación de eventos o de individuos

Cuando los fenómenos generativos son lejanos en el tiempo, y por lo tanto no son directamente observables, las personas describen el fenómeno en su perspectiva estática, por ejemplo una cuenca hidrográfica. Cuando los fenómenos generativos son observables (coetáneos del SI) las personas pueden tener percepciones dinámicas de ellos.

El hecho de que percibamos un fenómeno como objeto o como evento se debe en muchas ocasiones a la relación que tenemos con los cambios que experimenta. Cuando la frecuencia con que percibimos los cambios es alta tenderemos a considerar los eventos. En caso contrario consideraremos los individuos. Es decir, si a nuestros ojos un fenómeno es estable, porque apenas observamos cambios, tenderemos a la percepción estática o de individuos. Si lo observamos como algo cambiante tenderemos a la percepción dinámica o de eventos.

Hay fenómenos que están en cambio continuo. Pero a veces estos cambios son tan sutiles a nuestra percepción que nos pasan inadvertidos. Podemos estar un rato observando una planta. En ella se están produciendo cambios continuos. Sin embargo nos cuesta percibirlos.

74

5.1.2 Elementos del sistema objetoElementos del sistema objetoElementos del sistema objetoElementos del sistema objeto

En el Sistema Objeto encontramos tres tipos de elementos característicos de las organizaciones de negocio. Cada uno de ellos se percibe de forma diferente por los actores organizacionales.

• Elementos básicos Constituidos por las materias primas y los productos o servicios comercializados. Son los operandos de los procesos organizacionales. Pueden ser más o menos complejos. Su descripción puede requerir una simple clase con varios atributos descriptivos o responder a una composición compleja que requiera el uso de múltiples clases, agregaciones y asociaciones. Se caracterizan porque:

� 8��1�� +�'��'��'�� (�Q��'�� 1� �� %��+��'�'�� &�� '��1� � � ��'��(�

� *��$��%��'�� 0�'��(�� '��'��%@��@��'�� @%�'�(��#��%@��@��@��'�(�

��%��%��%��(�� *��$��%�� '�%��'��+@��'�(� ��@��#��'��'��'�%��'��

%��'� �(��9�� '��%�(�� +#�� %C��'�� '�� '��(�� '��0�'�� &��(��%��&��%��'��(�� '�%��#� � � '�%��1�� &�� '��(� *�%��'��:�

��+��'��:��%��%��X�

��)!� ��%��+@��'��

• ElementosElementosElementosElementos mediadores mediadores mediadores mediadores: son los agentes que participan o median en los procesos organizacionales.

• Pueden ser de nivel operacional. Son los que aportan, reciben, transforman, transportan los objetos básicos.

• Pueden ser también los que soportan los procesos de gestión y planificación de las actividades de otros mediadores. � ��'�� '��+�$��1��Y� � �(�� '��'��'�%��%�� %�(�� %�� %��'� �(�� %��'� �(�� '�+��@��'��$� ��@%�'�%��(��


75

��))� ��%��%� ��

• Elementos de gestión y producción. � �� '�� 0�'��(� � �� %�� +@��'�� 2�� ''��:�

��0�%��:� '��%�:� ��1��%��:� ��Y�(((6� '�� '��'�� %� �� (�

� *��$��%�� 1��Y� � �(�� %@��'��+#��(��#��%@��%��(��'��

��'��(��%��'��'�+��%��+@��'��(�� ?�&�� '�%��%�� %�(� �� '�%��%�� %�� %� �� $�

+@��'��@�'�� '�� %�� (�� %�� %��'� �(�*��&��1��Y� � �(�� +#�� %C��'�� '�� '��(�

��),� ��%��

5.1.3 Entradas y salidas: lo básico y lo derivadoEntradas y salidas: lo básico y lo derivadoEntradas y salidas: lo básico y lo derivadoEntradas y salidas: lo básico y lo derivado

Las interacciones entre un sistema de información y su entorno contienen descripciones de fenómenos de la realidad. Toda interacción puede tener una parte descriptiva básica y una parte descriptiva derivada. La parte básica es la que corresponde a la nueva información aportada al sistema. La parte derivada está constituida por toda aquella información que se obtiene de la que ya conoce el sistema. En palabras de Längefors un Sistema de Información es “a technologically implemented medium for recording, storing, and disseminating linguistic expressions, as well as for drawing conclusions from such expressions”. La información derivada está constituida por todas las expresiones que diseminamos y por todas las conclusiones que podemos sacar de ellas.

Complejidad y tipicidad introsducida en cada nivel.

Complejidad intrinseca básica

Complejidad basico-mediador

Complejidad intrínseca de gestión

Complejidad gestión-mediación

Compeljidad gestión-básico

76

Es básico el hecho de que informemos al sistema que un cliente c ha comprado x unidades del producto z el día d. Es derivado, una conclusión de la que el sistema no ha sido informado explícitamente, saber qué cliente ha comprado más unidades del producto z el día d.

Los objetos de negocio tienen una composición compleja. En algunos casos su estructura completa puede ser el resultado de una derivación. Por ejemplo, el listado del 20% de clientes que consumen el 80% de los productos de una empresa. En otros pueden reflejar información básica. Por ejemplo una descripción del catálogo de productos. En otros pueden ser mixtos. Unas partes provienen de información básica, otras provienen de información derivada y son el resultado de ciertas conclusiones. Por ejemplo una factura tiene una información básica: el número de la factura, la fecha de la factura, el período de facturación, el cliente al que corresponde la factura y las líneas de albarán que recoge. El resto de información de la factura puede derivarse de información que consta en el sistema. En algunos casos podría ser incluso posible que las líneas de albarán fueran una derivación del sistema a partir del dato del período de facturación.

En la estructura básica de un suceso comunicativo -contacto, descripción, reacción- la descripción contiene información básica y la reacción describe las necesidades de derivación: las conclusiones o cálculos.

En el modelo simplificado que denota diferentes estadios de proceso en una organización. El contenido de información básica y derivada se va invirtiendo a medida que avanzamos en el tiempo.

��)-� ��'��&��%�'��+@��'��$� ��1� �� ''��

Así en las interacciones de los procesos “iniciales” o de la fase de demanda el contenido de información básica es mayor, por ejemplo un pedido, que en las interacciones de las fases “finales” por ejemplo una factura.

5.1.4 Niveles organizacionalesNiveles organizacionalesNiveles organizacionalesNiveles organizacionales

Si atendemos a los niveles de gestión organizacional -estratégico, táctico, operacional- observamos que en los niveles altos los requisitos que detectemos harán referencia a información derivada. La carga de interacciones con aporte de información se deja al nivel operacional que es el que observa de forma más directa lo que ocurre día a día. A los niveles de decisión les interesan más las conclusiones, no la información detallada.


77

��)�� 1��0�'��:�� $�� (�

5.2 ��"�

La literatura ha acuñado el concepto “de negocio” para referirse a un ámbito significativo o “de valor” de las percepciones. Utilizaremos esa denominación para indicar percepciones próximas a los actores organizacionales y no a los agentes informáticos. Así mientras un objeto de un diagrama de clases es algo que se define sin ambigüedad y que encapsula propiedades y métodos entorno a un mismo identificador un objeto de negocio es una percepción de una estructura de información por parte de un usuario. Un objeto de negocio puede ser un formulario o un expediente que comprende diferentes formularios y escritos. Todo objeto de negocio puede asociarse a un proceso de negocio que define los distintos pasos en los que el objeto de negocio va tomando forma.

Un objeto de negocio se puede describir mediante un esquema de objetos de un diagrama de clases.

Los procesos de negocio y los objetos de negocio constituyen una forma dual de nuestra percepción.

Las propiedades de un objeto de negocio pueden ser elementales o estructuradas. Las propiedades estructuradas pueden ser, a su vez, objetos de negocio, es decir, composiciones de propiedades que sean de interés para algún actor social. Obsérvese que donde dice interés podría decir valor. Carece de importancia porque lo que se indica en realidad es que la estructura de un objeto de negocio es “discrecional” y no universal. Alguien decide ver una parte de la realidad representada mediante un determinado objeto de negocio.

Un proceso de negocio es una composición temporal de interacciones comunicativas que conforman un objeto de negocio.

Los objetos de negocio necesitan disponer de identificación. De otra forma no seríamos capaces de distinguir dos fenómenos diferentes. La identificación de un objeto puede ser propia o dependiente.

Las componentes de un objeto de negocio pueden ser básicas o derivadas. Son básicas si existe una interacción comunicativa que aporta su valor descriptivo. Son derivadas si se obtienen mediante un cálculo o derivación a partir de otras propiedades básicas o derivadas.

78

Las interacciones comunicativas de entrada aportan información descriptiva de los objetos de negocio. Las interacciones comunicativas de salida muestran objetos de negocio derivados.

Cualquier interacción, en su forma más general, puede contener descripciones básicas y derivadas.

Los objetos de negocio pueden tener también un mayor o menor carácter básico o derivado.

Por ejemplo, el listado de productos comprados por clientes de Murcia puede considerarse una interacción de salida y un objeto “totalmente derivado”. El alta de un proveedor puede considerarse una interacción de entrada y al proveedor como un objeto básico.

Mientras que una factura es una composición de propiedades básicas y derivadas como veíamos en el apartado 5.1.3. “...una factura tiene una información básica: la fecha de la factura, el período de facturación, el cliente al que corresponde la factura y las líneas de albarán que recoge. El resto de información de la factura puede derivarse de información que consta en el sistema. En algunos casos podría ser incluso posible que las líneas de albarán fueran una derivación del sistema a partir del dato del período de facturación....”

5.2.1 Dinámica de Dinámica de Dinámica de Dinámica de los objetos derivadoslos objetos derivadoslos objetos derivadoslos objetos derivados

Uno de los problemas que aparece en el desarrollo de aplicaciones es el de la dinámica de los objetos derivados. Un objeto derivado puede ser estático o dinámico. Es estático el valor obtenido debe preservarse aunque cambien los valores de los objetos de los que se deriva. Es dinámico si el valor que interesa es el que se obtiene cada momento que se deriva. Es dinámica “la lista de los clientes de Murcia” es estático “el precio del producto 33 de la factura 44”.

Un tipo de objeto derivado estático es un índice secuencial. Por ejemplo la numeración de las facturas. También los es la descripción de un producto que aparece en una factura o su precio.

5.3 ��

¿Cómo buscamos requisitos? ¿Cómo detectamos las interacciones que existen?

Obviamente no hay una sola forma. Los diferentes modos de percibir, las diferentes formas de relacionarse con el sistema hacen imposible una única estrategia de investigación cognitiva.

Según las percepciones de los usuarios y las características del sistema objeto podemos encontrar diferentes formas de organizar la investigación de un sistema. Cada una de ellas sugiere una estrategia de análisis diferente. Las estrategias no son excluyentes. Son contingentes. En función de las características de cada usuario y del problema tratado puede ser conveniente el uso de una u otra.

5.3.1 Estrategias directasEstrategias directasEstrategias directasEstrategias directas

Es aplicable cuando analizamos un sistema existente (que está funcionando aunque sea de forma manual) en el que los usuarios tienen una cultura establecida de procedimientos y formularios organizacionales. Al conocer los procedimientos de tramitación será posible obtener información precisa de constructores y sus estructuras de adquisición. Constituye la aproximación más fiable.


79

��( Estrategia directa

La estrategia directa es aplicable con usuarios de nivel operacional, es decir los que conocen los procedimientos concretos. Los usuarios de nivel táctico y estratégico, que no conocen los procedimientos básicos con detalle, expresarán sus necesidades en términos de consultas. Describirán la información que necesitan obtener para su gestión organizacional.

Mediante estrategia directa partimos de la estructura de adquisición de cada suceso constructor para ir obteniendo el modelo de datos de forma incremental. Al analizar cada acontecimiento podemos encontrar objetos básicos cuyo análisis puede responder a otra percepción más estática.

Los sucesos consultores se definen de forma precisa a partir del modelo de datos.

La estrategia de JSD es directa. Primero se identifican y organizan los sucesos constructores. Las organizaciones de constructores definen las entidades del sistema. Sobre estas estructuras se definen las funciones de observación (consultores).

5.3.2 Estrategias inversasEstrategias inversasEstrategias inversasEstrategias inversas

Es aplicable cuando analizamos un sistema que no existe más que en la mente de los usuarios. No existe una experiencia del mismo y es más difícil establecer los procedimientos organizacionales. Será más fácil saber qué esperan obtener los usuarios del sistema (consultores).

También es adecuada cuando partimos de objetos de negocio que son fuertemente derivados y en que no son en sí mismos objeto directo de los sucesos generativos. Una nómina, por ejemplo, recoge información básica de objetos que resultan de sucesos que jamás identifican el objeto nómina.

��( Estrategia inversa

A partir de los consultores podemos definir el modelo de datos que satisface las necesidades de consulta. Por último será necesario definir los constructores que permiten generar dicho modelo de datos. La estrategia inversa es menos fiable a la hora de definir el modelo de datos. En

80

[ATRE80] se propone una técnica de derivación de modelo de datos a partir de estructuras de consultores basada en la normalización.

5.3.3 Estrategias internasEstrategias internasEstrategias internasEstrategias internas

Consiste en definir la arquitectura interna de componentes del sistema y como guía para la definición de las comunicaciones.

Existen entidades en los sistemas que suelen ser de carácter básico (normalmente referidas por las demás entidades) cuya descripción puede ser independiente de los tratamientos. Por ejemplo los productos que una empresa comercializa, por complejos que sean, tienen características estáticas bien conocidas por los usuarios. Es la forma de gestionar estos productos (cómo se piden, fabrican, transportan, facturan...). Las características observables de un buque o de las mercancías serán descritas con detalle por los usuarios. Los sucesos en que se ve involucrado (llegada, salida, amarre...) o la forma en que las mercancías se cargan o descargan son procesos que para caracterizarse deben quedar reflejados en estructuras que no reflejan aspectos estáticos directos sino descripciones de actividades. La hora de llegada, la mercancía cargada, etc. no son propiedades de la entidad buque sino resultado de actividades en las que el buque está involucrado.

��!( Estrategia interna

En las actuales propuestas de modelado de SI la estrategia de análisis es esencialmente interna. El modelo ER propugna el descubrimiento de la estructura de entidades. Los constructores y consultores se definen a posteriori. Los modelos orientados a objeto comienzan por definir la arquitectura de entidades, el diagrama de clases. El resto de componentes se obtienen a partir de esta arquitectura.

Todas las propuestas basadas en ontologías de objetos preconizan la descomposición de componentes internas bajo el criterio de unidad de identificación.

La descomposición interna estática no es la única posible. La versión inicial del Análisis Estructurado de Sistemas puede considerarse una estrategia interna.

Las técnicas de integración de vistas [BOUZ90], [BATI92].pueden considerarse una forma de estrategia interna. Aunque la integración de vistas parte de las visiones externas de usuarios cada visión de usuario no responde a un concepto de constructor o consultor sino a un concepto de esquema externo considerado como proyección del esquema interno. Por ello cada vista es un fragmento del estado interno del sistema. La integración de vistas no propone la separación de aspectos constructivos y consultivos y, en ese sentido, debe ser considerada una estrategia de descomposición interna.


81

5.4 ��

A medida que vamos refinando el sistema surgen niveles de descomposición cuyos elementos responden a una intención que va más allá de la mera reducción de complejidad. Se trata de lo que hoy en día se denominan procesos de negocio.

Un proceso de negocio es el conjunto de los sucesos que se requieren para gestionar de forma completa una transacción entre organizaciones.

El término de forma completa requiere, de nuevo, criterios de unidad. Preguntarnos qué consideramos completo es lo mismo que preguntarnos qué consideramos la unidad de procesos de negocio.

Los criterios que se vienen proponiendo en la literatura son las metas u objetivos.

El término proceso de negocio es habitual en las áreas de BPM y en las propuestas de workflow.

A business process is a set of logically related business activities that combine to deliver something of value (e.g. products, goods, services or information) to a customer.

Un proceso de negocio es una composición de interacciones a medio o largo plazo en la que podemos hacer las siguientes suposiciones:

• El proceso de negocio se compone de interacciones elementales o sucesos. • El proceso de negocio tiene un inicio y un fin definidos. • En algunos casos pueden existir más de una forma de iniciar y más de una forma de terminar. • Si el proceso de negocio se inicia, forzosamente acabará alcanzándose un estado final en un

plazo razonable. • Los sucesos que componen un proceso de negocio se ordenan en el tiempo. El criterio de unidad que se utiliza en los procesos de negocio coincide con el criterio de unidad que se propone en las aproximaciones basadas en metas.

La delimitación de las actividades que comprende un proceso de negocio o un caso de uso orientado a metas siguen en realidad un mismo criterio: ofrecer valor añadido.

Para Cockburn la meta se asocia a la apreciación de valor por parte de un actor. Este criterio aparece en la propia definición de caso de uso de Jacobson “a sequence of transactions in a system whose task is to yield a measurable value” [Jacobson 1995].

Existen muchas técnicas de modelado orientadas a objetivos [Bubenko 1994], [Potts 1989], [Yu 1994], [Anton 1996], [Rolland 1998]. El único problema que plantean los objetivos es que no siempre son únicos porque no todos los actores que participan en una interacción necesariamente comparten las mismas intenciones.

El punto de partida siempre será una descripción inicial del proceso de negocio. Esta descripción se obtendrá de los responsables del proceso. Bien porque existen especificaciones de procedimiento, bien porque se establezcan en una entrevista específica.

La descripción inicial servirá para identificar las fuentes de información esenciales para la captura de requisitos de ese proceso.

Será necesario definir una ficha de proceso que contendrá la descripción general del proceso, los objetivos de gestión, los indicadores de gestión y una posible relación de carencias o necesidades actuales.

A partir de este esquema inicial el analista procederá a determinar y completar un esquema de sucesos comunicativos.

82

��)>� ��'4�� '��(�2G�&��*�(��IZ� �6�

5.5 ��

El ámbito de los procesos es de carácter abstracto. Hay tres tipos de requisitos esenciales en un proceso.

Las interacciones comunicativas que caracterizan el proceso.

Los objetos de negocio que caracterizan el proceso.

Los indicadores de negocio que dan al estamento directivo una visión global del proceso y permiten su control efectivo.

5.6 ��

• Nombre • Motivos para el cambio: problemas detectados en la gestión actual o necesidades que el

procedimiento actual no puede satisfacer. • Objetivos: mejoras esperadas en beneficio, reducción de costes, recursos, tiempos, imagen... • Objetos de negocio: identifique los requisitos de observación esenciales sobre los diferentes

elementos del sistema. Defina un glosario de los objetos, y sus principales características. � Elementos básicos: Materias primas, bienes, servicios. Sobre qué elementos actúa el proceso

que se va a definir.

� Elementos mediadores: Recursos humanos, medios de producción que intervienen en el proceso y que serán objeto de interés en la aplicación.

� Gestión: Determine las fases esenciales de gestión involucradas.

Solicitud (valoración-presupuesto-, aprobación…)


83

Planificación (asignación de recursos

Aprovisionamiento, Producción, Ejecución, Transformación, Desplazamiento, Distribución

Cobro

• Fuentes de información: defina quienes participarán en el proceso de análisis. Qué formularios se utilizan en la gestión actual.

Usuario responsable

Usuarios implicados

Formularios en papel o electrónicos.

• Interfaces: defina relaciones con otros subsistemas que recibirán o aportarán información al proceso. Este apartado solo debe documentarse si el proceso que se analiza no forma parte de un subsistema superior que lo contiene en el que se han documentado las necesidades de integración.

• Indicadores de Gestión � Indicador: Parámetro que define el volumen, esfuerzo o recursos que son necesarios en la

gestión actual.

� Estimación: volumen de la gestión actual, posibles tasas de error, tiempos de respuesta actuales, sucesos críticos.

� Objetivos: mejora propuesta de cada indicador.

� Listado asociado: listados que permitirán conocer si los objetivos se están satisfaciendo.

• Diagrama de Sucesos a través de él se define el comportamiento comunicativo que requiere el proceso de negocio. Permite investigar las necesidades de información de forma metódica.

• Lista de sucesos de negocio: está constituida por todos los sucesos de entrada (sucesos constructores) y todos los sucesos de salida (sucesos consultores) utilizados en el diagrama de sucesos o detectados como indicadores de gestión.

Tanto el diagrama de sucesos como la lista de sucesos o los consultores que resuelven los indicadores de gestión son el resultado de diversas entrevistas.

En una primera entrevista se deben determinar los aspectos más básicos. En función de la cultura tecnológica y de gestión de los usuarios la riqueza de los consultores puede ser mayor o menor. Cuando los usuarios sufren una informática poco adaptada a sus necesidades tienen problemas operacionales y es difícil que planteen problemas tácticos o estratégicos. Lo primero es resolver las operaciones diarias.

Cuando una organización ha madurado en el uso de la tecnología desarrolla una mayor riqueza de consultores.

La cumplimentación del documento de proceso de negocio comprende varias iteraciones.

84


85

5.7 ��

El análisis de comportamiento comunicativo es una estrategia directa basada en obtener las interacciones a partir de la organización temporal de los procesos de entrada.

• Definir el conjunto de sucesos comunicativos que la organización requiere para cada proceso de negocio.

• Reflejar en qué forma se organizan en el tiempo estas comunicaciones. • Definir el contenido esencial de cada una de las comunicaciones requeridas. Para la determinación de los sucesos comunicativos es recomendable utilizar las siguientes técnicas.

5.7.1 Análisis generativo Análisis generativo Análisis generativo Análisis generativo

El análisis generativo se basa en “construir” las secuencias temporales o el comportamiento comunicativo de los mensajes de entrada.

Para llevar a cabo el análisis generativo podemos apoyarnos en los formularios existentes o en las descripciones de procesos.

.1.1.1.1 AnálisisAnálisisAnálisisAnálisis de formularios. de formularios. de formularios. de formularios.

Frente a cualquier formulario el analista indagará la forma en que se cumplimenta. Se trata de detectar si el formulario corresponde a uno o más sucesos comunicativos.

Se debe investigar con el usuario la forma en que se generan cada uno de los campos del formulario. En qué instante se generan y quién los genera. Los formularios de entrada pueden ser generados de forma incremental siendo el resultado de una secuencia de sucesos de entrada. Cada comunicación de entrada va añadiendo nueva información al formulario.

La documentación inicial puede basarse en el propio formulario, marcando cada conjunto de campos que se adquieran en el mismo suceso. Anotando quién es el responsable de cada suceso e indicando el orden generativo para establecer la secuencia de sucesos.

El analista buscará cuáles son los actores primarios que originan la información del formulario, mediante qué sucesos diferentes se construye, el mensaje que se comunica en cada suceso y cual es el orden temporal de esta generación.

.2.2.2.2 FormulariosFormulariosFormulariosFormularios y y y y funcionesfuncionesfuncionesfunciones comunicativas comunicativas comunicativas comunicativas

Lo primero que deberá de hacer el analista es revisar las secuencias básicas de los procedimientos organizacionales y convertirlos en sucesos utilizando criterios de unidad comunicativa.

El esqueleto de los diagramas de comportamiento comunicativo son los sucesos constructores. Cuando definimos procesos de negocio de forma detallada el hilo conductor se establece sobre los sucesos que aportan nueva información al sistema. A partir de ellos se van definiendo las necesidades de información.

Con la documentación aportada por los usuarios el analista fijará las estructuras de adquisición de cada uno de los sucesos detectados. Mediante esta actividad pueden aparecer nuevos sucesos o desaparecer algunos de los inicialmente considerados.

Los formularios deben ser exhaustivamente analizados para obtener toda la información necesaria para la especificación de los sucesos.

El analista deberá comprender el uso de cada uno de los formularios utilizados por la organización; prestando especial atención a los formularios de entrada de datos.

Perry Edwards [Edwards 1985] define diferentes usos de formularios organizacionales que se presentan a continuación.

86

�� Los formularios de entrada de datos están asociados a la adquisición de información. Son el punto de partida del análisis de comunicaciones. Si no existen será necesario diseñarlos con los usuarios construyendo prototipos simples. Los formularios son la mejor herramienta de especificación y validación de contenidos que el analista puede utilizar. Por su carácter externo constituyen una visión totalmente adaptada al usuario.

�� Los documentos de ida y vuelta son aquéllos que el sistema genera, mediante un suceso consultor, pero con la previsión de que vuelvan a ser ingresados en el sistema para alguna tramitación posterior.

Por ejemplo una persona se matricula de un curso y se le expide un documento de pago. Esta persona va al banco, ingresa el importe de la matrícula y devuelve una copia sellada del documento para reincorporarlo al sistema.

Tratamientos similares pueden asociarse a gestiones de pagos, envío y devolución de albaranes, una tarjeta de cargos en un hotel…

El aspecto más importante de los documentos de ida y vuelta es el control de identificación. Al ser la organización la que expide el documento siempre puede generar identificadores propios en formatos que permitan una adquisición ágil (códigos de barras, OCR…).

Los documentos de ida y vuelta estarán asociados a diferentes sucesos constructivos. Sus características dinámicas dependerán de las secuencias de sucesos aplicables.

Frecuentemente los documentos de ida y vuelta requieren dispositivos complejos para su tratamiento ya sea en emisión o en el uso (control de accesos, identificación de tramitaciones).

�� Cuando una organización maneja funciones de su sistema de información de modo manual, pueden aparecer formularios que en la práctica se asocian a consultores pero que por su forma de uso parecen constructores.

Estos formularios suelen contener información resumida, campos acumulados, campos calculados, en general información redundante que se actualiza en el momento en que la información base se conoce y que simplifica la gestión.

Por ejemplo supongamos un almacén en el que se producen entradas y salidas de productos. Habitualmente, cuando se gestiona de forma manual, los responsables de almacén tienen formularios donde reflejan cada entrada y cada salida (o uno para entradas y otro para salidas). Pero además pueden tener otro formulario de existencias por producto. Cada vez que entra un producto se refleja en el diario de entradas y se actualiza el estadillo de existencias de ese producto.

Los formularios de resultados intermedios deben tratarse como información redundante. Obsérvese que en el ejemplo anterior los datos adquiridos se utilizan para actualizar dos formularios.

Se trata de separar los aspectos constructivos y consultivos.

La construcción implica adquirir la nueva información conocida: “se aportan x unidades del producto y en la fecha z”.

La consulta implica definir el formulario de existencias como la suma de todas las unidades aportadas para un cierto producto menos la suma de las salidas de ese mismo producto.

Que por razones de diseño decidamos mantener redundancia es otra cuestión aparte.

Más que diferentes tipos de formularios, el analista debe estudiar la comunicación que cada suceso define sobre un formulario.


87

El objetivo es conocer los circuitos de las comunicaciones de entrada o sucesos constructores de un área de gestión. Es necesario preguntar por los sucesos iniciales: de qué forma o formas comienza o a petición de quién se inicia la gestión.

A partir de los sucesos iniciales se irá completando la secuencia temporal de sucesos necesarios para el área de gestión que se analiza.

�� Los formularios de consulta son los diferentes mensajes de salida del sistema. En muchos casos se descubren de forma vinculada a los diferentes sucesos constructores.

2 Consultores de nivel estratégico y táctico. Pueden ser los más complejos. Suponen un conocimiento profundo de la gestión del negocio. En muchos casos, dependiendo de la cultura organizacional, surgen de forma tardía cuando la organización comienza a tener experiencia con el sistema desarrollado.

Surgen como requisitos del nivel gerencial que deberá establecer sus indicadores de gestión. No suelen vincularse a constructores concretos. Normalmente su forma y estructura debe ser simple. Sin embargo su generación puede ser sofisticada. En muchos casos requieren gran esfuerzo de diseño. Puede ser necesario al análisis de almacenes de datos o la minería de datos.

Los requisitos de rendimiento y aspecto son importantes.

Suponen el aspecto más evolucionado de una aplicación.

3 Consultores de apoyo a la operación. Se trata normalmente de consultores vinculados a constructores. Consultores que son necesarios para planificar las operaciones diarias de la organización. Son de complejidad media. Los requisitos de aspecto y presentación no son críticos. Lo importante es el contenido de información. Los requisitos de rendimiento suelen ser críticos.

4 Consultores externos. Son todos aquellos consultores que salen del ámbito organizacional hacia los usuarios externos. Los requisitos de aspecto son importantes porque afectan a la imagen organizacional. Los requisitos de rendimiento no son críticos pero si el volumen de usuarios externos es considerable pueden exigir un diseño y arquitectura complejos.

5 Consultores de auditoría y control. Son consultores que facilitan el seguimiento del uso del propio sistema de información.

Pueden ser orientados al control de responsabilidad del sistema: quién está haciendo uso de las funciones del sistema, en qué momento y de qué forma.

Pueden orientarse a control de riesgos en la adquisición y distribución de la información.

Detección de responsabilidades de sucesos no iniciados. ¿Se ha emitido la facturación de los pedidos del mes pasado?

Detección de sucesos normativos no realizados. Normalmente serán sucesos que deben ocurrir según un plan preestablecido y con ciertas restricciones temporales. Por ejemplo la devolución de un material prestado antes de un cierto plazo. La comunicación de llegada de una mercancía en un plazo razonable.

El análisis detallado de consultores se simplifica cuando conocemos el modelo de datos del sistema. Esto no significa que no deben documentarse los consultores hasta que no se conozcan todos los constructores y se haya modelado el diagrama de datos. El analista puede ir detectando las necesidades de consulta a medida que van surgiendo en las entrevistas con los usuarios. Puede documentar los requisitos de rendimiento, aspecto, estructura y formato. Pero la generación de consultores no podrá definirse de forma precisa hasta que el modelo de datos no esté resuelto.

88

El diseño de consultores aporta además los criterios de desnormalización, es decir, incorporación de redundancia, desnormalización de especializaciones, etc.

Desde el punto de vista generativo tendrá que evaluarse la complejidad del consultor. Inicialmente bastará con estudiar si es SQL-generable o si es algorítmico. En el caso algorítmico el estudio de complejidad es imprescindible. Los tiempos de desarrollo en consultores algorítmicos pueden ser difíciles de establecer.

Por ejemplo, una empresa de corte de tableros recibe pedidos para proveer de pequeños tableros a empresas del sector del mueble de cocina y baño. La empresa compra grandes tableros y en función de los pedidos procede al corte en máquinas especializadas. La empresa tiene una persona que planifica los cortes. Actualmente el desperdicio es del orden del 10%. La empresa quiere reducir este desperdicio a la mitad.

Este problema no se soluciona con una simple consulta en SQL. Se trata de un consultor que requerirá un estudio algorítmico detallado. Es un problema de optimización cuya solución general se asocia al problema de la mochila.

.3.3.3.3 Análisis de procesos organizacionales.Análisis de procesos organizacionales.Análisis de procesos organizacionales.Análisis de procesos organizacionales.

Las comunicaciones de entrada se pueden ir derivando de la forma en que la organización va resolviendo los procesos de negocio. Cuando exista se puede utilizar la documentación existente de flujos de trabajo o procedimientos de calidad.

Normalmente esta documentación describe de forma procedimental y orientada a las responsabilidades de los actores que dan soporte a los procedimientos. Se trata de que cada actor sepa como debe actuar y qué responsabilidades tiene.

La documentación disponible será objeto de mejora separando las interacciones externas de las composiciones internas.

Las preguntas tenderán siempre a identificar la unidad comunicativa identificando el disparo o contacto inicial, el mensaje comunicado y el sincronismo de la reacción organizacional.

Si los procesos organizacionales no estuvieran documentados será preciso analizarlos para buscar los instantes en que se producen los sucesos comunicativos.

En la mayoría de los casos la trama de sucesos comunicativa está establecida. El analista simplemente deberá reconsiderar si los instantes comunicativos son los idóneos y los contenidos de los mensajes se adaptan a las necesidades organizacionales.

En algunos casos el analista deberá diseñar la trama de observación. Deberá decidir cuales son los instantes más adecuados para la captura. Cómo se insertan en el proceso organizacional y cuales son las alternativas de soportes que minimizan el uso de recursos y garantizan la mayor adaptación posible.

.4.4.4.4 Análisis de observaciones de estado.Análisis de observaciones de estado.Análisis de observaciones de estado.Análisis de observaciones de estado.

Existen sucesos cuya composición comunicativa es trivial. La información que aportan es el hecho de haber ocurrido. El analista debe preocuparse de establecer si su detección es relevante para la organización. Estos sucesos son de varios tipos. Pueden afectar a los elementos básicos o mediadores aportándoles valor.

Cada vez que algo ocurre en la organización hemos de considerar si el estado de algún elemento básico sufre un cambio relevante. Por ejemplo, una empresa fabrica muebles de cocina. Fabrica pedido a pedido. El pedido se recibe, se planifica la producción. Entra en producción. Una vez finalizada la fabricación se lleva al muelle de carga de allí lo carga el transportista para llevarlo al cliente.

El pedido está en diferentes estados. Puede ocurrir que el pedido se haya finalizado y esté todavía en el área de fabricación. Que la fabricación se finalice no garantiza que el pedido esté en el


89

muelle de carga. Los elementos fabricados de un pedido tiene diferente valor, o estado, según estén o no en el muelle de carga. Por lo tanto el suceso que comunica que un pedido se ha desplazado al muelle de carga cambia el estado de un pedido. La estructura del mensaje puede ser mínima: el identificador del pedido. Lo importante es que el pedido está en el muelle de carga y el transportista lo podrá cargar. No disponer de esta información puede suponer pérdidas de tiempo y dinero para la organización

.5.5.5.5 El aEl aEl aEl análisnálisnálisnálisis is is is generativo en ausencia de documentación.generativo en ausencia de documentación.generativo en ausencia de documentación.generativo en ausencia de documentación.

Diseñe formularios y procesos con los usuarios. Si los usuarios no se ven obligados a pensar en la estructura de información que necesitan y en los procesos por los que van a regirse su análisis corre graves riesgos.

5.7.2 Análisis de salidaAnálisis de salidaAnálisis de salidaAnálisis de salidas vinculadas vinculadas vinculadas vinculadas.s.s.s.

Todo mensaje de entrada puede servir de fuente de información para inferir la necesidad de comunicaciones de salida vinculadas.

Se denominan sucesos vinculados porque en tiempo de análisis surgen de forma vinculada al mensaje de entrada. Normalmente en diseño también deberán vincularse de modo que el formulario que contenga un determinado suceso de entrada deberá permitir “disparar” los sucesos de salida vinculados.

Las necesidades de sucesos vinculados pueden ir apareciendo a medida que se va analizando con detalle los sucesos de los formularios.

Todo mensaje de entrada puede contener aspectos consultores vinculados

.1.1.1.1 Consultores previos a un constructorConsultores previos a un constructorConsultores previos a un constructorConsultores previos a un constructor

Para determinar el mensaje de entrada el usuario necesita informaciones previas que le permiten decidir los datos que comunicará. Por ejemplo, una asignación de personal a un proyecto puede requerir un listado de la ocupación del personal.

Los consultores previos deben detectarse preguntando al usuario por ellos en cada comunicación de entrada que informen. Un consultor previo permite decidir una elección más adecuada de los datos de entrada al suceso constructor. Por lo tanto en el proceso organizacional relacionado con esa comunicación existe una decisión, elección, estimación, diagnóstico, juicio, etc. El consultor previo ayuda o facilita ese proceso.

Es posible que el agente que comunica la información de un suceso requiera más de un consultor previo.

La pregunta básica es: ¿Qué información necesita para poder realizar este proceso? o ¿Qué información le podría suministrar el sistema para facilitar su trabajo?

.2.2.2.2 Consultores acreditativos de constructorConsultores acreditativos de constructorConsultores acreditativos de constructorConsultores acreditativos de constructor

El suceso requiere una salida o comunicación a agentes externos. Se trata de un consultor que “certifica” la transacción realizada, normalmente será una copia de los datos capturados. Es lo que antiguamente se denominaba impresión “hardcopy”. Puede ser la expedición de un recibo, la copia de un pedido…

.3.3.3.3 Consultores informativos de un constructorConsultores informativos de un constructorConsultores informativos de un constructorConsultores informativos de un constructor

Los consultores informativos suponen la comunicación a agentes organizacionales del contenido del mensaje comunicado por un suceso.

90

Deberá establecerse para quién es importante conocer la nueva información o quién tendrá que reaccionar frente a esa información. En definitiva a quién es necesario y a quién conviene informar.

��,�� *��1��'�� '��'��(�

Los consultores informativos pueden tener dos objetivos diferentes. Provocar que el actor que los recibe inicie otro suceso o informar del estado de los asuntos sin responsabilidad inmediata para la ejecución de sucesos.

5.7.3 Consultores de auditoríaConsultores de auditoríaConsultores de auditoríaConsultores de auditoría

.1.1.1.1 Auditoría de disparo o de ocurrencia: Auditoría de disparo o de ocurrencia: Auditoría de disparo o de ocurrencia: Auditoría de disparo o de ocurrencia:

�� ¿Qué personas deben conocer que esto ha ocurrido?

No se trata de conocer el contenido sino la mera ocurrencia del suceso. Auditamos la ocurrencia, por ejemplo, cuando pensamos que el responsable del disparo puede fallar o cuando alguien necesita conocer índices de actividad sobre uno o más sucesos.

�� ¿La frecuencia de ocurrencia de una gestión está descendiendo? ¿Tenemos los mismos pedidos que en la misma semana del año pasado? ¿El tiempo medio entre el pedido y la carga del camión se ha dilatado?

.2.2.2.2 Auditoría de contenidosAuditoría de contenidosAuditoría de contenidosAuditoría de contenidos

�� ¿Alguien debe supervisar los datos que se aportan?

La auditoría de contenidos permite establecer reglas de negocio respecto al comportamiento.

Por ejemplo: “el importe de pedido no puede superar el riesgo establecido para el cliente salvo que la operación sea autorizada por el Jefe Comercial”.


91

La auditoría de contenidos conduce a dos búsquedas de requisitos:

Una para estudiar las necesidades y la forma más adecuada de informar al “auditor” que la regla de negocio ha sido transgredida. Si el “auditor” usa con frecuencia el sistema se puede proponer un consultor que muestre todas las “transgresiones” cada vez que el usuario se conecte, a primera hora de la mañana, o a petición del usuario. Si no usa el sistema con frecuencia será necesario hacerle llegar la información con la urgencia requerida. Por ejemplo usando correo electrónico.

La otra búsqueda de requisitos sería para determinar el constructor que permite autorizar o denegar una determinada operación.

Los sucesos vinculados por auditoría de contenidos deben de permitir el sincronismo de reacción. El mismo entorno que comunica la “trasgresión” debe ser capaz de permitir la respuesta de quien controla. Es decir el mismo medio a través del cual se le comunica el consultor al usuario tiene que permitir la respuesta.

�� ¿El importe medido de facturación está decreciendo? ¿Cual es la evolución de ventas por comercial?

.3.3.3.3 Auditoría de secuencias normativasAuditoría de secuencias normativasAuditoría de secuencias normativasAuditoría de secuencias normativas

En los diagramas de comportamiento aparecen secuencias normativas de sucesos. Con ello queremos decir que los usuarios, u otros mediadores, esperan que una vez ha ocurrido un determinado suceso se alcance un suceso relacionado en un plazo razonable de tiempo. Es normativo que si un avión despega debería aterrizar en un plazo razonable. Es normativo que si un cliente hace un pedido se le acabe facturando en un plazo razonable de tiempo.

La gravedad que se atribuya a los diferentes sucesos de un proceso sugiere diferentes tipos de auditoría.

Los consultores admiten diferentes estilos de realización. La comunicación de la trasgresión de las reglas de auditoría puede ser de tipo “lo antes posible”, es decir síncrona, o a petición del usuario, es decir asíncrona. Según las consideraciones de urgencia sobre el proceso o las consideraciones de gravedad sobre las reglas de auditoría la organización optará por un estilo de comunicación.

Cuando usamos mecanismos de comunicación para informar lo antes posible los mensajes pueden ser específicos informando del hecho concreto a las personas indicadas.

Alternativamente podemos utilizar un estilo de comunicación en demanda. En este caso es el usuario el que accede a consultores que le permiten supervisar el cumplimiento de las reglas de auditoría.

5.7.4 Constructores vinculadosConstructores vinculadosConstructores vinculadosConstructores vinculados

.1.1.1.1 Auditoría de comunicacionesAuditoría de comunicacionesAuditoría de comunicacionesAuditoría de comunicaciones

Todo suceso consultor puede contener aspectos “constructivos” si queremos controlar su ocurrencia (auditoría de emisión).

Pero la auditoría no garantiza que el consumidor haya recibido la información. Si además buscamos garantía es necesario incorporar constructores de confirmación (auditoría de recepción).

92

��,�� *��'��1��'�� '��(�

Pueden aparecer también constructores vinculados a constructores. Por ejemplo constructores de inserción condicionada. Cuando se formula un pedido si el cliente no existe se le da de alta. Es posible que un suceso de gestión requiera vinculación con uno o más sucesos de mantenimiento básico.

.2.2.2.2 Análisis de excepciones y alternativas.Análisis de excepciones y alternativas.Análisis de excepciones y alternativas.Análisis de excepciones y alternativas.

Normalmente las personas cuentan los sucesos “normales”, los que ocurren con más frecuencia. A los sucesos excepcionales se les da poca importancia. El analista deberá investigar los tratamientos excepcionales. Estos tratamientos son porcentualmente irrelevantes pero deben ser detectados.

Pueden aparecer excepciones en los tratamientos internos, es decir, los que dependen de la propia organización. Son sucesos asociados a la aprobación, conformidad o toma de decisión. El analista siempre verificará la posibilidad de rechazos o decisiones alternativas. El tipo de preguntas a formular nunca se harán en forma positiva (¿siempre se aprueba?, ¿todos se aprueban?) sino en forma negativa (¿es imposible que ocurra de otra forma?).

Otras excepciones a considerar son las desviaciones de presunciones optimistas o la saturación de recursos. En procedimientos en los que se usan recursos de cualquier tipo (asignaciones, planificaciones) debemos indagar si es posible que esos recursos no estén disponibles por el propio uso organizacional por saturación. La saturación puede afectar a los mediadores que deben responsabilizarse de una gestión o a la imputación de elementos básicos a un medido de producción o a un contenedor.

Pueden aparecer excepciones en aspectos externos, es decir, aquellos sucesos que pertenecen al Sistema Objeto pero que están fuera del ámbito de la organización. Si estamos analizando una gestión de envío de pedidos siempre será necesario buscar posibles incidencias. ¿Qué pasa si el camión tiene una avería? ¿Qué pasa si el cliente rechaza la mercancía?

5.7.5 Análisis de Análisis de Análisis de Análisis de Objetos Objetos Objetos Objetos de negocio.de negocio.de negocio.de negocio.

Los usuarios pueden comenzar por una descripción de objetos que se utilizan en el proceso. Téngase en cuenta que, en la mayoría de los casos, los procesos de negocio son orientados a objeto. No en el sentido más técnico de la palabra objeto, una clase, sino en el sentido más amplio de los usuarios una estructura de información compleja y variable. Los objetos de usuario


93

suelen ser agregados y complejos. Las clases de negocio preliminares designan una amalgama no claramente delimitada de clases “informáticas” es decir plenamente identificadas. Cuando un usuario habla de una factura, lo hace en sentido laxo. Incluye todas las posibles configuraciones de facturas que se dan en su negocio. Para un informático la factura no existe. Existe un diagrama de clases que describen la factura. Habrá como mínimo una clase, que el informático puede llamar factura, identificada con un número de factura y que solo contendrá los datos de la cabecera de la factura. Existirá otra clase líneas de factura con otro identificador asociado. Si las líneas son de varios tipos el informático especializará en varias clases más, etc.

Los usuarios no piensan nunca así. Mantienen un pensamiento complejo y agregado respecto a los objetos agregados.

Cuando el usuario comience a describir objetos, el analista tomará nota de sus descripciones. Según la forma de describir del usuario el analista tratará de identificar si se trata de clases o propiedades, si son descripciones de elementos básicos o derivados. SI las descripciones son estáticas o dinámicas y si el objeto descrito es complejo o simple.

El problema surge cuando el análisis directo no es aplicable. EL análisis generativo es aplicable cuando las interacciones comunicativas identifican un mismo objeto de negocio o componentes asociadas al mismo objeto de negocio. Es decir cuando la parte básica del objeto de negocio puede identificarse y, por lo tanto, asociarse a los sucesos comunicativos que la generan.

Pero existen objetos con una composición mixta, básica y derivada, en los que lo básico es está asociado a objetos diferentes del objeto de negocio que analizamos. No es obvio el comportamiento de las comunicaciones que afectan a un objeto de negocio “nómina”. O su estructura temporal es laxa y no tan fácil de seguir como una gestión de pedidos. El análisis de composición de objetos derivados permite abordar el problema en estos casos.

5.7.6 La busqueda de inLa busqueda de inLa busqueda de inLa busqueda de interacciones comunicativas a partir de objetos de negocioteracciones comunicativas a partir de objetos de negocioteracciones comunicativas a partir de objetos de negocioteracciones comunicativas a partir de objetos de negocio

Observe siempre qué expresiones usa el usuario. Identifique si el usuario describe de forma estática, descripción de características de objeto, o está describiendo un cambio que se requiere o que se produce, descripción de características de un suceso.

Identifique si el usuario describe una propiedad elemental o algo complejo. Si se trata de un complejo averigüe que tipo de identificación tiene asociada dependiente o independiente.

Cuando el usuario describa objetos que no pueda asociar con facilidad a información proveniente de sucesos de entrada obtenga la composición y comience a analizar las componentes.

Busque el origen de cada componente. Si se trata de una característica básica debe llegar a conocer cual es el suceso de entrada que informa de ella.

Si es una característica derivada deberá analizar la expresión de derivación y el mapa de dependencias con otras propiedades hasta llegar a las características básicas. Deberá anotar si la derivación es estática o dinámica (5.2.1des hasta llegar a las características básicas. Deberá anotar si la derivación es estática o dinámica (5.2.1).

Desarrolle el árbol de derivación es decir la forma en que se componen las derivaciones.

Tenga en cuenta que cada derivación no es más que una función de consulta. Si se trata de derivaciones estructurales deberá indicar la relación estructural mediante lenguaje natural (con expresiones similares a las utilizadas en una sentencia SQL), usando estructuras de adquisición o con otro lenguaje.

Si se trata de derivaciones algorítmicas deberá definir el cálculo mediante alguna técnica de especificación.

94

Imagine la siguiente hoja de nómina. Es un objeto con gran contenido derivado. El sucesos “emitir nómina” solo aportaría el mes que se remunera y la fecha de emisión.

Podríamos describir este objeto mediante la siguiente estructura.

COMPOSICIÓN ORIGEN

NOMINA=

Fecha emisión + e

Mes + e

Empleado(id)=

< nombre+ empleado.nombre

nif+ empleado.nif

salario base>+ empleado.salario

descuento ausencias+ calcular descuento ausencias( )

salario base neto+ salario base- descuento ausencias

ayuda familiar+ calcular ayuda familiar( )

cotización SS+ calcular cotización SS( )

retención IRPF+ calcular retención IRPF( )

salario neto+ salario base neto+ ayuda familiar- retención IRPF

retención plan jubilación+ calcular retención plan jubilación( )

líquido+> salario neto - retención plan jubilación

Ahora deberíamos conocer la estructura de cada derivación. Eso nos llevará a nuevos objetos derivados o a los sucesos generadores de algún objeto.

1-Octubre-1997

Nómina de SEPTIEMBRE de 1997

EMPLEADO Gutierrez Gomez, Francisco Antonio 22.336.443-R

SALARIO BASE 3.500

AUSENCIAS 3 días -785

SALARIO BASE NETO 2.715

AYUDA FAMILIAR 130

COTIZACIÓN S.S. -800

RETENCIÓN IRPF 9% -424

SALARIO NETO 1.621

PLAN DE JUBILACIÓN 2% -110

LÍQUIDO A PERCIBIR 1.511


95

� �� #��

� ��

� �� $� ��%��

� ��

� �� "�$&

'��

'��

'��(�"�$&

'��

� �� )��

'��

��*�� +

� ��

,��

� �� (��

'��

��-�,�+

�� "�$&

��

��

��

��

$ ��

��

.��/�� / ��

.��/�� / ��

��

�0��'�',��1��"2��"'��

�

��,�� .�+�� 1�'��

Cada una de las funciones que calculan aspectos intermedios o componentes derivadas tiene una especificación de cálculo asociada.

Esta especificación puede ser descrita de diferentes formas. Por ejemplo el porcentaje a aplicar para calcular el plan familiar se obtiene a partir de la siguiente tabla.

�

nº de hijos

sueldo base 0 1 2 3 4 >4

≤3.000 10 9 9 8 7 7

< 5.000 12 11 10 10 9 8

≥ 5.000 15 14 13 13 12 11

96

Los objetos derivados pueden suponer descripciones de tipo algorítmico o expresiones de estructuras de objetos.

Por ejemplo, cada una de las líneas de la factura de un cliente resulta de obtener todas las lineas de albarán de ese cliente para el período de facturación especificado. Agruparlas por producto y precio para así acumular todas las unidades del mismo producto y precio.

Especificación de sucesos

97

6666---- Especificación de sucesosEspecificación de sucesosEspecificación de sucesosEspecificación de sucesos

6.1 ��

Un suceso comunicativo es un requisito genérico refinable. La estructura de composición de un suceso se caracteriza por los tres aspectos básicos de toda comunicación de mensajes:

• Contacto que recoge todos los requisitos relativos al escenario en el que se establece la

comunicación. Las condiciones de disparo o de contacto. Desde los imprescindibles requisitos

de disponibilidad hasta los posibles requisitos de soportes específicos o de protocolos de

verificación.

• Descripción comunicativa que recoge todos los requisitos relativos al mensaje que se

comunica al sistema y que constituye la descripción del suceso acaecido y la aportación de

nueva información. La descripción del mensaje es la parte más esencial de un suceso.

• Influencia o reacción que recoge todas las conclusiones y derivaciones que el sistema necesita

realizar. Todos los requisitos de comunicaciones de salida vinculadas que deben informar a

otros actores del sistema de hechos relacionados o derivados del que en ese momento se

informa.

6.2 ��"�

Los sucesos comunicativos constituyen la esencia de una especificación de requisitos de negocio. En este capítulo se propone una estructura para los sucesos que contiene diferentes facetas descriptivas relacionadas con la especificación e investigación de requisitos.

98

Todos los sucesos tendrán asociado un identificador

• Identificador numérico/alfanumérico. Coincidirá siempre con la numeración del esquema de sucesos. Como es frecuente que se utilicen herramientas diferentes para diagramas y para el texto de la especificación es conveniente poner cuidado en la concordancia de identificador y de nombre. De lo contrario se crea confusión y se dificulta la localización e identificación correcta de elementos en la especificación.

Los identificadores pueden ser alfanuméricos si contienen acrónimos o abreviaturas de áreas de negocio o de procesos de negocio (FAC 1, FAC 2, GESMED 2.2...).

• Nombre del Suceso El nombre del suceso debe ser consensuado con los usuarios.

El nombre de un suceso puede construirse siguiendo las recomendaciones de Yourdon. Propone una estructura de nominación basada en la secuencia:

<emisor+acción+objeto+[cualificación]>

Un fotógrafo entrega un reportaje

La editorial devuelve el albarán firmado

En algunos casos podemos reemplazar al emisor por el receptor aunque éste sea un actor secundario y se limite a dar soporte al proceso de adquisición.

<receptor + acción+objeto+[cualificación]>

Comercial recibe el albarán firmado

6.3 ��"�

6.3.1 DESCRIPCIÓN GENERALDESCRIPCIÓN GENERALDESCRIPCIÓN GENERALDESCRIPCIÓN GENERAL

La descripción general del suceso contiene los gráficos y el texto que permiten comprender el suceso. Normalmente será una enumeración de las actividades que se realizan.

En la descripción general podemos encontrar las siguientes secciones:

• Objetivos En el caso más habitual, el noventa por cien de las veces, los objetivos de un suceso se resumen en una frase simple.

Los objetivos de un suceso son dependientes del ámbito en el que se considere.

En el ámbito del Sistema de Información los objetivos responden a los propósitos de observación, influencia o control del sistema objeto. Se trata de los aspectos denotativos del mensaje, del contenido descriptivo. Qué fenómeno o fenómenos comunicamos.

En el ámbito del Sistema Organizacional los objetivos se relacionan con la función conativa del mensaje, la intención de inducir un determinado comportamiento. En este ámbito los objetivos se complican porque pueden aparecer diferentes intenciones y por lo tanto diferentes objetivos. Es necesario conocer cuál es la reacción organizacional frente al mensaje recibido. Si el analista no comprende la reacción de los diferentes actores organizacionales es difícil que pueda ajustar el contenido adecuado del mensaje a las necesidades organizacionales.


99

Cuando aparezcan diferentes intenciones organizacionales el analista debe considerar si son o no compatibles. En caso de incompatibilidades deberán utilizarse técnicas de resolución de conflictos.

• Descripción La descripción muestra una visión más detallada de las actividades del sistema de información indicando las peculiaridades de los soportes. Pueden aparecer descripciones de los diferentes canales de adquisición utilizados o de los procedimientos diferidos de captura, cambios de formato, etc.

La descripción debe mostrar todos los sucesos físicos y los procedimientos manuales requeridos en cada suceso comunicativo.

Puede enumerar las distintas acciones y responsabilidades del suceso. No constituye una especificación rigurosa sino una explicación que tiene como objetivo facilitar la comprensión del suceso.

• Necesidades y problemas Este apartado es opcional. El analista debe siempre detectar la expresión de necesidades no cubiertas o la indicación de problemas por parte de los usuarios.

Necesidades y problemas pueden estar vinculados a los contenidos de la información o a los agentes soporte que la manipulen.

Si se trata de los contenidos será necesario remodelar con los usuarios los mensajes.

Las necesidades y problemas dan lugar a requisitos concretos (estructurales, de suceso, de soporte, de rendimiento...). Si el problema está en la comunicación será preciso revisar la descripción de la comunicación.

Si se trata de los soportes será necesario su reemplazo o su optimización. En este caso los requisitos estarán asociados a la disponibilidad o al rendimiento de alguno de los soportes.

6.3.2 DESCRIPCIÓN DEL CONTACTODESCRIPCIÓN DEL CONTACTODESCRIPCIÓN DEL CONTACTODESCRIPCIÓN DEL CONTACTO

La descripción de contacto se refiere a todo aquello que es necesario para que pueda tener lugar el establecimiento de la comunicación. Esto implica diferentes requisitos que no son solo del software, sino del sistema de información y de los agentes y tecnologías que lo soportan. No exclusivamente la digital.

Es posible que se requieran documentos acreditativos, la cédula de habitabilidad, el certificado de empadronamiento, el pago del último recibo, etc. Será conveniente documentar o definir una lista de verificación (checklist) de cualquier aspecto documental que se considere necesario o conveniente.

Las condiciones generan diferentes tipos de requisitos. Las condiciones de disponibilidad dan lugar a requisitos operacionales de disponibilidad y de soporte.

• Disponibilidad

� G��''��%�� +�� :�4��(((��

� �� /� �� &�� &��'�� %�:� � ��'��:�

�%�'��%��:� ��'��:� ��+�'�� +��@�� '�&�'�� ;� '�%�� &��'��:�

��+�� $�� '��(��

� *��/��+��'�� '�%��'�'�� +��@�� '�%�� $� ��'��(�

� *��'��/� ��'�� '�� +��'�&�'��@��%��

4�+��'��$��%��'�� '��(��&��'�� +��

�� +�'��@��'�� 1��$��%��0�� (��

• Responsabilidad de actores

� �� /��@��0� ��+�'��'��'�%��'�'��

100

� �'�� '��/�� 2��'��6� ��'�� '��'�� '��

�&��'��(�*�%��+�%��'�� '��(��@��'�� '�%��

��'�� '�� '��(��

• Protocolos de acreditación documental: verificaciones sobre los datos aportados, ya sea

mediante certificaciones documentales ya mediante inspección visual, diagnóstico, juicio,

estimación....

• Protocolos de verificación de elementos físicos asociados a la comunicación. Entrada de

material en un almacén. Book de fotógrafo...

6.3.3 DESCRIPCIÓN DE LA COMUNICACIÓNDESCRIPCIÓN DE LA COMUNICACIÓNDESCRIPCIÓN DE LA COMUNICACIÓNDESCRIPCIÓN DE LA COMUNICACIÓN

.1.1.1.1 Estructura del mensajeEstructura del mensajeEstructura del mensajeEstructura del mensaje

Los sucesos pueden aportar información de objetos desconocidos por el sistema.

• Individuos aislados no complejos. Por ejemplo informar de un nuevo producto en el catálogo

• Conjuntos de individuos. Por ejemplo informar de que un conjunto de personas solicitan que

se asfalte una calle.

• Agregados o complejos. Por ejemplo un pedido con el conjunto de productos solicitados A su vez cada uno de ellos puede admitir variantes es decir especialización. Podríamos tener conjuntos de individuos con variantes o agregados de variantes. Por ejemplo un pedido con líneas de materias primas, de productos confeccionados o de servicios prestados como reparaciones o transportes.

Los sucesos pueden aportar información sobre objetos conocidos por el sistema, es decir información contextual. Que de nuevo puede ser:

• De individuos aislados por ejemplo informar del nuevo precio de un producto en el catálogo

• De conjuntos de individuos por ejemplo informar del importe de ayuda familiar que le ha

correspondido a un conjunto de personas que lo solicitaron

• De aspectos parciales de un complejo. Por ejemplo informar de que 20 unidades del producto

XFRS del pedido 345/08 han sido ya producidas en este instante por el operario R2P2.

Todos estos aspectos pueden ser descritos en lenguaje natural. Siempre hay que tener en cuenta que la forma de describirlos sea completa. Podemos usar una notación estructurada para hacerlo. Pero si lo hacemos correctamente es indiferente. La estructura del mensaje asociado a un suceso debe definir los tipos de elementos descritos.

• Si se trata de nueva información básica describimos la estructura en cuestión. Por ejemplo un

suceso para dar de alta un cliente podría describirse mediante la siguiente estructura: Cliente= < código+ fecha_alta+ CIF+

nombre+ calle+ número+ escalera+ puerta+ C.P.+ población + provincia >


101

Eso mismo podemos decirlo en lenguaje natural. Pero sin ambigüedad. De forma completa. No sirve una descripción del tipo “se toman los datos del cliente el cif, el nombre, dirección, etc.” O “se toman los datos relevantes del cliente”. Habrá que indicar “del cliente es necesario conocer Código, fecha en que se dio de alta, su NIF el nombre y apellidos su dirección completa para envíos calle, número, escalera, puerta y código postal así como la población y la provincia”

También podemos adjuntar una ficha o formulario de cliente, si existe, que describa claramente la

composición.

Si se trata de nueva información contextualizada tendremos que identificar el contexto.

Si quiero referirme a la propiedad (o propiedades) de un individuo podré escribir:

Objeto de negocio(id)<propiedad> Donde id lo utilizamos para indicar que usaremos alguna expresión o forma de identificación de un objeto (de una instancia) concreto.

Es decir basta con indicar que clase de objeto debo identificar y que propiedades serán informadas. Por ejemplo para indicar que un cliente puede cambiar de dirección podemos expresar.

CLIENTE (id) < calle+

número+ escalera+ puerta+ C.P.+ provincia >

Donde indicamos que solo informaremos de que ha cambiado la dirección del cliente. El resto de sus propiedades permanecen inalteradas.

Si quiero referirme a las propiedades de un conjunto de individuos que identificaré uno a uno escribiré

{Objeto de negocio(id)<propiedad>}

Por ejemplo supongamos que es necesario cambiar el precio de varios productos. { PRODUCTOS (id) < precio > }

Este tipo de iteración es poco frecuente. Normalmente los conjuntos de iteración para objetos existentes vienen determinados por alguna característica. Si quiero referirme a las propiedades de un conjunto de individuos necesito indicar el conjunto de los individuos.

{Objeto de negocio(id)<propiedad>} { Objeto de negocio(criterio de selección)<id>}

Necesito expresar dos aspectos. Uno es la estructura de la información que comunicaré el otro el conjunto de individuos conocidos por el sistema de los que necesitaré informar.

Por ejemplo, una empresa ha recibido solicitudes de empleo. Dirección revisa las solicitudes y decide aceptarlas indicando el nivel profesional al que se adscribe o rechazarlas.

�� 2/1/34�1$5/6/,78 19� �

��:;�1��"�%9� � �[�N��'�� 2��9��2 �'��6�6K� M�O�

��8��<��=� �

��>� �

��?��

Obsérvese que se ha indicado una función genérica de consulta no existe(decisión) cuyo significado puede ser ambiguo. La función no existe() es una función genérica que nos dice que una propiedad nunca ha sido informada al sistema. Desde el punto de vista de la representación,

102

del diseño, esto puede solucionarse mediante el uso de valores nulos o de otras soluciones más redundantes.

Puedo decirlo en lenguaje natural pero es importante determinar ambos aspectos señalados: estructura que se comunica y descripción del contexto de iteración es decir descripción del conjunto de objetos afectados “todas las solicitudes que todavía no se han evaluado”.

Si quiero referirme a la propiedad de un elemento de un agregado escribiré

Objeto de negocio(id).objeto componente(id)<propiedad>

Por ejemplo para indicar que ha habido una alteración en las unidades pedidas de un determinado producto de un determinado pedido escribiré:

PEDIDO(id).producto(id)= < cantidad>

La estructura del mensaje se refina en los siguientes requisitos.

1111 ComponentesComponentesComponentesComponentes

La estructura de composición de los objetos sobre los que se informa.

2222 DominiosDominiosDominiosDominios

Debe indicarse para cada componente cual es el dominio asociado. Esto permite mantener adecuadamente un diccionario de datos.

3333 Valores inicialesValores inicialesValores inicialesValores iniciales

Los valores iniciales pertenecen en realidad al ámbito del uso.

4444 DerivaciónDerivaciónDerivaciónDerivación

La derivación puede ser de componentes. “el precio total es el precio unitario multiplicado por las unidades más el importe de IVA”

Pero como hemos visto la derivación puede generar estructuras más complejas.

��:;�1��"�%9� � �[�N��'�� 2��9��2 �'��6�6K� M�O�

Por ejemplo podríamos indicar que el conjunto de líneas de un albarán se deriva de las lineas de un pedido.

LINEAS ALBARÁN= d PEDIDO(id).LINEAS = { <referencia+ {<referencia cantidad_servida cantidad_pedida precio_a_facturar + precio_pedido>} > } LINEAS +


103

��,�� G�� '��'�%��'��1��

.2.2.2.2 Restricciones comunicativas.Restricciones comunicativas.Restricciones comunicativas.Restricciones comunicativas.

Definen el estado necesario en el sistema para que la comunicación sea aceptable. Necesitan referir elementos de la estructura de comunicación. Son restricciones estructurales pero con mayor énfasis en la relación entre lo comunicado y lo conocido. Por ejemplo, “el importe del pedido no puede superar el riesgo asegurado para el cliente”.

Las condiciones comunicativas pueden conducir a

1111 Restricciones EstructuralesRestricciones EstructuralesRestricciones EstructuralesRestricciones Estructurales

Son restricciones de la propia estructura del mensaje. No es necesario conocer el contexto para poder describirlas.

2222 Restricciones ContextualesRestricciones ContextualesRestricciones ContextualesRestricciones Contextuales

Son las que se basan en contrastar el mensaje que se comunica con lo ya conocido por el sistema.

3333 Restricciones de privacidadRestricciones de privacidadRestricciones de privacidadRestricciones de privacidad

Son restricciones de especialización asociadas a diferentes criterios de privacidad para cada usuario. Pueden afectar a los dominios, a la derivación o a la composición.

Establece niveles de privacidad sobre la estructura del mensaje. Puede afectar a las componentes que cada tipo de usuario puede ver (que no vea los campos ay b) o a los dominios a los que puede acceder (que solo le muestre los pedidos de su

Los requisitos de privacidad suponen la existencia de diferentes grados de autoridad sobre el contenido del mensaje de un suceso. Es posible que un tipo de usuarios sólo visualice determinados campos o que otro tipo usuarios sólo pueda trabajar con determinados clientes. Los distintos grados de autoridad inducen especializaciones en la estructura de adquisición. Estas especializaciones pueden afectar a las componentes o a los dominios.

Especialización de estructuras

Especialización de dominios

.3.3.3.3 Requisitos de fiabilidadRequisitos de fiabilidadRequisitos de fiabilidadRequisitos de fiabilidad

Los riesgos de fiabilidad establecen la confianza que debe tener el sistema sobre el actor primario que aporta los datos. Si el analista detecta riesgos de fiabilidad será necesario prever sucesos de inspección que validen la bondad de los datos.

104

La escasa fiabilidad tiene que ver con un inadecuado diseño de las comunicaciones. Es posible que el actor aporte datos incorrectos por error, por incomodidad o de forma malintencionada. Si el sistema de adquisición de datos resulta incómodo o requiere esfuerzos suplementarios a su trabajo habitual, el usuario intentará evitarlo. Si el usuario puede tener perjuicio por aportar los datos que el sistema le pide, tendrá reticencia para hacerlo.

Los requisitos de fiabilidad aparecen cuando se consideran las condiciones en el ámbito del sistema organizacional. La documentación previa que se requiere a un actor cuando comunica con el sistema constituye requisitos de fiabilidad. El problema de los requisitos de fiabilidad es que son difíciles de obtener porque requieren un buen conocimiento del contexto cultural de los actores primarios. Puede ocurrir que, al analizar un sistema, el analista nunca llegue a entrevistarse con un actor primario. Es inusual, aunque no adecuado, que en el análisis del sistema de información para la gestión de un ayuntamiento el analista llegue a hablar con los ciudadanos.

Los requisitos de fiabilidad pueden generar:

• Requisitos de procedimientos manuales: como se vio en el apartado de condiciones del entorno de contacto.

• Protocolos de identificación de emisores

• Protocolos de acreditación de los contenidos de mensajes.

Se trata de listas de verificación con los documentos acreditativos que deberá aportar el emisor para garantizar o acreditar los datos y su fiabilidad.

• Requisitos de sucesos de autorización, validación y verificación.

Es posible que al detectar problemas de fiabilidad se incorporen al proceso nuevos sucesos en los que una persona experta revise y valide la información aportada. Se trata de reglas de negocio de comportamiento.

.4.4.4.4 Requisitos de usoRequisitos de usoRequisitos de usoRequisitos de uso

La descripción de comunicación recoge todas las necesidades de comunicación de un suceso. Cuál es el mensaje que se comunica y qué otras necesidades vinculadas de comunicación requiere.

Siempre pediremos a los usuarios que aporten cualquier formulario que utilicen en los procedimientos de gestión. De no existir ningún formulario se propondrá a los usuarios que diseñen uno utilizando las herramientas ofimáticas a las que estén acostumbrados. En su defecto el analista diseñara con los usuarios los formularios necesarios. Mediante esta interacción obtendremos los requisitos estructurales del suceso caracterizados en la estructura de adquisición.

La información descrita en un mensaje de entrada define la nueva información que llega al sistema. Es la que permite decidir el modelado esencial de la memoria del sistema. También es esencial para el diseño de las pantallas de usuario.

Los requisitos de las comunicaciones de entrada son de varios tipos. Normalmente se pueden expresar mediante una estructura tabular.

1111 Localizadores/FiltrosLocalizadores/FiltrosLocalizadores/FiltrosLocalizadores/Filtros

Un localizador es una estructura de interfaz que permite trabajar con un determinado tipo de objetos de negocio. EL localizador muestra todos los objetos que interesan a un usuario. Usualmente debe mostrar el estado en que se encuentra cada uno permitiendo el acceso a las características de cada objeto para su manipulación.

Los localizadores manejan conjuntos de instancias y deben disponer de filtros para que cada usuario pueda localizar los que sean de su interés.


105

2222 Formularios y documentos de usuarioFormularios y documentos de usuarioFormularios y documentos de usuarioFormularios y documentos de usuario

Todo sucesos y los consultores vinculados pueden estar asociaos a documentos de usuario que será conveniente reproducir o, en su caso, mejorar.

3333 Requisitos deRequisitos deRequisitos deRequisitos de aspecto aspecto aspecto aspecto

Los requisitos de aspecto deberían estar estandarizados en su mayoría para cualquier organización. Se refieren a todos los criterios de forma: tipos de letras, colores, distribuciones de elementos en pantallas y listados...

4444 Requisitos de soporte Requisitos de soporte Requisitos de soporte Requisitos de soporte editorialeditorialeditorialeditorial

106

6.3.4 DESCRIPCIÓN DE LA DESCRIPCIÓN DE LA DESCRIPCIÓN DE LA DESCRIPCIÓN DE LA REACCIÓNREACCIÓNREACCIÓNREACCIÓN DEL SISTEMA DEL SISTEMA DEL SISTEMA DEL SISTEMA

Cuando un sistema de información conoce que algo ha ocurrido en el entorno que observa

reacciona de la siguiente manera:

• Registra o almacena el nuevo conocimiento.

• Extrae todas las conclusiones necesarias que pueden inferirse al incorporar el nuevo

conocimiento.

• Pone a disposición de los actores adecuados el nuevo conocimiento o las conclusiones que de

el se han derivado.

Esta caracterización guía la estructura de los requisitos de reacción. Podemos hablar de los

requisitos de objetos de negocio básicos o de clases de objeto básicas, de los objetos de negocio

derivados que es necesario obtener como conclusión del nuevo conocimiento y de las

comunicaciones vinculadas que definen quién debe conocer todo este conocimiento.

Funciones y reglas de negocio En este ámbito es frecuente encontrar los términos Función de negocio o Regla de negocio.

Una función de negocio, cuando se aplica en el ámbito de los tratamientos de la reacción, refiere las actividades que el sistema realiza con la información.

Si el concepto función de negocio lo aplicamos a los objetos de negocio básicos estaremos hablando de aspectos de actualización de la memoria: insertar, modificar, borrar.

Si el concepto función de negocio lo aplicamos a los objetos de negocio derivados estaremos hablando de aspectos de recuperación y cálculo.

El concepto de regla de negocio, cuando se aplica a este ámbito, se refiere a una función de negocio o a una parte de una función de negocio en la que aparece una lógica compleja basada en combinaciones de condiciones.

.1.1.1.1 ObjetosObjetosObjetosObjetos de negocio de negocio de negocio de negocio básicos básicos básicos básicos

La descripción de la reacción del sistema se elabora a partir de las restricciones precedentes. La estructura de adquisición y la descripción narrativa permiten inferir el modelo de datos y las actividades de actualización o derivación expresadas con mayor precisión.

En el caso de sucesos asociados a comunicaciones de entrada procederemos al modelado de datos. Generaremos un modelo de datos asociado a la estructura de adquisición que caracteriza el mensaje. Solo los nuevos datos comunicados generan nuevas clases de objetos o entidades en el sistema. El uso de referencias nos permite conectar los atributos a nuevas clases con las clases ya existentes, definidas en sucesos previos.

Cada comunicación de entrada es responsable de “generar” una parte del modelo de datos del sistema.

.2.2.2.2 ObjetosObjetosObjetosObjetos de negocio de negocio de negocio de negocio derivados derivados derivados derivados

• Funciones de negocio Las funciones de negocio están definidas por cada una de las consultas u objetos derivados que los usuarios requieren. En unos casos las funciones de negocio podrán ser expresiones de derivación estructural, en otras funciones de cálculo sobre objetos del sistema. En general los objetos de negocio derivados deben analizarse siguiendo las pautas indicadas en el apartado de análisis de objetos derivados.


107

• Reglas de negocio El concepto de regla de negocio es ambiguo. Para la wikipedia las reglas de negocio tienen la siguiente definición:

Reglas de negocioReglas de negocioReglas de negocioReglas de negocio es la colección de políticas y restricciones de negocio de una organización.

Un ejemplo de reglas de negocio sería:

"Un cliente al que facturamos más de 10.000€ al año es un cliente de tipo A"

"A los clientes de tipo A les aplicamos un descuento del 10% en pedidos superiores a 3.000€"

Las organizaciones funcionan siguiendo múltiples reglas de negocio, explícitas o tácitas, que están embebidas en procesos, aplicaciones informáticas, documentos, etc. Pueden residir en la cabeza de algunas personas o en el código fuente de programas informáticos.

En los últimos años se viene observando una tendencia a gestionar de forma sistemática y centralizada las reglas de negocio, de forma que sea fácil y sencillo consultarlas, entenderlas, utilizarlas, cambiarlas, etc.

La definición es imprecisa. Pero las hay peores. Véase sino el manifiesto del BusinessRulesGroup de 2003.

Las reglas de negocio están asociadas a la actuación contingente o condicional. A cómo debe reaccionar o comportarse el sistema cuando se dan situaciones variables.

Para algunos autores las reglas de negocio pueden ser cualquiera de los requisitos considerados hasta ahora.

En los ejemplos que proporciona la wikipedia se presenta de forma incompleta una especialización de tratamientos.

Cuando decimos que a los clientes de tipo A les aplicamos un descuento X en los pedidos de importe Y establecemos una condición de tratamiento, de la reacción del sistema.

Pero lo importante, desde el punto de vista del análisis, no es cada regla sino el conjunto estructurado de reglas que definen de forma completa el tratamiento. La técnica a utilizar en este caso se conoce desde hace tiempo como tablas de decisión. Una tabla de decisión permite evaluar cual es el repertorio de condiciones que entran en juego para la aplicación de un determinado tratamiento.

En el ejemplo que propone la wikipedia se trata de una visión incompleta de lo que debe ser una regla de negocio. El analista debe detectar que como mínimo se establecen dos condiciones una el tipo de cliente (cliente de tipo A), otra el importe del pedido (si el importe es superior a 3000).

Por lo tanto se definirá una regla de negocio de especialización de tratamientos que podría denominarse “aplicación de descuentos”.

Esta regla se especificará mediante una tabla de decisión. En ella desarrollaremos cuatro cuadrantes: condiciones, valores de condiciones, acciones y valores de acciones.

108

Sección Identificación de condiciones: se detalla una condición por renglón. Se llaman condiciones a situaciones variables que pueden ocurrir (p.ej: tipo de cliente, monto de ventas, antigüedad, etc.).

Sección Identificación de acciones: depende de la complejidad de los tratamientos. Puede ser una única acción valorada (tipo de descuento a valor del descuento) o una lista de acciones potencialmente aplicables según cada combinación de valores de condición. Se llaman acciones a los distintos comportamientos que se asumirán en función de los valores que tomen las condiciones

Sección Valores de condiciones: se indican valores de las condiciones identificadas.

Sección Valores de acciones: se indican valores de las acciones identificadas.

Las tablas de decisión permiten un marco de trabajo para determinar especializaciones de tratamientos de forma exhaustiva y rigurosa. El analista comenzará por determinar las condiciones que pueden afectar a la diversidad de tratamientos. Para cada condición deberá establecer la enumeración de valores admisibles. Estos valores serán valores discretos (A,B,C) o condiciones que discretizan un rango continuo (de 0 a 1000, de 1001 a 10000, más de 10000).

• Tipos de reglas de negocio reactivas.

� 8�� '�� '��0�'�� %��%�� &��

�� ''�� @��%��&��'�� '�� '�%��'�'��$� ��

�� '�� C� �� %�(� 8�� '�� &��

��%�� (��

��1��'�� (�8��T��'��''�� %�(��

�� %�� '� ��%@��'�%��'�� (�La especificación y sobre todo el análisis de reglas de negocio de especialización de tratamientos conviene realizarla mediante un árbol o una tabla de decisión.


109

��,!� .�+�� '�� '�� '��0�'�� %��

� 8�� '�� '��0�'�� '�%��%�� &�� %��%��(�

�� '�� ;�� $� '�� %��#��'�%��'� ��$�

��''�� (��%��+�0'��

�� %�� ,(��[� �� +� �� '��

'�%��'��(� �� '�� +��'�%��%��'�� 1��

�� (� ��'�%��%��4�+��:�� ;��'�� &�+��'�'��:�$��

'�%��%��9'��'�� ;�� '�� 0�� (� 8��

��'�� '��0�'�� '�%��%��1��'�%��'�'��:��'��

1��'�� ;�:�$��1��'�%��%��%��'��''��

��%��1��'��'��1�� '�%��%�� (�Las reglas de negocio de especialización de comportamiento también pueden analizarse y describirse mediante tablas o árboles de decisión. Pero a diferencia de los tratamientos lo único que hacen es provocar cambios en variables de estado que serán utilizadas como condiciones de disparo en los sucesos relacionados.

Las reglas de negocio de comportamiento exigen la revisión del esquema de sucesos del proceso de negocio.

La sección de acciones en este caso no se trata de tratamientos sino de sucesos requeridos que reflejan el comportamiento esperado para cada combinación de condiciones.

.3.3.3.3 Sucesos vinculados Sucesos vinculados Sucesos vinculados Sucesos vinculados

Al obtener los requisitos de cada suceso procederemos al análisis de sucesos vinculados. Si alguna de las comunicaciones vinculadas al suceso requiere auditoría y control será necesario revisar el esquema de sucesos. El análisis de sucesos vinculados se describe en el capítulo anterior. Surge en el modelado del proceso de negocio cuando se establece el comportamiento. Al describir cada suceso el mayor conocimiento de los usuarios puede conducir a nuevos requisitos de sucesos informativos, acreditativos o de otro tipo.

Los sucesos vinculados se enumeran en forma de lista. Cada suceso será objeto de una especificación detallada.

110

6.3.5 RequisRequisRequisRequisitos comunicativos del ámbito de usoitos comunicativos del ámbito de usoitos comunicativos del ámbito de usoitos comunicativos del ámbito de uso

Existe información del ámbito de uso que no afecta a la esencia comunicativa de la necesidad de negocio. El analista debe saber separar los dos aspectos.

Como hemos visto un suceso informa al sistema de nuevos individuos que el sistema desconocía hasta ese instante o de individuos conocidos por el sistema. Cuando se informa de algún aspecto de objetos conocidos una cuestión esencial es que el usuario debe:

Identificar cada objeto del que va a informar. Describir los cambios producidos en determinadas características de cada objeto identificado.

La necesidad de negocio es indicar que se habrá de identificar un objeto de la clase “A” y que se introducirá una descripción para sus propiedades “a1,a2,a3”.

Pero en el ámbito de uso la forma de localizar un determinado objeto cobra gran importancia. Es posible, incluso que ofrezcamos al usuario varias maneras alternativas de identificar una instancia de una clase de objeto para que pueda informar de los cambios que ha sufrido.

6.3.6 RRRRequisitos comunicativos del ámbito del suceso.equisitos comunicativos del ámbito del suceso.equisitos comunicativos del ámbito del suceso.equisitos comunicativos del ámbito del suceso.

De la ocurrencia de un suceso surgen diferentes necesidades comunicativas:

Para la adquisición consideraremos tres grupos de requisitos. Los requisitos de composición o de estructura, los requisitos de derivación que no siempre aparecerán y los requisitos de condiciones y restricciones estructurales.

Para la reacción consideraremos los requisitos de clases que se derivan directamente de la estructura de adquisición y las funciones y reglas de negocio que definen la relación entre la estructura de adquisición y el modelo de datos.

Los requisitos asociados a un suceso no son solamente de información. Existen también requisitos operacionales, habitualmente incluidos en los conocidos como no funcionales, y requisitos de uso.

Los requisitos de uso pueden surgir en los sucesos. Pero su ámbito adecuado son los contextos editoriales que se presentarán en el siguiente capítulo. Un contexto editorial es una agrupación de sucesos que comparten una misma interfaz de usuario. Por ejemplo, en el caso de estudio de la agencia fotográfica todos los sucesos que afectan a la gestión de exclusivas (solicitud, asignación, finalización, cobro) se agruparían en un mismo contexto editorial de modo que reutilizarían las componentes de interfaz.

No obstante es posible que en un suceso aparezcan requisitos de aspecto o de soporte editorial (ayudas contextuales para la edición de ciertos campos. Reutilización editorial de datos históricos como “el pedido más frecuente de un usuario”, etc.).

La estructura de requisitos propuesta permite abordar la investigación definiendo un marco de procedimiento para la realización de entrevistas.

Una vez establecido el proceso de negocio y definida la secuencia temporal de sucesos comunicativos se procederá a especificar cada uno de los sucesos comunicativos.

Las entrevistas para capturar requisitos de sucesos partirán del esquema de sucesos y se guiarán por la definición de cada uno de los sucesos. Suceso a suceso se verificarán las diferentes facetas descriptivas de cada uno de ellos


111

6.4 ��

Una estructura de adquisición es una especificación de una estructura de datos para la descripción de un mensaje en la que cada elemento se asocia con la operación editorial que permitirá instanciar su valor.

6.4.1 Notación para la definición de estructuras de mensajesNotación para la definición de estructuras de mensajesNotación para la definición de estructuras de mensajesNotación para la definición de estructuras de mensajes

La notación BNF fue propuesta por Backus y Naur en el desarrollo del compilador de Algol 60 [Backus 1963].

En la propuesta inicial los constructores gramaticales fueron dos: la secuencia representada mediante contigüidad y la alternativa representada por la barra vertical de separación.

Los paréntesis angulares se utilizaban para delimitar símbolos no terminales.

Extensiones posteriores incorporarían las llaves {,} para repeticiones y los paréntesis rectos [,] para la opcionalidad. La cantidad de notaciones propuestas provocaría el artículo de Wirth “What can we do about the unnecessary diversity of notation for syntactic definitions” [Wirth 1977].

Una adaptación significativa de la notación BNF sería la utilizada para la descripción de estructuras de datos en el Análisis Estructurado de Sistemas [DeMarco 1979].

La notación que aquí se propone se basa en los tres constructores clásicos de secuencia, alternativa y repetición.

< + > Secuencia o composición

[ | ] Alternativa o especialización

{ } Iteración

La diferencia fundamental con la mayoría de notaciones propuestas estriba en el uso de paréntesis para la secuencia. Ni el análisis estructurado de sistemas ni las notaciones iniciales de BNF permiten la parentización de secuencias. Esta ausencia de parentización impide la descripción de estructuras dentro de estructuras. Por ejemplo:

Vehículo=Matrícula+Marca+Modelo+Motor=Cilindrada+Válvulas+Combustble+Color+Extras

Vehículo=Matrícula+Marca+Modelo+Motor=<Cilindrada+Válvulas+Combustible>+Color+Extras

La primera forma, la que permite el análisis estructurado de sistemas, es ambigua. La ausencia de parentización obliga a dividir las estructuras cada vez que queremos nominar una subestructura o grupos datos.

Vehículo=Matrícula+Marca+Modelo+Motor+Color+Extras

Motor=Cilindrada+Válvulas+Combustible

Esta peculiaridad impide una edición simple de estructuras complejas. De hecho las herramientas CASE de las técnicas estructuradas presentaban una interfaz para la definición de diccionarios de datos costosa y pesada. Para ver una estructura completa era necesario navegar por el árbol de subestructuras abriendo un formulario para cada una de ellas.

112

6.4.2 Operaciones de adquisición de datosOperaciones de adquisición de datosOperaciones de adquisición de datosOperaciones de adquisición de datos

Con la notación presentada la estructura del mensaje que nos informa de la existencia de una nueva persona puede definirse como:

Persona=

< código+

fecha_alta+ CIF+

nombre+

calle+

número+

escalera+

puerta+

C.P.+

población +

provincia >

Pero una estructura de adquisición de datos indica además el origen de los datos que constituyen el mensaje.

Podemos vincular una operación de adquisición de datos a cada elemento de una estructura. Esta idea fue propuesta en [Brodie 1984] para la técnica ACM/PCM. Utilizaremos las siguientes abstracciones básicas de operaciones de adquisición de datos:

i para los datos que el usuario introducirá o aportará al sistema de forma libre. Estos datos no son predecibles por el sistema. El sistema desconoce el instante exacto y el valor de los datos que un agente puede comunicar al sistema. El gerente de un videoclub no sabe en qué momento se pasará un socio del videoclub ni las películas que le pedirá.

e para los datos que el usuario aportará pero en un dominio que el sistema puede prever. Por lo tanto el usuario elegirá entre las opciones que el sistema le proponga. El socio del videoclub sólo podrá pedir películas en video o en dvd. Toda operación de elección supone la indicación de un conjunto asociado de valores. En el caso de tipos enumerados se puede utilizar el constructor de alternativas e [dvd|video]

d para los datos que puedan ser calculados o derivados de otros. El precio final a pagar por el cliente no es necesario introducirlo si es calculable a partir de los precios unitarios.

g para los datos que pueden ser generados por el propio sistema. Como es el caso de los códigos o de la fecha del día o de las constantes. No dependen de la voluntad de un agente externo y pueden ser generados en cualquier instante por agentes del sistema. Toda generación se asociará a una función g funcion() o a una constante g ‘iniciado’.

Añadiendo las operaciones de captura de datos podemos describir la estructura de adquisición de los mensajes que nos informan de la existencia de nuevas personas como:

Persona= < código+ G F1() fecha_alta+ G hoy() CIF+ I

nombre+ I calle+ I número+ I escalera+ I puerta+ I población + I C.P.+ I provincia > D F2 (C.P.)


113

Donde indicamos que en el suceso el código de persona se generará según una función específica, que la fecha se generará a partir de la función hoy(), que el resto de datos se introducirán por el usuario y que la provincia se derivará a partir del Código Postal (C.P.).

.1.1.1.1 CCCComposición de operacionesomposición de operacionesomposición de operacionesomposición de operaciones

Las operaciones de adquisición pueden componerse en diferentes formas.

Las operaciones de generación o derivación pueden ser una forma de establecer valores iniciales. Es posible que una operación de generación de lugar a datos editables por el usuario.

Por ejemplo la fecha de alta puede generarse a partir de la fecha actual y además puede ser editada por el usuario

Persona= < código+ g F1() fecha_alta+ g i hoy()

… >

La estructura de operaciones de adquisición puede expresarse con más rigor como < g hoy() + i >

.2.2.2.2 Expresiones de derivaciónExpresiones de derivaciónExpresiones de derivaciónExpresiones de derivación

En su forma más simple una expresión derivada refleja que un campo de un formulario es el resultado de una operación a partir de otros campos.

Sea, por ejemplo, el siguiente fragmento de estructura de adquisición que describe la introducción de un pedido:

< { LINEA DE PEDIDO= < Referencia= I Descripción+ Precio >+ Cantidad + I Total línea d Cantidad*Precio > }+ Total >

d � (Total línea)

En la expresión de derivación asociada a la componente Total Línea aparecen dos propiedades que por comodidad no hemos prefijado con el nombre de su estructura.

Total línea d Cantidad*Precio

De forma más rigurosa debiéramos haber escrito para referirnos a estas propiedades:

LINEA DE PEDIDO.Precio y LINEA DE PEDIDO.Cantidad

Sin embargo no necesitamos prefijar las propiedades puesto que no existe ambigüedad.

Igual ocurre con la segunda expresión.

Total d � (Total línea)

El sumatorio se refiere sin ambigüedad a una propiedad que pertenece a una iteración.

114

6.4.3 Derivación de estructurasDerivación de estructurasDerivación de estructurasDerivación de estructuras

.1.1.1.1 SelectoresSelectoresSelectoresSelectores

La estructura de datos asociada a la comunicación de un suceso, no sólo contiene referencias a los nuevos datos. También puede contener referencias a datos previamente conocidos por el sistema.

Supongamos que queremos representar la estructura de adquisición asociada a mensajes del tipo “Una persona cambia de domicilio”. Lo primero que tendremos que hacer es “recordar” los datos de la persona en cuestión. Para ello usaremos los paréntesis de selección. El uso de paréntesis de selección con una estructura indica una referencia al entorno de la memoria del sistema en vez de una referencia al entorno editorial.

Persona= D Persona(código I) < código+ < código+ fecha_alta+ fecha_alta+ CIF+ CIF+

nombre+ nombre+ calle+ calle+ I número+ número+ I escalera+ escalera+ I puerta+ puerta+ I población + población + I C.P.+ C.P.+ I provincia > provincia > D F2 (C.P.)

Esta forma supone una derivación estructural. Lo que se está expresando es que la información origen del mensaje que se va a construir se obtiene del propio sistema de información.

No derivamos un campo sino una instancia de la estructura completa de persona. Por simplicidad y dada la total similitud de propiedades podemos reducirlo a la forma siguiente.

Persona (código) (código) (código) (código) = I < fecha_alta + CIF+

nombre+ calle+ I número+ I escalera+ I puerta+ I población + I C.P.+ I provincia > D F2 (C.P.)

Mediante expresiones de derivación podemos obtener valores elementales, conjuntos de valores o conjuntos estructurados de valores.

Por ejemplo Cliente(provincia){<apellidos, nombre>} denota el conjunto de apellidos y nombre de los clientes de una determinada provincia.

.2.2.2.2 Relaciones Relaciones Relaciones Relaciones

Las estructuras mantienen entre ellas relaciones de contigüidad que se expresan de diferentes formas según el modelo de datos usado.

En el modelo relacional se utilizan los mecanismos de clave ajena. En el modelo ER se utilizan las relaciones. En los modelos de objetos se usan la asociación y la agregación.

En la notación propuesta dos estructuras tienen relación de contigüidad si una de ellas es componente de la otra.


115

Sea el ejemplo de la figura siguiente que muestra un fragmento de una cabecera de pedido. PEDIDO=

< num_pedido +

fecha_pedido+

CLIENTE=

< CIF+

nombre+

razón social+

provincia+

.....

En esta estructura pedido y cliente son estructuras relacionadas, de la misma forma que lo serán en los modelos de datos correspondientes. Toda relación de contigüidad requiere una definición de cardinalidad o multiplicidad. Sabemos que entre pedido y cliente existe una cardinalidad M-1.

Las siguientes expresiones derivadas son equivalentes. Denotan las fechas en que un determinado cliente ha realizado algún pedido.

Cliente(cif).Pedido{<fecha>}, Cliente(cif).{Pedido<fecha>}, Cliente(cif).{Pedido.fecha}, {Cliente(cif).Pedido<fecha>}, {Cliente(cif).Pedido.fecha}

Si bien hay varias maneras de expresar lo mismo, se recomienda usar siempre una forma estándar. Preferiblemente se optará por una de la dos últimas porque expresan mejor que el resultado es una iteración y, además, permiten el uso de operaciones poblacionales (equivalentes a las operaciones agregadas de SQL). Por ejemplo “la fecha del primer pedido que se hizo en una determinada provincia”:

Min{Cliente(provincia).Pedido.fecha_pedido}

En la estructura de pedido que se muestra, cliente y lineas no mantienen relación de contigüidad. Pero las dos son contiguas al pedido.

PEDIDO=

< num_pedido+

fecha_pedido+

CLIENTE=

< CIF+

nombre+

razón social+

calle+

número+

escalera+

puerta+

C.P.+

provincia >

LINEAS=

{ <referencia+

descripción+

cantidad

precio +

importe

> } LINEAS +

total

> PEDIDO

Por ello para obtener “la cantidad de artículos de la referencia 33 que solicitaron los clientes de Huelva en el mes de mayo” es necesario utilizar el hecho de que ambas mantienen relación de contigüidad con PEDIDO.

Sum{CLIENTE(provincia=’huelva’).PEDIDO(mes(fecha_pedido)=’mayo-05’).LINEAS(referencia=33)<cantidad>}

116

.3.3.3.3 Iteraciones derIteraciones derIteraciones derIteraciones derivadasivadasivadasivadas

En algunos casos es necesario usar conjuntos de iteración en la definición de estructuras de adquisición. Una iteración es un conjunto de instancias de una clase que se derivan del sistema.

Por ejemplo, supongamos que queremos indicar que una factura se realiza a partir de los datos que se almacenaron en el pedido correspondiente.

FACTURA= < num_factura+ g fecha factura+ g num_pedido+ e PEDIDO(estado=’por facturar’)<num_pedido> CLIENTE= d PEDIDO(num_pedido=:num_pedido).CLIENTE < CIF+

nombre+ razón social+ calle+ número+ escalera+ puerta+ C.P.+ provincia > +

LINEAS= d PEDIDO(num_pedido=:num_pedido).LINEAS = { <referencia+ {<referencia descripción+ descripción cantidad cantidad_pedida precio + precio_pedido>} importe d cantidad*precio > } LINEAS + total d 3 (cantidad*precio) > FACTURA

La estructura anterior expresa que el usuario elige un pedido que está por facturar y los datos de la factura se derivan de éste. Las elecciones de este tipo se describen con la expresión:

e CLASE (selección){<visualización>}<proyección>

El criterio de selección determina el dominio de instancias de la clase que se ofrecen para la elección, la parte de visualización indica los atributos de esas instancias que se presentarán al usuario y la proyección indica los campos que se derivan para la interfaz. En el momento de diseñar la interfaz, estas selecciones dan lugar a ayudas de campo.

Obsérvese que, en los selectores, se ha prefijado con dos puntos los parámetros que hacen referencia a campos de la interfaz; esto es especialmente útil en casos en que se puede dar ambigüedad.

Cuando se utilizan la expresiones de derivación para instanciar campos o estructuras es posible que exista una posterior edición de los valores instanciados. Añadimos una “columna de edición” para separar con nitidez la derivación de la posible edición del valor derivado.

FACTURA= < num_factura+ g fecha factura+ g num_pedido+ e e PEDIDO(estado=’por facturar’)<num_pedido> CLIENTE= d PEDIDO(num_pedido=:num_pedido).CLIENTE < CIF+

nombre+ razón social+ calle+ número+ escalera+ erta+


117

C.P.+ provincia > +

LINEAS= d PEDIDO(num_pedido=:num_pedido).LINEAS = { <referencia+ d {<referencia descripción+ d i descripción cantidad d cantidad_pedida precio + d precio_pedido>} importe d d cantidad*precio > } LINEAS + total d d 3 (cantidad*precio) > FACTURA

.4.4.4.4 Derivación de Iteraciones y agrupación. Derivación de Iteraciones y agrupación. Derivación de Iteraciones y agrupación. Derivación de Iteraciones y agrupación.

La agrupación es equivalente al uso de la cláusula GROUP BY en SQL.

Una agrupación es una operación que a partir de un conjunto de instancias devuelve otro conjunto de instancias mediante un cambio en la intención de identificación. El conjunto de las personas, por ejemplo, puede considerarse desde dos ópticas de identificación. Una sería la individual, la que podría interesar a efectos fiscales o legales, queremos conocer a cada individualidad del conjunto. El identificador (el CIF, por ejemplo) determina un individuo único y a todas sus propiedades.

Otra sería la poblacional, más frecuente en el ámbito social, donde no interesa identificar a cada individuo sino a poblaciones de ellos que presentan un conjunto de propiedades similares. Son estas propiedades similares las que definen una relación cociente en el conjunto de las personas. El identificador se convierte en un identificador de poblaciones y de las características comunes a los individuos que las forman.

Cualquier conjunto de individuos puede convertirse en un conjunto de poblaciones mediante una agregación, o agrupación, entorno a una o más propiedades.

Por ejemplo, sea el conjunto de las personas identificadas mediante el dni. Al agrupar este conjunto por provincia tenemos una representación de las personas de cada provincia. Las personas pierden su identificación individual y pasan a tener identificación poblacional. Podemos saber cuantas personas hay en cada provincia, cuantas personas tienen cada edad o cuántas personas hay en cada provincia con cada edad.

Una agrupación se define a partir de una clase básica, un criterio cociente y un criterio de proyección.

• La clase básica está caracterizada por sus atributos, sus identificadores y sus instancias. Por ejemplo la clase básica:

Personas{<dni+nombre+apellidos+ provincia+población+edad>}

Como la clase ya ha sido definida con anterioridad, no necesitamos presentar sus atributos en la expresión de derivación. Sí se indicará mediante selectores los posibles criterios de selección a aplicar sobre el conjunto de instancias de la clase base.

• El criterio cociente define el cambio en el punto de vista de identificación. Por ejemplo: <provincia+edad>.

Las propiedades del criterio cociente, o propiedades cocientes, pertenecen forzosamente al conjunto de propiedades de la clase básica. El resto de propiedades de la clase básica las denominaremos propiedades no cocientes.

La operación de agrupación la representamos mediante una barra inclinada (como la cocientación en Teoría de Conjuntos) y se parentiza con las llaves de iteración porque devuelve un conjunto de instancias:

{clase básica / criterio cociente}

118

• El criterio de proyección define las propiedades que nos interesa conocer de la agrupación; es la forma en que resumimos cada conjunto de instancias de las propiedades no cocientes.

Es obvio que a cada valor <provincia+edad> le corresponderá un conjunto de valores nombre, apellidos, población o dni. Es necesario elegir para cada una de estas propiedades la operación agregada que a partir de todas sus instancias nos devuelve un único valor. Tradicionalmente SQL utiliza las operaciones agregadas max, min, sum, avg o count.

En el ejemplo siguiente las líneas de factura se obtienen seleccionando todas las lineas de pedido del cliente para un determinado mes agrupándolas por referencia y precio.

Factura= < Numero factura+ G Fecha factura+ I Mes de facturación+ I CLIENTE(cif )= I < nombre+ domicilio+ población >+ LINEAS DE FACTURA= d { PEDIDO(CIF=cif y fecha_pedido.mes=Mes de facturación).LINEAS /

<referencia+precio> }= {<referencia+ {<referencia+ descripción+ descripción+ precio+ Precio+ cantidad facturada + suma(cantidad) >} importe > } d Precio* cantidad facturada > Factura

La expresión de agrupación no tiene en cuenta descripción. Desde el punto de vista conceptual sería necesario indicar que una referencia determina un único valor de descripción y se sobreentiende que por tanto la agrupación no afecta a la descripción. Pero si se piensa en el ámbito del diseño o de la construcción, en el lenguaje SQL, es necesario garantizar el valor único de la descripción. Podemos asumir una regla implícita estableciendo que, a los campos que no figuran en el criterio cociente pero sí en el criterio de proyección, se les aplica una función agregada por defecto.

.5.5.5.5 Iteraciones derivadas con multiselecciónIteraciones derivadas con multiselecciónIteraciones derivadas con multiselecciónIteraciones derivadas con multiselección

Otra funcionalidad de derivación editorial es la multiselección. La multiselección permite elegir, manualmente, un subconjunto de un conjunto derivado. La MMMMultiselección permite un MMMMarcado de los elementos de un conjunto de iteración que se requieren para una determinada función.

Por ejemplo, supongamos que queremos indicar que una factura se realiza a partir de los datos que se almacenaron en el pedido correspondiente.

Factura= < Nfac+ G Fecha_factura+ G según pedido+ e Pedido( ) CLIENTE= d Pedido(según pedido).CLIENTE < CIF+

nombre+ Razón social+ calle+ Número+ Escalera+ puerta+ C.P.+ Provincia >> +


119

LINEAS= M Pedido(según pedido).LINEAS = { <referencia+ {<referencia Descripción+ Descripción Cantidad Cantidad_pedida Precio + Precio_pedido>} Importe d Cantidad*Precio > } LINEAS + Total d 3 (Cantidad*Precio) > PEDIDO

En este caso el usuario elige las líneas que se incluirán en la factura a partir del conjunto derivado.


121

6.4.4 EspecializaciónEspecializaciónEspecializaciónEspecialización

El uso de estructuras de especialización en formularios indica la existencia de variedades estructurales excluyentes. Cada variedad estructural recoge diferentes campos que deberán ser cumplimentados según el caso.

Normalmente aparecen campos cuyo valor puede determinar el uso de una u otra variedad estructural. En este caso podemos hablar de indicadores de especialización. Un indicador de especialización es un campo de un formulario cuyos valores determinan el uso de una u otra variedad estructural. Por ejemplo, supongamos que un proyecto puede ser interno o externo. Tendríamos un campo del formulario Tipo de proyecto cuyos valores posibles serían [interno|externo]. En el caso de que fuera interno en el formulario se indicará el Departamento que lo realizará. En el caso de que sea externo en el formulario se indicará el CIF y la razón social de la empresa adjudicataria.

La persona que cumplimente el formulario deberá indicar la opción deseada y según la opción cumplimentará los campos adecuados.

En la estructura de adquisición el indicador de especialización se asocia a una operación de captura de elección.

< . . . + Tipo de proyecto+ e [interno|externo] REALIZACIÓN= [ INTERNA= Tipo de proyecto=’interno’ < Departamento > i | EXTERNA= Tipo de proyecto=’externo’ < cif+ i Razón Social > i ] >

Cada una de las variantes estructurales (INTERNA, EXTERNA) lleva asociada una condición que se vincula al indicador de especialización.

Es posible también que en un formulario aparezcan variantes estructurales sin que exista un indicador de especialización “nominal”. Por ejemplo supongamos que en función del valor de un campo es necesario cumplimentar de modo diferente el formulario.

< . . . + importe+ i [ Obra mayor= importe > 100 & importe < 200 <coeficiente de extrusión+ i tasas de consolidación>+ i | Obra doiro= importe >= 200 < plazo reposición+ i retorno de freseles > i ] + >

Obsérvese que se ha omitido el nombre de la estructura que contiene las diferentes variantes estructurales.

Las estructuras opcionales se tratan como variantes con una sola opción.

< . . . + importe+ i [ Obra mayor= importe > 100 <coeficiente de extrusión+ i tasas de consolidación>+ i ] + >

122

Las condiciones de especialización pueden afectar no solo a las estructuras sino también a los dominios asociados a cada campo.

“Cada comercial sólo podrá vender artículos asignados a su departamento”. En este caso el dominio en el que se pueden seleccionar artículos estará especializado según las asignaciones a departamentos existentes.

En este caso es conveniente asociar una función de especialización al dominio.

Requisitos de uso

123

7777---- SucesSucesSucesSucesos y estadoos y estadoos y estadoos y estado

7.1.1 Sucesos y ObjetosSucesos y ObjetosSucesos y ObjetosSucesos y Objetos

El mundo que nos rodea en la, aparentemente, constituido por una amalgama de fenómenos dinámicos y continuos. Lo expresaron los filósofos presocráticos. El mundo está en continuo cambio. Por contra las concepciones que elaboramos del mundo son estáticas y discontinuas. Sucesos y objetos son los dos mecanismos de categorización conceptual de nuestras percepciones que reflejan la discontinuidad y el estatismo. Concebimos como objetos aquellos fenómenos en los que no apreciamos cambios sustanciales. Concebimos como sucesos ciertas discontinuidades que suponen cambios en el estado de las cosas.

La categorización de conceptos está basada, según la mayoría de expertos, en los eventos. Parar Barsalou [Barsalou 1998] la categorización de conceptos se basa tanto en objetos como en eventos:

“…it is not surprising that the cognitive system categorizes on the basis of both individuals and events. If the cognitive system didn’t establish representations of individuals that exist across events, it couldn’t construct the history of an individual, it couldn’t represent the fact that the appearance of an individual might vary widely across occasions, it couldn’t count the number of repeating individuals observed across occasions, and it couldn’t determine the properties that occur most often across the individuals in a category.

In contrast, if the cognitive system didn’t record information about events, it couldn’t distinguish individuals that occur frequently in a category from individuals that occur rarely. Similarly, it couldn't distinguish the frequent properties of an individual from the infrequent ones. “

Tradicionalmente, en informática, se habla de estática y dinámica. Pero el término dinámica tiene un significado particular. Nuestras percepciones de fenómenos tienden a conceptos estáticos, los objetos o individuos, o a conceptos dinámicos discretos, los eventos. Un evento es la percepción

“Dynamic "things" must not be confused with

static descriptions of their results.”

Wolgfang Hesse

124

de una alteración en un fenómeno observado. No tenemos la capacidad de concebir una dinámica continua. Concebimos estados y cambios perceptibles. Toda nuestra cultura se llena de eventos simbólicos que rompen la continuidad. Fijamos arbitrariamente los principios de año o ciertas fechas señaladas que marcan de forma eventual el principio o fin de procesos dinámicos continuos o una frontera arbitraria en un cambio gradual. Todas nuestras formas de medida no son sino formas de discretizar, o cuantificar, fenómenos.

En esa discretización utilizamos propiedades que actúan como síntomas del proceso continuo. Aceptamos la temperatura y la humedad relativa como una descripción de un proceso climatológico altamente complejo. Basta una indicación de esas dos magnitudes para que nuestro cerebro presuma un escenario complejo tropical, desértico o polar.

La segunda de nuestras peculiaridades cognitivas es la necesidad de identificación. Probablemente fruto de la discretización, nuestra mente parece compelida a identificar cada uno de los objetos o de los eventos que percibe y clasifica.

Los fenómenos son complejos. En los fenómenos percibimos propiedades que agrupamos en forma de objetos. La composición de objetos y propiedades es una forma de ver o intuir los fenómenos.

En realidad consideramos un fenómeno como un entorno dinámico en el que somos capaces de percibir objetos relacionados. Percibimos que existen patrones de relaciones entre objetos que se repiten en el tiempo con ciertas analogías. Esa percepción es nuestra intuición de los fenómenos. No sabemos si existe un único fenómeno universal. Creemos que existen diferentes fenómenos que no se influyen o que están débilmente influidos.

Nuestra observación se limita a aislar aquellas características relacionadas que pensamos que describen un fenómeno. Nuestras limitaciones cognitivas se traducen en una fragmentación continua de fenómenos. En los fenómenos localizamos individuos, objetos.

Los fenómenos que percibimos no tienen una forma de identificación preestablecida. Seguro que existe un criterio de identificación para cocodrilos. Otra cosa es que quien observa y describe sea capaz de aplicarlo. Podemos identificar lo que somos capaces de distinguir. El observador de un sistema busca propiedades que diferencien los fenómenos o, si carece de criterios sólidos para ello les asigna un identificador sintáctico (un código). El observador de cocodrilos puede decidir describir los sucesos con cocodrilos mediante un nombre que asigna a cada uno. Suponemos que el suceso “Luis duerme en la orilla” y “Alberto se come una zarigüeya” se refieren a especímenes diferentes, pero en realidad no tenemos certeza. Supongamos que a los cocodrilos se le puede adosar un emisor con una frecuencia identificativa. Nuestra certeza depende de la tasa de error del dispositivo de identificación o de errores de interferencias. Parece más fiable que la identificación experta.

Que los humanos no dispongamos de criterios de identificación para los fenómenos no significa que sean iguales. La confusión es nuestra no de los fenómenos. Existen multitud de fenómenos para los que no tenemos identificación. No tenemos la capacidad de identificar átomos, y mucho menos partículas o subpartículas. No tenemos la capacidad de identificar masas. Tenemos serias dificultades para identificar colores. Cuando decimos “color rojo” no identificamos un fenómeno sino una clase de fenómenos. Sin embargo no somos capaces de tratar computacionalmente lo que no podemos identificar.

Los sucesos presentan dos aspectos identificación. Uno externo, cual es el identificador mediante el cual diferenciamos una ocurrencia del suceso de las demás. Otro interno, cual es la composición de identificadores que refiere el suceso.

Si las representaciones que hacemos de estado se basan en relaciones de objetos identificables, para que un suceso describa un cambio de estado necesita describir el estado que requiere y el que genera. Tanto uno como otro puede ser una composición de identificadores, es decir pueden ser estados compuestos.

Si los sucesos son lo que se comunica al sistema y no somos capaces de distinguirlos no podemos saber lo que ha ocurrido.

Requisitos de uso

125

El problema con la identificación es que, si es insuficiente, alcanzamos la confusión de fenómenos. Un ejemplo puede ser el de los sucesos de entrada y salida de existencias en almacén entra(producto, cantidad) sale(producto, cantidad) frente al cual la respuesta del sistema sea actualizar el stock del producto indicado. Es un suceso histérico, en el sentido freudiano de olvido. Es un suceso cuya ocurrencia no podrá ser identificada por el sistema. El problema es obviamente que el suceso no tiene un criterio de identificación ni puede tenerlo si no ampliamos sus propiedades. Podremos saber las existencias que nos quedan pero no podemos recordar cuánto ha entrado y cuánto ha salido.

7.1.2 Sucesos y Clases de SucesosSucesos y Clases de SucesosSucesos y Clases de SucesosSucesos y Clases de Sucesos

De igual manera que la perspectiva estática diferencia entre clase e instancia (entidades, objetos...) en la perspectiva dinámica también debemos hacerlo.

Lo que el analista describe son clases de sucesos. Cada clase de sucesos tiene asociada una población de instancias. Denominaremos ocurrencias a las posibles instancias de una clase de sucesos.

Por definición las ocurrencias de una clase de sucesos siempre pueden acaecer de forma concurrente. Por ejemplo “Un socio solicita darse de alta” denota una clase de sucesos cuyas instancias siempre pueden concebirse como concurrentes. Cualquier par de clientes pueden llegar al mismo tiempo y solicitar ser socios.

El aspecto opuesto es la serialización. Existen instancias de sucesos que deben ocurrir en un cierto orden y nunca de forma paralela.

Recuérdese una de las características de los sucesos: La ocurrencia de un suceso necesita conocer la ocurrencia previa de otros sucesos.

Para que pueda ocurrir un suceso de la clase “El socio solicita una cinta en préstamo” deben haber tenido lugar previamente dos ocurrencias de suceso. Una de la clase “Un socio solicita darse de alta” y otra de la clase “Recibir pedido de distribuidora”.

Los sucesos constructores generan estados particulares en el sistema. Cuando decimos que la ocurrencia de un suceso necesita conocer la ocurrencia previa de otros sucesos nos referimos a que todo suceso puede necesitar referirse a estados previamente generados por otras clases de sucesos.

Podemos por tanto vincular y ordenar clases de sucesos si sabemos que existen relaciones de precedencia temporal entre las instancias generadas por ellos. Cuando en un diagrama de sucesos relacionamos dos sucesos A y B estamos expresando que una instancia u ocurrencia de la clase B necesita la existencia previa de al menos una ocurrencia de la clase A.

7.1.3 Sucesos y estadosSucesos y estadosSucesos y estadosSucesos y estados

Todo suceso constructor es un generador o modificador de estados. La complejidad de un suceso depende de la complejidad del estado asociado. En principio el concepto más básico de estado estaría asociado al concepto de identificador, sea de una entidad, de un objeto o de una relación.

El menor estado que podemos generar aparece al incorporar un nuevo identificador al sistema con sus propiedades asociadas es una instancia de una clase simple. Por ejemplo un cif de un cliente junto con las propiedades que lo caractericen.

Pero siempre existirán sucesos que generen un estado complejo en el que aparecerán diferentes identificadores relacionados. Cada uno de ellos tendrá sus propiedades asociadas.

Un suceso “Tomar Pedido” incorpora una instancia de la clase “cabecera de pedido” (es decir un identificador de la clase cabecera de pedido junto con otras propiedades determinadas por él) y

126

varias instancias de la clase “línea de pedido” (es decir varios identificadores de la clase línea de pedido relacionados cada uno de ellos con el identificador de pedido y con las propiedades que los caracterizan).

Las relaciones temporales entre sucesos definen relaciones entre los estados generados por cada uno de ellos.

Sea el esquema de sucesos de la figura.

��,)� G��'��'��

El suceso “1 Alta Socio” genera instancias de la clase Socio. El Suceso “2 Alta Huertos” genera instancias de la clase “Huerto”.

Si los sucesos están relacionados también lo estarán los estados resultantes.

7.1.4 Relaciones dRelaciones dRelaciones dRelaciones de Cardinalidade Cardinalidade Cardinalidade Cardinalidad

Siguiendo con el ejemplo anterior podemos decir que la cardinalidad entre estos dos sucesos es 1-N.

Con ello estamos expresando que cualquier ocurrencia de alta socio podrá relacionarse con múltiples ocurrencias de la clase Alta huertos. Por el contrario toda ocurrencia de la clase Alta huertos sólo se relaciona con una sola ocurrencia de la clase Alta Socio.

��,,� G��'�� '�� '��

Obviamente el estado generado por el suceso 1 Alta socio tiene una relación 1-N con el estado generado por el suceso 2 Alta huertos.

��,-� �� '�%��%��

Requisitos de uso

127

Cuando tratamos con estados complejos las relaciones de cardinalidad pueden ser confusas. Es necesario comprender la estructura de identificadores para que la relación de cardinalidad sea significativa.

En la figura siguiente se muestra un patrón de secuencia de sucesos con cardinalidad 1-1,

��,�� *��'��1��$�'�� (�

En esta secuencia aparece un primer suceso 8 La Editorial solicita una exclusiva. Una vez se atiende la solicitud se busca un fotógrafo que pueda realizarla. Cuando se conoce qué fotógrafo quiere realizarla se le asigna mediante el suceso 9 Fotógrafo solicita asignación de exclusiva. Por último, cuando el fotógrafo ha realizado la exclusiva, la entrega en la agencia provocando el suceso 10 Fotógrafo finaliza exclusiva.

Cada ocurrencia de una clase sólo se relaciona con una ocurrencia de la siguiente. Una exclusiva sólo se asignará a un fotógrafo pero además una asignación se refiere a una única solicitud de exclusiva.

Este patrón es típico de las clases sucesivas. Toda la secuencia afecta a un mismo y único identificador de estado u objeto.

El primer suceso de la secuencia es un generador de estado (crea el identificador de exclusiva con sus propiedades asociadas). Los siguientes son modificadores esenciales de estado. Se limitan a añadir nuevas propiedades a un identificador existente. Desde el punto de vista del estado pueden tratarse como especializaciones.

7.1.5 Diagramas de sucesos y diagramas de estadosDiagramas de sucesos y diagramas de estadosDiagramas de sucesos y diagramas de estadosDiagramas de sucesos y diagramas de estados

Las relaciones que aparecen en los diagramas de comportamiento deben preservarse en los diagramas de estados desde dos puntos de vista: la cardinalidad y la temporalidad.

Los diagramas de estados (de entidades u objetos) siempre contienen de forma implícita información de temporalidad.

La información de temporalidad es información dinámica. Por ejemplo, en un diagrama ER una relación ya nos está diciendo implícitamente que para construir una instancia de relación es necesario construir primero las instancias de las entidades participantes.

128

��,>� G��'��3��%��%��5�� (�

Esta es una información dinámica en el sentido de requerir tres encapsulamientos dinámicos diferentes. El suceso que genera instancias de A, el que genera instancias de B y el que genera instancias de R.

Los diagramas ER utilizan el concepto de restricción de existencia (o de cardinalidad mínima) para anular esta información implícita.

Si manifestamos que la entidad B tiene una restricción de existencia respecto a la relación indicamos que no existe ninguna instancia de B que no esté vinculada a una instancia de R. Esta forma de expresarlo es sesgadamente estática.

��-�� G��'��3��%��%��'��9��5�'�� (�

Existe otra manera de expresarlo con sesgo dinámico. El diagrama anterior requiere dos sucesos constructores. Uno para generar instancias de A y otro para generar instancias de B relacionándolas con instancias de A.

Podemos considerar sobre un diagrama ER las clases de equivalencia inducidas por la relación “ser generado por el mismo suceso”. Para el ejemplo considerado obtendríamos diferentes encapsulamientos de sucesos:

��-�� '��$��

La preservación del orden implícito en el concepto de relación exige que el esquema de comportamiento refleje un orden parcial de sucesos de la forma siguiente:

��-�� *�%��%��3��1��5(�

Requisitos de uso

129

En el caso de existir restricciones de existencia la complementariedad sucesos/estados nos lleva a las siguientes relaciones:

��-�� '��$��

Nótese que la preservación de comportamiento exige que las ocurrencias del suceso A precedan temporalmente a las del Suceso R-B relacionadas.

En [Casamayor 1994] se propone una técnica para inferir transacciones a partir de estas clases de equivalencia inducidas por las restricciones de existencia.

Como se argumentó en el apartado de comportamiento, cada suceso debe presentar como interfaz de comportamiento a los demás sucesos las diferentes modalidades de estado que genera, lo que incluye las modalidades de especialización.

7.1.6 Especialización deEspecialización deEspecialización deEspecialización de comportamiento y estado. comportamiento y estado. comportamiento y estado. comportamiento y estado.

Las relaciones de especialización entre los estados del sistema se pueden deducir del comportamiento externo.

��-!� ��'��0�'�� '�%��%��$��

La detección de patrones de comportamiento con cardinalidad 1-1, presenta comportamiento de especialización sucesiva.

.1.1.1.1 Composición de identificadoresComposición de identificadoresComposición de identificadoresComposición de identificadores

El análisis de estado es, en definitiva, un análisis de identificadores. La diversidad de identificación surge de forma externa, a través de la cardinalidad de sucesos, o de forma interna estudiando las relaciones de composición de las estructuras comunicadas en cada acontecimiento.

En la figura siguiente el suceso 6 Editorial solicita reportaje genera un estado complejo compuesto por diferentes formas de identificación.

130

��-)� *�%��'�� &�'�'��

Requisitos de uso

131

8888---- Requisitos de usoRequisitos de usoRequisitos de usoRequisitos de uso

8.1 ��

Suponga que usted acude al servicio de correos para poner un telegrama. Lo primero que tiene que hacer es localizar dónde puede realizar esta gestión. Posiblemente deba usted además proveerse del formulario correspondiente.

Una vez haya localizado el entorno adecuado es posible que requiera usted ciertas informaciones previas que podrían afectar a la forma o al contenido de su mensaje. Por ejemplo la lista de precios. Imagínese que los precios van por bloques de palabras. Usted intentará maximizar el uso del bloque.

Comenzará un proceso editorial en el que usted participará como aportador de información escribiendo el mensaje en el formulario previsto para ello.

El proceso editorial continuará con la colaboración de alguna persona de correos que procederá a un cambio de formato introduciendo el texto que usted le proporcionó mediante un teclado en algún artefacto específico.

Esta persona realizará ciertas validaciones. Comprobará, por ejemplo, que la población a la que usted quiere enviar su mensaje existe o que el país al que usted pretende enviarlo dispone de servicio telegráfico.

Calculará el importe contando las palabras y aplicando la tarifa correspondiente. Registrará en algún soporte los datos que la organización de correos considere necesarios. Probablemente registre los datos del emisor, del receptor, el importe cobrado, la fecha y día de la operación.

Por último emitirá un recibo y una copia del mensaje enviado que le serán entregados para acreditar la operación.

La serie de actividades descritas en este ejemplo son habituales en cualquier interacción de un sistema de información; independientemente de los tipos soportes.

132

�� "� �� (�

Como vemos en el ejemplo anterior, la descripción de sucesos tiene dos ámbitos descriptivos: los requisitos del dominio del problema y los requisitos del entorno de uso.

Cuando nos movemos en el ámbito del problema la cuestión se centra en identificar las interacciones, los mensajes asociados y la reacción del sistema frente a esos mensajes.

Cuando trabajamos en el ámbito de la solución la cuestión se centra en ofrecer un soporte eficiente a la comunicación. Pero podemos observar que aparecen requisitos que en el domino del problema, en el modelo del negocio, ni se plantean. ¿Cómo encuentra un usuario de mi servicio la ventanilla adecuada? ¿Cuantos recursos son necesarios para cumplimentar un cuestionario? El entorno de uso incorpora aspectos pragmáticos que en el entorno del negocio resultan accesorios.

Una de las principales características del entorno de uso es facilitar la edición de los mensajes. Hasta tal punto que una interfaz puede considerarse un mero editor de estructuras. De hecho es lo que el usuario percibe. El usuario no desencadena sucesos sino más bien procesos editoriales que permiten construir mensajes que se comunican al sistema. La mayor parte del tiempo que un usuario pasa ante una interfaz la dedica a la edición. Por ello el concepto base de nuestra aproximación es el cocococontexto editorialntexto editorialntexto editorialntexto editorial.

Un contexto editorial identifica un editor de estructuras para uno o más sucesos de usuario. Cuando un contexto editorial se utiliza para varios sucesos de usuario es porque existe compatibilidad estructural entre ellos. El caso más típico de un contexto editorial es la agrupación de los sucesos de alta, consulta, modificación y borrado para una clase.

De forma general consideraremos que los requisitos del entorno de uso tienen que ver con los tres aspectos siguientes:

• �� /�� +��'��0��'�� '��'��1�'�� %��#��'�%��'��234�$��

Requisitos de uso

133

��1��'��56��'��0��'�� +#��'��&��'��23�'��0��'��7��(8(56(� �� '��0��'��9�� %�� %��#��$:��1�0�'�� :�'�%��'��%�(�

• �� /��1��0�� '��&��%�'��'�� &��'��''�� 2��'��6(��'��'��1�� '��1�� $:��:�� +��;�� &��'�� $� �� <� ��'��%�� $� �� '�%+�� %��%��#��(�

• �� /�� '��4��&��0� �� '�� '�%��'�'��&�'��1�� %��#��1�'�� ''�� %�(�

8.2 ��#��"�

8.2.1 Localización de clases de fuLocalización de clases de fuLocalización de clases de fuLocalización de clases de funciones.nciones.nciones.nciones.

La complejidad nos lleva a dividir y estructurar un sistema en partes relacionadas, con frecuencia de modo jerárquico. A través de las relaciones establecidas podremos localizar la parte que nos interese.

Desde hace tiempo se plantean dos formas básicas de organización de funciones en las interfaces de usuario. Se conocen bajo la designación de ‘objetos-acciones’ o ‘acciones-objetos’. En cada una de ellas se da prioridad a la localización por clases de funciones o por clases de objetos.

La primera actividad cuando pasamos del modelo de negocio al modelo de uso consiste en la definición de la arquitectura de invocación de sucesos de usuario. Esto se realiza mediante la navegación explícita o taxonómica. Esta navegación es la que permite crear la organización de clases de funciones según los criterios elegidos. Se basa en el uso de enlaces o invocaciones explícitas a diferentes contextos de una aplicación. Se denomina taxonómica porque la forma de enlazar define de forma explícita la taxonomía o modelo organizativo de los sucesos de usuario.

La navegación explícita o taxonómica está asociada a la localización del entorno de proceso de una determinada función o suceso.

La navegación explícita resuelve la localización de clases de sucesos. Una jerarquía de menús es una organización de funciones basada en navegación taxonómica.

En el caso de soportes nada o débilmente informatizados corresponde a la búsqueda que se debe realizar para encontrar el entorno de proceso adecuado; lo que puede suponer el hacer cola en la ventanilla de información o consultar la información de un directorio para encontrar la ubicación correcta.

Si la organización dispone de una web que permita esos trámites usted deberá navegar por la web hasta localizar el formulario correspondiente.

.1.1.1.1 Organizaciones de sucesos.Organizaciones de sucesos.Organizaciones de sucesos.Organizaciones de sucesos.

En la fase de captura de requisitos las composiciones temporales de sucesos resultan adecuadas porque facilitan la exhaustividad. Es más fácil para los usuarios ir narrando los pasos que siguen para completar un proceso de negocio que enumerar todas las funciones que realizan. E igual ocurre a la hora de validar. Es más fácil para los usuarios detectar que han olvidado una etapa en una secuencia de sucesos que detectar que en una lista de sucesos falta alguno.

134

En el entorno de uso los sucesos representados deben ser fácilmente localizados por los usuarios y para ello ya no se usan organizaciones temporales sino espaciales. En las formas espaciales los sucesos se pueden agrupar por diferentes criterios

• porque son realizados por un determinado departamento o persona • porque afectan a un tipo de objeto determinado • porque se usan para un proceso funcional dado • porque así lo decide el usuario El catálogo de sucesos que se ha ido obteniendo a partir de los sucesos de negocio debe ampliarse con los sucesos de mantenimiento que derivan del catálogo de requisitos de datos y del diagrama de clases de análisis.

.2.2.2.2 Reorganización de sucesos.Reorganización de sucesos.Reorganización de sucesos.Reorganización de sucesos.

Los sucesos catalogados durante el análisis del modelo de negocio deben agruparse en contextos según criterios de localización que convengan a los usuarios. La reorganización de sucesos preconfigura el contenido de los contextos editorialescontextos editorialescontextos editorialescontextos editoriales que se irá completando paulatinamente a lo largo del proceso.

Para la reorganización de sucesos el analista cuenta con abundante información del usuario. Una primera propuesta de organización del analista considerará la organización objetual y los sucesos vinculados que son las dos formas más frecuentes de contextualización.

Los requisitos de localización incorporan los siguientes aspectos:

• La relación de contextos: que contendrá cada uno de los contextos editoriales con la lista de los sucesos que comprende. Los contextos editoriales pueden describirse utilizando la notación propuesta en el capítulo I.1 . ��N*��9�� J� �

��K��%+�� '��9��L� �

��?��'��'��L� �

��%��'�� L� �

��N��'�� '��O�L� �

��M�O��*��9��

�� "��%� �� '��9�� (�

• El mapa de accesibilidad: que describe la organización y acceso a cada uno de los contextos. Habitualmente será un árbol como el utilizado para los mapas de un sitio web.

Requisitos de uso

135

�� #�%�� '�� '��9��(�

8.2.2 Localización de instancias de objetos Localización de instancias de objetos Localización de instancias de objetos Localización de instancias de objetos

La localización de instancias de objetos tiene que ver con facilitar al usuario el acceso a las instancias que debe tratar. Esto conduce a una suerte de navegación diferente a la taxonómica. La navegación estructural se basa en utilizar la estructura de la memoria del sistema para la localización de instancias de objetos.

La localización de instancias de objetos está relacionada con aquellos sucesos que suponen la modificación o borrado de objetos existentes. Por ejemplo el cambio de domicilio de un cliente. Pero también tiene que ver con funciones asociadas a la creación de objetos relacionados o dependientes de otros. Por ejemplo el alta de un pedido de un determinado cliente.

Desde el punto de vista de la interfaz la navegación estructural se materializa en estructuras de interfaz asociadas a clases del modelo de datos y a sus relaciones.

La localización de instancias está íntimamente asociada al soporte editorial.

8.3 ��

Un contexto editorial está formado por diferentes formularios que contienen funcionalidades de soporte editorial. Las funcionalidades de soporte editorial pueden adscribirse a actividades de localización, derivación, edición o a servicios asociados a cada una de ellas.

• Localización de instancias de objetos: Habitualmente un contexto editorial suele tener asociado un localizador de instancias de objetos. Este localizador se define mediante una estructura que el usuario puede navegar con los cursores o con disparos de funciones de recorrido. Los localizadores navegables están asociados a conjuntos de instancias de una clase derivada. Como conjuntos es posible

136

asociarle servicios de soporte a la localización: filtros, búsquedas, ordenación. Estos servicios pueden requerir el uso de formularios separados.

• Derivación estructural La derivación estructural permite iniciar la estructura de adquisición de un suceso. En los casos más complejos puede solucionarse en formularios separados. Sobre todo si las derivación estructural es asistida y necesita la intervención del usuario. Los formularios de derivación estructural son muy similares a los localizadores de instancias. Un localizador permite acceder a un objeto único. La derivación estructural permite componer estructuras de iteración compleja. Obviamente la composición requiere utilizar el acceso a cada objeto constituyente.

La derivación estructural puede requerir servicios de soporte similares a los de la localización.

• Edición La funcionalidad de edición es la más evidente de una interfaz. Las estructuras de adquisición permiten indicar características editoriales. Pero es posible que en el entorno de uso aparezcan funciones de soporte editorial que en el dominio del problema no surgieron. Por ejemplo una función que duplique lineas de pedido para facilitar la inserción de nuevas lineas similares a las existentes. Funcionalidad para iniciar determinados campos con el valor más frecuente. Funcionalidad para recordar el último valor introducido.

8.3.1 Compatibilidad editorial: Contextos editoriales.Compatibilidad editorial: Contextos editoriales.Compatibilidad editorial: Contextos editoriales.Compatibilidad editorial: Contextos editoriales.

En el diseño de la interfaz que soporte los sucesos de usuario es posible aplicar reutilización. Cuando sea posible, se resolverán dos o más sucesos de usuario en lo que llamamos un contexto editorial, de modo que se estará (re)utilizando un mismo conjunto de elementos de interfaz para soportar la edición de varios sucesos de usuario.

Dados dos sucesos de usuario, decimos que son editorialmente compatibles si sus estructuras de adquisición permiten la reusabilidad estructural; es decir, si la edición necesaria para construir los mensajes asociados a ambos sucesos (definidos en sus estructuras de adquisición) tiene las suficientes semejanzas como para poder ser soportada por la misma composición de estructuras de interfaz. Cuantas menos modificaciones sea necesario realizar en las estructuras de interfaz entre su uso para un suceso y su uso para el otro, mayor será la compatibilidad editorial de los sucesos.

Un contexto editorialcontexto editorialcontexto editorialcontexto editorial es un conjunto relacionado de estructuras de interfaz que dan soporte a un conjunto de sucesos de usuario editorialmente compatibles. Un contexto editorial debe ser capaz de presentar tantas variedades editoriales como funciones de usuario compatibles ofrezca.

Por ejemplo los sucesos de alta de un cliente, consulta de un cliente y modificación de un cliente tienen estructuras de adquisición semejantes y, por lo tanto, son editorialmente compatibles; es habitual la reutilización de las mismas componentes de interfaz para los tres sucesos. Diremos en tal caso que los estamos resolviendo en un mismo contexto editorial. Este contexto presentará al menos tres variedades editoriales, que darán lugar a diferentes modos de uso del contexto: el modo alta, el modo consulta y el modo modificación.

Cuando el proceso editorial asociado a un suceso de usuario es complejo, es habitual que se descomponga en objetivos editorialesobjetivos editorialesobjetivos editorialesobjetivos editoriales intermedios, asociados a sucesos de diseño. Los sucesos de diseño no deben confundirse con sucesos de usuario, surgen de un refinamiento de éstos para hacer más asequible la construcción del mensaje asociado.

Para describir un contexto editorial se especifican las siguientes propiedades.

1. Objetivos editoriales.

2. Sucesos de usuario de análisis a los que se da soporte editorial.

Requisitos de uso

137

3. Sucesos de usuario de diseño, los cuales surgen por necesidades editoriales (almacenar estados intermedios de la edición de un formulario) o por necesidades de funciones sobrevenidas de diseño (parametrizaciones de usuario, recuperaciones de históricos, etc.)

4. Sucesos de usuario accesibles. Los sucesos de usuario accesibles son aquéllos cuyo contexto de edición se especifica separadamente pero que el usuario requiere que se localicen asociados al contexto que se define. Estos sucesos pueden tener incluso estructuras de adquisición relacionadas con el contexto actual, pero por cualquier criterio la especificación y construcción se hace de forma separada (p.ej. los consultores vinculados). Desde los formularios que concreten el contexto actual, se podrá navegar a los que soporten los sucesos accesibles.

5. Funciones editoriales. Ya sean disparadas por un suceso de usuario de diseño, o bien disparadas internamente por la aplicación, son en realidad requisitos solicitados por los usuarios pero que se entienden como objetivos secundarios.

Requisitos de uso

139

9-Técnicas de obtención de información

141

9999---- Técnicas de obtención de informaciónTécnicas de obtención de informaciónTécnicas de obtención de informaciónTécnicas de obtención de información

9.1 ��

La palabra stakeholders ha remplazado al término users. Encontrar una traducción plausible para stakeholders no es tarea fácil. Utilizaré el término castellano actores para indicar todas aquellas personas que forman parte de un problema o tienen que ver con su solución.

9.2 ��"�

La principal fuente de información para el análisis de sistemas de información son los actores del sistema. Pero también tenemos otras fuentes de información como la documentación de la organización, la legislación u otros sistemas existentes con funcionalidad similar.

Los documentos organizacionales pueden ser de dos tipos.

Uno sería el constituido por los documentos básicos usados en la operación diaria como fichas de clientes, pedidos, albaranes etc. Estos documentos son útiles para el análisis de datos y en permiten también establecer un seguimiento de sucesos asociados.

Otro sería la documentación que la organización haya confeccionado sobre sí misma. Es posible que la organización disponga de manuales de procedimientos o que tenga una certificación de calidad. Estas fuentes son muy adecuadas para el análisis de procesos.

El problema de los documentos organizacionales es que pueden estar desfasados. Incluso los formatos de los formularios pueden ser inadecuados y el uso que se hace de ellos es más rico que el que muestra la estructura del formulario.

La mayoría de técnicas de obtención de información requiere la participación del usuario porque es el que finalmente mostrará o no su satisfacción con el sistema de información diseñado.

9.3 ��"�

La entrevista es un encuentro planificado entre usuarios y analistas para identificar fuentes de información u obtener requisitos.

9.3.1 Consideraciones generales sobre las entrevistasConsideraciones generales sobre las entrevistasConsideraciones generales sobre las entrevistasConsideraciones generales sobre las entrevistas

Los diferentes manuales que tratan el tema de las entrevistas consideran aspectos relativos al entrevistador y al entrevistado.

El entrevistador debe tener, según Silvia Royo “apariencia agradable, modales corteses, simpatía y facilidad de palabra. Agilidad y flexibilidad mental. Facilidad para entrar en contacto con la gente. Buenas dotes de observación y sentido del detalle. Buena memoria. Capacidad de síntesis.” La descripción es para entrevistadores de “cuestionario”. Es decir que llevan un guión de actuación y no es preciso que sean expertos en la materia sobre la que preguntan. Sin duda las características que apunta son deseables para un ingeniero de requisitos.

Como muchas recomendaciones de las entrevistas provienen de la práctica médica o del campo de la psicología el entrevistado aparece como débil ante el entrevistador. Probablemente responde a esa deformación profesional que lleva a la dualidad sano/enfermo. Esa actitud, que también aparece entre los informáticos pero con la dualidad ignorante/sabio, conduce a recomendaciones como las siguientes:

� Realizar la entrevista en “terreno del entrevistado”. “Acercarse al sujeto: recibirlo en casa”. Situar cómodamente al sujeto. Ponerse a cubierto de indiscreciones y testigos.

� Minimizar la toma de notas porque intimida al entrevistado.

� Evitar los silencios porque son intimidatorios.

� No se debe experimentar asombro ante ninguna respuesta.

La primera cuestión es que cualquier entrevistado puede tener dotes sociales, intelectuales y personales superiores al entrevistador. En muchos casos es posible que el que necesite tranquilidad y sosiego sea el entrevistador.

Algunos manuales anglosajones de análisis y consultoría también consideran el temor del entrevistado. Esto es posible si el entrevistado cree que el objetivo de las entrevistas es remplazar personas por artefactos y puede acabar en el paro.

Hacer las cosas en terreno del entrevistado no responde a la debilidad sino a lo práctico. Suele ser el que paga y no quiere desplazarse. SI la entrevista es con varias personas tiene menos costes para la empresa. Los analistas están más habituados. Y es la costumbre, lo que se suele hacer siempre.

Pero puede tener inconvenientes, por ejemplo las interrupciones o que el entrevistado no se abstraiga de lo que estaba haciendo o de los problemas pendientes por resolver. Nunca debe hacerse una entrevista en el despacho del entrevistado. Las interrupciones podrían afectar a la marcha de la entrevista. Siempre se debe buscar un espacio en el que se respete la actividad de los asistentes.


143

Si seguimos las recomendaciones de la PNL (programación neurolingüistica) deberíamos utilizar siempre la misma sala. O una sala en la que la gente esté habituada a hacer reuniones. Según la PNL las personas tenemos condicionantes, anclas, de modo que ciertos entornos predisponen nuestra actividad para la PNL un ancla es un “estímulo sensorial específico que evoca una experiencia determinada”. De la misma forma que un espacio de estudio bien iluminado y confortable en el que siempre estudiamos nos permite alcanzar la concentración con mayor rapidez una sala en buenas condiciones y en la que habitualmente se mantienen reuniones nos predispone a la actividad de comunicarnos.

La toma de notas puede intimidar cuando se hacen preguntas íntimas. Pero raramente cuando se pregunta por la actividad profesional. Mi experiencia es que a cualquier profesional se extrañará que un analista de requisitos no tome notas de lo que se le dice. En todas las reuniones de empresa se suelen generar actas.

Es cierto que los silencios pueden intimidar pero también depende del resto de señales que emitamos. Una sonrisa puede romper esa intimidación. El silencio también puede hacer que el entrevistado reflexione. Tampoco debemos tener prisa en hablar. Podríamos estar interrumpiendo al entrevistado o forzándolo a responder con más rapidez. Cuando un silencio se produzca preocúpese de mantener el contacto. No se sienta molesto o incomodado, posiblemente transmitirá esta sensación. Por el contrario, relájese y deje pasar unos segundos con una actitud atenta. Mire a su interlocutor de forma amable. Sin urgirlo. Pero esperando por si tuviera algo más que decir. Tenga siempre frases preparadas para cambiar de tema. “Si se le ocurren nuevas ideas puede enviarme un correo...”

Respecto al asombro, de nuevo, se trata de un problema de intimidad. Asombrarse no tiene porqué ser malo. Si alguien cuenta que hace el mismo trabajo cuatro veces, por ejemplo introducir un pedido, uno se puede asombrar sin perder el respeto por el entrevistado.

En resumen se trata más bien de ser natural y relajado en vez de desconfiado y suspicaz. Y sobre todo, se trata de que el entrevistado tenga la sensación de que a) sabemos lo que estamos haciendo, b) nos interesa su opinión y c) pretendemos ayudarle. Porque, en realidad, todo esto de las aplicaciones va de hacerle la vida más fácil a la gente. Si lo que queremos es simplemente salir del paso o no complicarnos la vida con los problemas de los demás es difícil que una entrevista para obtener requisitos funcione bien.

9.3.2 El proceso de la entrevistaEl proceso de la entrevistaEl proceso de la entrevistaEl proceso de la entrevista

Entrevistas y reuniones deben organizarse según las tres fases siguientes:

.1.1.1.1 PreparaciónPreparaciónPreparaciónPreparación: : : :

Los analistas deben preparar la entrevista con antelación. Para ello, si es necesario, buscarán documentación sobre los asuntos que se vayan a tratar. Identificarán las personas adecuadas de la organización para tales asuntos y acordarán un lugar y hora para celebrar la entrevista. Todo ello será comunicado, con tiempo suficiente para que puedan prepararse, a los usuarios. Si los participantes ya han sido informados por la dirección se enviará una nota, habitualmente un correo, en la que

Debe enviarse una nota escrita a todos los participantes que contendrá:

• Una descripción del motivo de la entrevistas

• La relación de participantes

• Objetivos

• Lista de los temas a tratar

• Fecha, hora y lugar de celebración

• Tiempo previsto

Todo analista debe tener una plantilla de convocatoria de reunión.

Al preparar la entrevista deberá tener en cuenta en qué ámbito de requisitos piensa trabajar. Para cada ámbito, excepto el inicial claro está, deberá llevar documentación de lo tratado o concluido en el nivel superior. Si va a tratar un proceso lleve información del área. Si va a tratar sucesos aporte la documentación del proceso. Si va a trabajar en requisitos de uso aporte la descripción de los sucesos involucrados y prototipos provisionales de pantallas.

.2.2.2.2 Realización: Realización: Realización: Realización:

1111 La La La La toma de contactotoma de contactotoma de contactotoma de contacto

En toda entrevista puede haber varios entrevistadores y varios entrevistados. Siempre habrá un coordinador, entre los entrevistadores, que será el que establezca los aspectos de toma de contacto y de procedimiento.

• Dará la bienvenida a los participantes y justificará la razón de su presencia en la organización. Indicará qué personas autorizan y se interesan en los asuntos que se tratarán.

• Procederá a la presentación de las personas. Si es un grupo pequeño el coordinador presentará a los entrevistadores y la razón por la que acuden a la reunión. Si el grupo fuera numeroso, más de seis personas, propondrá que cada uno se presente e indique su rol o interés en los temas que se van a tratar. En este caso deberá haber previsto cartulinas para hacer prismas con los nombres y roles de cada participante. Aunque siempre es posible improvisarlo con folios.

• Explicará qué se va a tratar y la forma de trabajo. Deberá controlar los tiempos y las transiciones entre temas. Si un tema no se finaliza en el tiempo previsto es preferible hacer una ronda de intervenciones en la que cada participante indique los temas pendientes. De este modo se prepara el guión de la siguiente entrevista.

• Repase la documentación aportada en la preparación. Asuma que algunos usuarios no habrán tenido tiempo ni de leerla. No dedique demasiado tiempo a ello. Simplemente ofrezca las pistas de donde deben mirar si lo necesitan

2222 Saber escuchar y preguntarSaber escuchar y preguntarSaber escuchar y preguntarSaber escuchar y preguntar

De forma general deben tenerse en cuenta las recomendaciones básicas de toda comunicación y las normas elementales de educación.

• Se deben dar muestras de escucha como asentir o reafirmar.

• La distribución de tiempos entrevistado-analista debe mantener una relación 80-20. Puesto que el objetivo es obtener información el analista no debe ocupar más de un 20% del tiempo.

• No discuta con los entrevistados. No pretenda demostrar que están equivocados. Aunque fuera un objetivo del proyecto no es el momento adecuado. Está ahí para obtener información.

• No se deja llevar por los prejuicios personales. El aspecto, las ideas o la cultura de la gente no tienen porqué ser los que usted desea. Debe intentar entender qué problemas tienen los participantes y qué información necesitan para resolverlos adecuadamente.

• No presuma que porque usen los mismos términos que otras organizaciones ya no hace falta que le cuenten más. Los términos carecen de valor en sí mismos. Los significados son lo importante y los significados dependen de las personas.

• No utilice jerga técnica. Esfuércese por aprender el léxico organizacional. Acercarse al lenguaje de los usuarios. Por ejemplo un término tan habitual como “interfaz de usuario” es muy confusa. Los usuarios hablan de “pantallas”.


145

• No tiene que hacerse amigo de nadie. No tienen que caer bien. No tiene que impresionar a nadie. En muchos casos los usuarios creen que están perdiendo el tiempo en una reunión de análisis porque tienen trabajo que hacer. Por lo menos debe conseguir: que crean que sabe preguntar y que crean que se interesa por sus problemas con el uso de la información.

3333 EEEEllll control de la entrevista control de la entrevista control de la entrevista control de la entrevista

El analista debe mantener en todo momento el control de la entrevista. En los temas y en los tiempos. El control de temas debe basarse en la propuesta realizada. Tenga en cuenta que si ha decidido trabajar sobre un ámbito determinado no debe profundizar en los superiores o inferiores. Encontrará aspectos de ellos pero céntrese en el ámbito y los elementos que identificó de ese ámbito. Imagínese que está haciendo una reunión para describir un suceso X. A medida que lo van describiendo aparecen otros sucesos que no había detectado hasta ahora. Tome nota de ellos y déjelos como requisitos pendientes de refinar. Informe a los participantes que se tratarán en otra reunión. En el mejor de los casos, si usted es de los que no tienen tiempo que perder, déjelos para el final de la reunión. Primero acabe lo que había planificado. No entre a refinar nuevos requisitos. Solo tome nota de ellos.

En algunos casos los usuarios tienden a presentar sus problemas recientes con la informática. Deberá saber cómo abordar y soslayar este tipo de intervenciones. Argumente siempre cual es el guión de la reunión pero sea comprensivo. Un usuario puede hacerle culpable de todos sus problemas informáticos. Si su sistema acaba de caer y ha perdido un par de horas de trabajo pensará que usted pertenece a la casta de las personas culpables de sus problemas. Atiéndale, déjele que se desahogue. Déle la razón de forma condicionada “desde luego si es como usted dice tiene toda la razón para estar indignado”. Tome nota del problema y emplácelo a solucionarlo en el marco de una reunión más adecuada.

Trate de identificar la motivación de cada participante. Observe si hay reticencias políticas. Si los cambios introducidos alteran la autoridad o responsabilidad de la persona. Intente adaptarse al modelo mental de cada usuario. Maneje como pueda a los usuarios que se muestran contrarios. “Esto es una tontería”. “Esto no sirve para nada”. “Ya lo han intentado tres veces y solo perdemos el tiempo”. En este caso debe contar con el apoyo de la dirección. Nunca debe imponerse. Pero debe mostrar firmeza en el trabajo.

Los participantes son los que saben del negocio. Usted sabe de requisitos. Ellos son los mejores en su trabajo y usted también en el suyo. Nadie de la reunión está más capacitado que usted para estructura el conocimiento. Si no, no lo habrían llamado.

4444 Finalización la entrevistaFinalización la entrevistaFinalización la entrevistaFinalización la entrevista

Agradezca a la gente su tiempo y su disposición. Comuníqueles que les enviará un resumen. Ofrézcales una forma de contactar con usted para cualquier aclaración que deseen hacer.

Si quedan temas pendientes intente acordar la próxima fecha de entrevista.

.3.3.3.3 SeguimientoSeguimientoSeguimientoSeguimiento

Tras la entrevista se hará un resumen lo antes posible, estructurando el conocimiento obtenido y esbozando los modelos obtenidos.

Usted deberá haber anotado cada requisito y quién lo aporta en lenguaje natural. EL acta recogerá todo lo que se expresó. Pero además a partir del acta elaborará un modelo estructurado de especificación. En muchos casos puede asociar los requisitos de usuario a la estructura que haga.

Se enviará un resumen a los entrevistados y se les solicitará la validación del mismo.

Las entrevistas constituyen una técnica flexible por su interactividad. Permite profundizar en los problemas que se consideren más relevantes y adaptarse al conocimiento de los usuarios. En general ofrece control de la situación permitiendo las repreguntas, cambios de temas etc.

El inconveniente es que son costosas en tiempo y recursos. Son difíciles de evaluar pero esa dificultad radica también en que la información que se obtiene es rica y compleja.

��!� ��'��


147

9.4 ��"�

9.4.1 Las entrevistas inicialesLas entrevistas inicialesLas entrevistas inicialesLas entrevistas iniciales

En la entrevista inicial aparecen las causas esenciales por las que se inicia el proyecto. Lo habitual es que se deba a la falta de información adecuada, a la poca eficacia, o a lo que cuesta obtenerla, a la poca eficiencia.

Pero como los humanos no siempre nos guiamos por la eficacia y la eficiencia pueden aparecer otras razones diferentes. Por ejemplo que ahora tengo dinero, que ha salido una ayuda, que tengo que consumir el presupuesto, que me hace ilusión, que todos tienen informática y un largo etcétera.

En la entrevista inicial debe conseguir:

• Conocer porqué sus clientes creen que tienen un problema, es decir los motivos de iniciar un

proyecto de análisis.

• Conocer quiénes son los responsables de definir el problema. Si se trata de las primeras

entrevistas todos los participantes deben de haber sido informados por la dirección de la

organización que estas reuniones se van a realizar y que la dirección desea que participen en

ellas. Las primeras reuniones deben ser convocadas por la dirección para evitar incidencias

con la coordinación de horarios.

Existen, por otra parte, diferentes grados y perspectivas de “inicial”.

Una perspectiva es la de las personas. Bajo esta perspectiva las entrevistas iniciales permiten la toma de contacto y el conocimiento preliminar de los actores que participarán en el proceso de análisis.

Otra perspectiva es la de proyecto. Iniciamos un nuevo proyecto del que deberemos obtener información.

Pero ambas perspectivas pueden darse con diferentes grados. Sobre todo en la perspectiva proyecto la gradación aparece vinculada a los ámbitos de los requisitos que se presentaron en el segundo capítulo.

Un proyecto puede abordarse desde el ámbito sistema, área o proceso. Una organización puede requerir tan solo la mejora de un determinado proceso con el que tienen problemas. O puede querer revisar el funcionamiento de todo su sistema de información.

Sea cual sea el ámbito aparecen aspectos comunes. Estos aspectos aparecen en lo que en diferentes métodos se denomina documento de inicio de proyecto.

.1.1.1.1 El documento de inicio de proyecto.El documento de inicio de proyecto.El documento de inicio de proyecto.El documento de inicio de proyecto.

El punto de partida en un desarrollo siempre es una descripción inicial del sistema de interés. Esta descripción se obtendrá de los responsables del sistema/área o proceso que se vaya a analizar. Bien porque existen especificaciones de procedimiento, bien porque se establezcan en una entrevista específica.

La descripción inicial servirá para identificar las fuentes de información esenciales para la captura de requisitos. Es conveniente definir una ficha de inicio de proyecto que contenga la descripción general del sistema, área o proceso a desarrollar.

La ficha deberá tener una estructura similar a las que se presentan a continuación.

��)� �#�%�� '�� $�'��


149

1111 MotivaciónMotivaciónMotivaciónMotivación.... Razones por las que se inicia el proyecto. Deberían incluir mejoras en los costes económicos, temporales. Puede tratarse en muchos casos de problemas de imagen o de posicionamiento en el mercado de servicios.

2222 ObjetivosObjetivosObjetivosObjetivos.... Define las intenciones esenciales del sistema a desarrollar. Los objetivos deben considerarse requisitos y se asociarán a indicadores que podrán adoptar dos formas. Indicadores objetivos obtenidos a partir de información del propio sistema (tiempos y recursos utilizados) o indicadores subjetivos y deberán asociarse con encuestas de satisfacción identificando además a los usuarios afectados.

3333 Exclusiones:Exclusiones:Exclusiones:Exclusiones: Cuando existan partes del sistema que no se desee analizar por razones de complejidad, economía o no exista necesidad.

4444 Subsistemas Principales: Subsistemas Principales: Subsistemas Principales: Subsistemas Principales: Si el proyecto es complejo pueden aparecer varios subsistemas, áreas de negocio o procesos de negocio. Los subsistemas principales deben entenderse como requisitos genéricos que posteriormente deberán refinarse.

5555 Fuentes de InformaciónFuentes de InformaciónFuentes de InformaciónFuentes de Información.... Personas o documentación relevante que nos proporcionarán información de cada subsistema. De cada persona deberemos anotar: Nombre, e-mail, teléfono de contacto, subsistema/área/proceso, responsabilidad.

Es conveniente conocer los intereses, motivaciones y responsabilidad de cada participante. Aparte de la información de contacto reseñada antes podríamos obtener información sobre los siguientes aspectos de cada participante:

• Rol: Participantes o Usuarios finales. Deberíamos saber en calidad de qué interviene cada

persona. Diferenciar si va a ser un usuario final o es experto o autoridad en el negocio. Por lo

tanto si la visión de requisitos que aportará es estratégica, directivas, operacional o de cliente

o proveedor. Y por lo tanto si su relación con el problema debe considerarse principal,

secundaria u ocasional.

• Grupo de usuarios. Es importante saber si cada participante es representativo de la

problemática de otras personas de la organización.

• Experiencia en el negocio [Básica|Avanzado|Experto]

• Experiencia tecnológica [Básica|Avanzado|Experto]

6666 Integración.Integración.Integración.Integración. Necesidades de integración con otros subsistemas o con sistemas externos (banca, gobierno...). La integración debe plantearse como un conjunto de requisitos de entrada salida con otros sistemas. Constituyen conjuntos de interacciones comunicativas.

7777 RestriccionesRestriccionesRestriccionesRestricciones • Técnicas

Lenguajes, plataformas u otros aspectos técnicos que deben ser utilizados en el proyecto.

• Económicas Presupuesto estimado.

• Legales Legislación aplicable al proyecto. Nivel de privacidad LOPD.

• Culturales Consideraciones culturales específicas según los mercados destino.

8888 Requisitos genéricosRequisitos genéricosRequisitos genéricosRequisitos genéricos • Idiomas

• Accesibilidad

• Portabilidad

• Confidencialidad y seguridad de accesos

9999 Requisitos del entorno operacionalRequisitos del entorno operacionalRequisitos del entorno operacionalRequisitos del entorno operacional Se trata de todas aquellas características y modos de funcionamiento que condicionarán la futura solución

• Disponibilidad. La disponibilidad determinará los requisitos de seguridad, respaldo y

contingencias de agentes soporte. La disponibilidad se puede dar en la forma “24/7” para

indicar 24 horas al día los siete días de la semana. Pero un aspecto importante es intentar

valorar el coste de cada hora que el sistema no está disponible. Estos aspectos determinan la

seguridad ante fallos.

• Distribución geográfica

• Entornos de operación especiales: luminosidad, polvo, temperatura.

• Usuarios previstos. Usuarios concurrentes • Crecimiento y evolución estimada del sistema.

��,� ��'�� '�%�� '�� $�'�� '��

10101010 Requisitos comunicativosRequisitos comunicativosRequisitos comunicativosRequisitos comunicativos Son requisitos de información de ámbito sistema. Siempre se trata de salidas. Es muy raro que a nivel sistema se planteen entradas.

• Consultores estratégicos: indicadores estratégicos, cuadro de mando....


151

• Requisitos propagables (deberían ser estándares)

o toda entrada o salida del sistema se trazará indicando el usuario, el instante y la terminal desde donde se trabaja

.2.2.2.2 Requisitos inRequisitos inRequisitos inRequisitos iniiiiciales del ámbito sistema: eciales del ámbito sistema: eciales del ámbito sistema: eciales del ámbito sistema: estándares.stándares.stándares.stándares.

• Requisitos que puedan afectar al desarrollo

Se trata, en la mayoría de los casos, de requisitos especificados en el ámbito sistema pero propagables a otros ámbitos más específicos. Son todos los patrones que pueden afectar a elementos específicos del desarrollo. Por ejemplo la forma de presentar los formularios. La manera de resolver el acceso a un conjunto de objetos. La disposición de los elementos de los menús o de los botones, la apariencia, color, zonas de mensajes de las pantallas, etc.

o Estándares de aspecto e imagen corporativa

o Estándares de uso de la interfaz:

� Patrones estructurales: de mantenimientos básicos, lista/detalle, maestro/detalle,

� Patrones de servicios: filtros, búsquedas, ordenaciones.

� Patrones de disparo

o Estándares de arquitectura y lenguajes

o Estándares de documentación

o Estándares de pruebas

o Estándares de programación

o Estándares de nominación de variables, campos, tablas de base de datos

• Requisitos de comunicaciones

Son requisitos de información de ámbito sistema. Se trata de requisitos propagables.

Por ejemplo la auditoría de entradas o salidas.

� De toda comunicación de entrada o salida del sistema se registrará indicando el usuario que la recibe o envía, el instante y la terminal desde donde se trabaja

� todas las comunicaciones a los administrados se efectuarán mediante certificado con acuse de recibo.

� Indicadores para el seguimiento de implantación: cómo se está usando la aplicación, quién la usa y quién no. Nos dice cómo debemos reforzar la formación a revisar los requisitos.

9.4.2 Las entrevistas deLas entrevistas deLas entrevistas deLas entrevistas del ámbito l ámbito l ámbito l ámbito procesoprocesoprocesoproceso

En el ámbito proceso el objetivo es determinar los objetos de negocio que lo caracterizan y las interacciones comunicativas de entrada o salida relacionadas con ellos.

Normalmente un proceso de negocio se describe en la forma acción objeto. Por ejemplo Gestión de pedidos, Gestión de reclamaciones, Gestión de facturas....

En la fase de proceso no debe profundizarse en la descripción de cada interacción. De hecho los participantes de obtención de requisitos de procesos no deberían ser los mismos que los del ámbito de sucesos.

Se está definiendo la política organizacional. La forma en que los diferentes departamentos cooperarán para la prestación de un servicio o la producción de bienes. Lo que requiere, en última instancia, la aprobación de la dirección.

Obtenga la información general del proceso en primer lugar. Recuerde los apartados característicos de un proceso.

• Nombre

• Motivos para el cambio

• Objetivos

• Fuentes de información Desde el punto de vista informativo son especialmente importantes los aspectos comunicativos:

• Objetos de negocio

• Comunicaciones externas

• Indicadores

• Diagrama de comportamiento

Una vez determinada la motivación para analizar el proceso compruebe que los objetivos del proceso están claros. Comience por intentar establecer relaciones entre los objetivos e indicadores de negocio. Si nadie es capaz de establecerlos puede ser por diferentes razones. No tienen costumbre de trabajar con indicadores o no están las personas que tienen una visión táctica del proceso. Compruebe que los usuarios que deberán supervisar el funcionamiento del proceso están presentes. SI lo están y no sale ningún indicador espere a que el proceso se haya definido operacionalmente es decir espere a haber finalizado el diagrama de comportamiento comunicativo.

A continuación obtenga información de los objetos de negocio. El primer aspecto a dilucidar es el tipo de objetos involucrados en el proceso.

Si los objetos son esencialmente derivados deberá trabajar a partir del objeto. Deberá conseguir que los participantes describan el objeto y los analistas irán definiendo la estructura. Es muy conveniente disponer de formularios de usuario para conducir las preguntas. El análisis de la composición del objeto permitirá llegar a los sucesos básicos necesarios para la “construcción” del objeto.

Si los usuarios describen actividades de gestión y procedimiento, si los objetos de negocio son esencialmente básicos se utilizarán las técnicas de análisis generativo.

Proceda según las recomendaciones del análisis generativo. Utilice la unidad reactiva como criterio. Recurra a formularios o a descripciones de proceso existentes. Busque siempre la forma en que se inician las cosas. Vaya siguiendo las diferentes actividades que conforman el proceso. Busque siempre la intervención externa de actores que aporten nueva información.

Una vez llegue a un primer bosquejo de comportamiento utilice las técnicas del apartado 5.7 Análisis del comportamiento comunicativo para revisar la bondad de la descripción. Fíjese especialmente en la existencia de reglas de negocio de comportamiento. Las reglas de negocio de comportamiento están asociadas a la auditoría de contenidos descrita en el apartado 5.7.3 Consultores de auditoría. A partir de ellos podemos detectar la necesidad de comportamiento añadido para supervisar la forma de operar. A veces la información de las reglas de negocio de comportamiento puede surgir al analizar los requisitos de un determinado sucesos como se define en el apartado 6.3.4 DESCRIPCIÓN DE LA REACCIÓN DEL SISTEMA.


153

9.4.3 Las entrevistas del ámbito interacciónLas entrevistas del ámbito interacciónLas entrevistas del ámbito interacciónLas entrevistas del ámbito interacción

Estas entrevistas se realizan con las personas directamente involucradas en la operación cotidiana. Son las que tienen un conocimiento más detallado de la información que se utiliza.

Para cada suceso deberá pensar un protocolo de preguntas según la lista de referencia que se aportó para el suceso.

1.1.1.1. DESCRIPCIÓN GENERALDESCRIPCIÓN GENERALDESCRIPCIÓN GENERALDESCRIPCIÓN GENERAL • Objetivos

Tenga en cuenta que está en el ámbito de las interacciones. Los objetivos serán comunicativos. Puede ocurrir que aparezcan objetivos sobre la comunicación de entrada (conocer las necesidades de un cliente) o de salidas vinculadas (informar a producción para que conozca los pedidos de clientes). No utilice la palabra objetivos. Recurar a las palabras para qué.

• Descripción

Confeccione una descripción física completa. Describa gráficamente todos los procedimientos físicos que acompañan al suceso lógico. Preocúpese de indicar las responsabilidades de los agentes involucrados en soportar el transporte o el envío de documentación. Si el origen de la información es remoto respecto al contacto describa le trasiego de información desde el inicio.

• Necesidades y problemas.

Deje esta pregunta para el final. Cuando tenga una visión más completa de la interacción.

Utilice un lenguaje positivo. No use nunca la palabra problemas. Pregunte siempre por las mejoras. ¿Creen que podría mejorar la forma en que lo hacen ahora?

2.2.2.2. DESCRIPCIÓN DEL CONTACTODESCRIPCIÓN DEL CONTACTODESCRIPCIÓN DEL CONTACTODESCRIPCIÓN DEL CONTACTO • Disponibilidad

� Restricciones temporales de disponibilidad, horario ... Pregunte por los horarios de disponibilidad. Categorice la disponibilidad. El tiempo que puede estar detenido o desatendida la comunicación.

� Actores secundarios Averigüe que personas son necesarias para dar soporte al proceso. Tenga en cuenta que en el caso de que se requiera alta disponibilidad los

� Canales Compruebe por qué canales diferentes puede llegar la información.

• Seguridad

� Autoridad Averigüe quién está autorizado para establecer esta comunicación. De quién se fía el sistema de información.

� Acreditación del emisor Averigüe si son necesarios protocolos de acreditación de personas.

� Acreditación de lo emitido Verificaciones sobre los datos aportados, ya sea mediante certificaciones documentales ya mediante inspección visual, diagnóstico, juicio, estimación....

• Verificación de elementos físicos asociados a la comunicación.

Compruebe si junto con la información aportada es necesario verificar algún aspecto físico. Por ejemplo contar los bultos que entrega un mensajero. Identificar el dvd que devuelve un socio de un videoclub. Verificar el funcionamiento de una tarjeta que se entrega a un cliente.

3.3.3.3. DESCRIPCIÓN DE LA COMUNICACIÓNDESCRIPCIÓN DE LA COMUNICACIÓNDESCRIPCIÓN DE LA COMUNICACIÓNDESCRIPCIÓN DE LA COMUNICACIÓN • Estructura del mensaje

Utilice siempre formularios para definir las estructuras. Formularios basados en papel o formularios de ordenador. Concrete siempre las cosas. Aunque documente mediante estructuras utilice imágenes más próximas al usuario. SI el usuario está acostumbrado a algún programa existente obtenga las “pantallas” que está acostumbrado a utilizar. Comprenda el modelo mental tecnológico que el usuario tiene.

• Restricciones comunicativas.

Es raro que los usuarios aporten restricciones. No entienden la palabra y tiene una carga peyorativa. Lo mejor es preguntar por condiciones. ¿Existe alguna condición para que se acepte un pedido?

• Requisitos de fiabilidad

Además de los contemplados en el apartado de contacto tendremos que ver si es necesario añadir nuevos sucesos para autorizar o validar las comunicaciones poco fiables.

• Requisitos de uso

� Formularios y documentos de usuario

� Requisitos de aspecto

� Requisitos de soporte editorial: Localizadores/Filtros 4.4.4.4. DESCRIPCIÓN DE LA REACCIÓN DEL SISTEMADESCRIPCIÓN DE LA REACCIÓN DEL SISTEMADESCRIPCIÓN DE LA REACCIÓN DEL SISTEMADESCRIPCIÓN DE LA REACCIÓN DEL SISTEMA

• Objetos de negocio básicos

El usuario suele opinar poco sobre las operaciones internas de almacenamiento. La estructura del mensaje determina la mayoría del modelo de datos y de la estructura de actualización.

• Objetos de negocio derivados

Será necesario un análisis de objetos derivados para documentarlos debidamente.

� Funciones de negocio

� �� '�� '��0�'�� %�� '�� '��0�'�� '�%��%��

• Sucesos vinculados

Pregunte por los consultores previos. Tenga en cuenta que la pregunta de consultores previos solo tiene pleno sentido para el actor primario, el que aporta la información. Por ejemplo al solicitar un préstamo el socio de una biblioteca es el actor primario. La persona que lo atiende y que probablemente manipulará el ordenador es el actor secundario. Erróneamente se suele preguntar a los usuarios que no siempre son los actores primarios.

¿Hay alguna información que cree conveniente para hacer esto? ¿Cree que su decisión podría mejorar si dispusiera de alguna información?

Pregunte por todas aquellas personas que necesariamente deberían conocer el nuevo hecho que se informa en la interacción analizada o alguna de loas conclusiones extraídas de él.


155

9.5 ��"�

En las entrevistas el analista debe estar atento a las expresiones de los usuarios. Debe utilizar la taxonomía de requisitos para identificar de forma rápida los requisitos que vayan apareciendo.

En primer lugar todo requisito debe identificarse en el ámbito correspondiente. Lo primero que deberá hacer es intentar asociar cada expresión a un suceso u objeto. Si la expresión es demasiado genérica entonces mire a ver si se trata de un proceso es decir de un conjunto de interacciones.

Pero sobre todo no permita que la falta de estructura de los usuarios influya en su criterio. Necesita identificar el ámbito y la característica para saber si debe recabar más información y cómo debe seguir preguntando.

Lo primero que debe hacer un ingeniero de requisitos es localizar el ámbito y la característica dentro del ámbito que identifica cada requisito.

��

�"��.�

$�'��'

'4%��'

�0��'

�'��0��'�

$��

�� '

�'��'

��"$�"'�

��"5�

��

��

2��/��

��

&� ��

0�

��

��

"��

',��*��

',��

��2��

4 ��

��

��

��,

��

��

&��

&��

$��

��

&��

&��

',�� "��

Un requisito puede ser genérico. Un área (comercial), un proceso (gestión de reclamaciones), un objeto (pedido), un suceso (pasar pedido a producción) o un consultor (listado de pedidos pendientes de cargar). O puede ser específico, una característica de cualquiera de los anteriores. Pero todo requisito siempre identifica un ámbito concreto. Por ejemplo

Suponga que ha obtenido la siguiente descripción de requisitos:

Tipo de financiación de los proveedores: los proveedores se pueden clasificar en dos tipos dependiendo si su pago es o no financiado.

• Proveedores financiados: Los proveedores financiados son aquellos a los que se paga sin tener que haber cobrado la mercancía una vez cumplido el plazo de pago que tiene asignado.

• Proveedores no financiados: Los proveedores no financiados son aquellos a los que se paga cuando la mercancía ha sido cobrada, excepto si se ha excedido el plazo de pago

correspondiente, momento en el cual se debe pagar la mercancía al proveedor por lo que se debe proceder a la liquidación aunque la mercancía aún no haya sido cobrada (pasa por tanto a ser financiado).

Esta descripción contiene varios requisitos. Comencemos por tipo de financiación ¿cual es su ámbito? Parece una propiedad de un objeto de negocio. Según la tabla de decisión para clasificación de propiedades consideraremos los dos aspectos de toda propiedad. Si es elemental identificaremos el objeto asociado que la identifica. Si es básica el suceso generador.

Identificamos la propiedad como adscrita al objeto Proveedores.

Ahora, para toda propiedad de objeto procederemos a su análisis generativo. Deberemos considerar si es básica o derivada. Si es básica localizaremos qué suceso la genera. Si es derivada buscaremos la definición de la función que la genera. Como vimos en el tema de objetos derivados la función puede ser estructural a partir de otros objetos o algorítmica mediante un procedimiento definido. Si la derivación requiere condiciones complejas podemos hablar de una regla de negocio y procederemos al estudio de las condiciones mediante tablas de decisión o árboles de decisión.

La pregunta a formular será por tanto: quién o qué define el tipo de financiación de un proveedor? A partir de la respuesta identificaremos el suceso generativo o la función que lo define.

Una vez identificada la propiedad Tipo Financiación y su génesis procederemos a considerar porqué es importante en el contexto. A falta de más información se deduce que se está tratando el pago a proveedores. Se trataría por tanto de formular las preguntas que nos permitieran relacionar esta característica con el suceso u objeto correspondiente. En principio parece que contribuiría a formar parte de alguna condición relacionada con el pago, es decir de alguna función o regla.

El control de la entrevista debe llevarlo el analista identificando los requisitos que se expresan y descartando los que no tengan que ver con el ámbito que se trata.

Por ejemplo, si se están definiendo procesos el analista buscará:

Características del proceso, descripción de objetos de negocio del proceso o identificación de sucesos y comunicaciones relacionadas con ellos.

Deberá escuchar los detalles que le den los usuarios pero reconducirá el tema al comportamiento y a la búsqueda de sucesos y comunicaciones externas.

Cuando trabaje en especificación de sucesos convocará las reuniones para abordar la descripción de cada suceso. Irá desgranando de forma sistemática, utilizando la ficha de sucesos, las características del suceso. Identificará la complejidad de la estructura comunicativa y considerará los aspectos básicos y derivados del suceso.


157

Las preguntas esenciales de todo suceso son siempre:

• qué me comunican y para qué me lo comunican

• a quién informo de lo que me comunican y para que quiere saberlo

Porque el ingeniero de requisitos siempre debe pensar en primer lugar en la información y en la utilidad que tienen para los usuarios.

Documents

AnÆlisis de Requisitos Comunicativos