INGENIERIA DE REQUISITOS

Germán Urrego Giraldo

 Necesidad y Objetivo
Problema y solución

La necesidad es un requisito imprescindible o irresistible en el ciclo de

vida de uno o varios agentes u objetos
La satisfacción de la necesidad implica la realización consciente o
inconsciente de objetivos de los agentes u objetos que experimentan o
no la necesidad
El problema plantea limitaciones, pretensiones, aspiraciones,
abstracciones, percepciones, interpretaciones dificultades, conflictos,
obstáculos y en general situaciones, eventos, desafíos que requieren ser
atendidos mediante soluciones que permitan avanzar en la satisfacción
de una necesidad, es decir en el logro de objetivos.
La solución de los problemas es una contribución a la satisfacción de
la necesidad, es un producto.
Las necesidades, los objetivos, los problemas, las soluciones
pueden expresarse en términos del conocimiento asociado a los
agentes y objetos implicados.
 Problema y solución
Identificación de Problemas
(- Limitación
- Aspiración
- Abstracción-Percepción-Interpretación
- Dificultad - Conflicto- obstáculo)
NECESIDAD (Requiere Conocimiento: Contexto
Social, Contexto Organizacional, Contexto de la
Solución, Dominio)
- Ser
- Tener Medios Métodos Dominio
Agentes - Saber- conocer/Investigación
- Comunicar-Compartir
- Objetos
- Hacer-Actuar - Situaciones
- Conceptualización -Técnica - Relaciones
- Diseño -Tecnología ( Es-un,
- Construcción - Ciencia Composición,
- Operación-Aporte Caracterización,
Verbo - Modificación Especificas del
- Substitución dominio)
- Acciones/Estados -
- Eliminación
- Circunstancias
Definición de Problema: Situación dentro de un
contexto específico, que demanda Intervenciones de
uno o varios agentes para actuar sobre dominios
determinados, con medios y métodos adecuados con el
fin de producir objetos y/o situaciones reales o
imaginarios.
 Identificación de los Problemas
• Conocimiento y Comprensión de las Realidades
• Delimitación y aprehensión del Conocimiento

• Representación del Conocimiento

• Tratamiento y aplicaciones del Conocimiento

El lenguaje ofrece recursos para la comunicación y

representación del conocimiento.
Los modelos verbales permiten la comprensión y descripción
del conocimiento de las realidades.
•Ejemplo de modelos verbales y “Esquemas Pre-conceptuales :
 Identificación de Problemas:
Diagrama Causa-Efecto (Diagrama de Isikawa)
OBJETIVO
NECESIDAD de una Empresa: Tener participación en el mercado
Existe ignorancia o duda Existe poca
sobre las características del competitividad del precio
Producto Se desconocen Hay deficiencias Hay efectos de las
atributos de calidad asociadas a los prácticas de la
Hay desconocimiento costos competencia
Se desconocen
EFECTO
respecto a tamaño, Hay limitaciones en las
presentación, características políticas de precios
empaque de su uso PROBLEMA:
CAUSA: Falta de
posicionamiento
Hay desconocimiento del producto en
Hay insuficiente Hay desconocimiento de los canales de
promoción del mercado objetivo distribución el mercado
Faltan estrategias de
Hay confusión o mala imagen de distribución
la marca o sus representantes SOLUCIÓN
Hay insuficiencia de
Hay dificultades para
Existe desconocimiento canales de distribución llegar a los canales
o mala reputación del Falta de canales de de distribución
producto en el mercado distribución
 Introducción a la Ingeniería de Requisitos

• Definición

Rama de la Ingeniería de software que se ocupa de (los fenómenos) las

metas del mundo real con el fin definir las funciones y las restricciones de
los sistemas de software. Considera las relaciones de los factores
pertinentes para precisar la especificación de la estructura, las
funcionalidades y comportamiento del software, así como su evolución en
el tiempo.

• La Ingeniería de Requisitos comprende el descubrimiento, la extracción, la

negociación, la validación, la operacionalización, la especificación, la
documentación y el seguimiento de la "huella" de los requisitos para la
construcción de sistemas.
 Marco de la Ingeniería de Requsitos
Definición del Análisis del Concepción del Realización del
sistema sistema sistema sistema

Operación-
lización
Definición
Conocimientos de los de
de
contextos social y
requisitos
organizacional requisitos

Definición de objetivos
de los contextos social y Elaboración Elaboración
organizacional. del modelo del esquema interno
Determina los agentes conceptual del sistema
interesados y las
fuentes de
conocimiento.
 Contextos y Agentes
Contexto social
Agentes
organizaciones personas
Contexto organizacional
Agentes
sistemas personas

Contexto del sistema

Agentes objetos
Definicion
Analisis del sistema
del sisteme
Definición Elaboración
Operationalizacion
de del modelo
de requisitos
requisitos conceptual
 Etapas de la Conceptualización de Sistemas

Conceptualización del Sistema

Definir el Sistema Analizar el Sistema

Definir los Requisitos Operacionalizar los Requisitos Elaborar el Modelo

Conceptual del Sistema
 BIBLIOGRAFIA
Brett McLaughlin, Gary Pollice, David West. 2006.
Head First Object-Oriented Analysis and Design. ISBN:978-0-596-00867-3. Ed. O’Reilly
Media.

Leffingwell, Dean. 2011

Agile software requirements : lean requirements practices for teams,
programs, and the enterprise. ISBN-13: 978-0-321-63584-6. Ed. Pearson Education, Inc.

Liping Liu and Borislav Roussev, (editors).2006

Management of the object-oriented development process. ISBN: 1-59140-606-4. Ed. Idea
Group Publishing.

Mc Conell Seven 1996

Rapid Development. Microsoft Press.

Bertrand Meyer.
Object Oriented Software Construction. Ed-Interactive Software Engineering Inc. (ISE)

Craig Larman. 2004

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and
Iterative Development (3rd Edition).. Prentice Hall, , 736p.

FOWLER, M. UML Distilled: A brief guide to the Standard Object Modeling Language.
Addison Wesley, Reading, 2004.
 BIBLIOGRAFIA

ROSEMBERG Doug, STEPHENS Matt. USE CASE DRIVEN OBJECT MODELLING WITH
UML THEORY AND PRACTICE. 2007

PRESSMAN, R. Ingeniería de Software, un enfoque práctico. Quinta edición. McGraw-Hill,

New York, 2002.

BARKER, R. Case Method Entity Relationship Modelling. Addison Wesley.1990.

SOMMERVILLE, I. Ingeniería de Software. Addison Wesley, Reading, Sexta Edición. 2000.

ARANGO, F. y ZAPATA, C. M. UN-Método para la elicitación de Requisitos de Software.

Carlos M. Zapata (Ed.), Medellín, 2007.

BOOCH G., JACOBSON I. y RUMBAUGH J. (2002), “El lenguaje de Modelado Unificado”.

Madrid. Addison Wesley Longman, 464 p.

Object Management Group OMG (2005), Unified Modeling Language: Superstructure

Version 2.0. En: http://www.omg.org/cgi-bin/apps/doc?formal/05-07-04.pdf. (Agosto 11 de
2006).

UML del OMG (Object Management Group) www.omg.org/technology/uml/ y

www.omg.org/technology/documents/formal.
 Ciclo de Vida del Desarrollo de Sistemas

Fase de conceptualización

Etapa de Definición

Modelos de Definición de sistemas

Conocimiento de la etapa de definición
Enfoque del aseguramiento de la calidad del software

Etapa de la concepción Arquitectónica Preliminar

Requisitos no-funcionales básicos
Elementos de la Infraestructura
Ubicación y entorno
Módulos estructurales (capas, nodos)

Etapa de Análisis

Documento de requisitos
Modelo conceptual
 Ciclo de Vida del Desarrollo de Sistemas

Fase de Diseño
Transición del modelo conceptual al modelo de diseño

Diseño de alto nivel

Arquitectura de control o Arquitectura del sistema de

Información o Arquitectura de Software

Conceptos de plataforma
Conceptos del Controlador
Conceptos de la Arquitectura
Integración de la arquitectura de software y de hardware
Enfoques de desarrollo de las arquitecturas

Diseño detallado

Implementación de clases y funciones

Desagregación de casos de uso (Escenarios)
Arquitectura de programa
 Ciclo de Vida del Desarrollo de Sistemas

Fase de Construcción
Concepto de plataforma, ambientes y herramientas de diseño
Clasificación de plataformas
Algunas plataformas existentes

Fase de Pruebas
Enfoques, Metodologías y Métodos de prueba
Estándares
Patrones y herramientas
Planes y casos de prueba
Proceso de prueba

Fase de Operación
Transferencia e implantación
Adaptación a la organización

Fase de Funcionamiento
Seguimiento
Adaptación al contexto externo
Mediciones
 Ciclo de Vida del Desarrollo de Sistemas

Fase de Mantenimiento
Proceso
Estrategias
Adaptación

Fase de Documentación
Necesidades
Enfoques de documentación
Aplicación al ciclo de vida del software

Fase de Terminación
Eliminación
Sustitución
 Ciclo de Vida Detallado de una Línea de
Productos, en Términos de Fases y sus Procesos
I-Fase de Preproducción
-Definición de Productos
Procesos:
-Identificación de Interacciones de Agentes Interesados
-Delimitación del Dominio y Tratamiento de Fuentes de
Conocimiento
-Construcción de Modelos de Características y de Modelos de
Variabilidad

-Análisis de Productos
Procesos:
-Análisis de Requisitos de los Productos
-Configuración de Componentes y Productos, Considerando la
Reutilización
-Identificación, Selección y Organización de Productos Correctos
 Ciclo de Vida Detallado de una Línea de
Productos, en Términos de Fases y sus Procesos
-Diseño de Componentes y Productos
Procesos:
-Verificación de Reusabilidad e Interoperabilidad de Componentes y de
la posibilidad de ensamblaje de Productos
-Instrumentación de Componentes y Productos
-Evaluación de las Capacidades y de las Posibilidades de Construcción de
Componentes y Productos

II-Fases de Producción
-Plan de Fabricación de Productos
Procesos:
-Verificación de la Utilidad y de las Posibilidades de Construcción de
Componentes y Productos
-Definición de Recursos y Estrategias y Métodos de Construcción para la
elaboración de Componentes y la Integración de Productos
-Planeación de la Integración y Validación de Componentes y Productos
 Ciclo de Vida Detallado de una Línea de
Productos, en Términos de Fases y sus Procesos
-Elaboración de Componentes y Productos
Procesos:
-Construcción de componentes
-Aseguramiento dela Compatibilidad e Interoperabilidad de
Componentes
-Construcción de Productos

-Pruebas y Afinación de Componentes y Productos

Procesos
-Definición del plan de pruebas de componentes y Productos
-Pruebas de Componentes y Productos
-Corrección y Ajuste de Componentes y Productos
 Ciclo de Vida Detallado de una Línea de
Productos, en Términos de Fases y sus Procesos
III-Fases de Posproducción
-Disposition of Products for Distribution
Processes:
-Documentación, Presentación y Acceso a Componentes y
Productos
-Definición de Canales de Distribución de Componentes y
Productos
-Adopción de Objetivos y Estrategias para la Distribución de
Componentes y Productos

-Distribución de Productos
Procesos:
-Promoción de componentes y Productos
-Comercialización de Componentes y Productos
-Entrega de Componentes y Productos
 Ciclo de Vida Detallado de una Línea de
Productos, en Términos de Fases y sus Procesos
-Servicios de Posdistribución Evaluación de Impactos
Procesos:
-Actualización de Ventas, Usos e Impactos de componentes y
Productos
-Evaluación de Usos, Reutilizaciones, e Impactos de Componentes
y Productos
-Provisión de Mantenimiento y Servicios Técnicos a Componentes
y Productos
 Estrategia de Trabajo por Proyectos

Concepto de Proyecto

Definición, cuantificación y organización

espacio-temporal de las actividades de los
actores implicados en el logro de un objetivo
mediante el uso racional de los recursos, bajo
determinadas circunstancias y restricciones
 PROYECTO DE DESARROLLO DE UN SISTEMA DE
INFORMACION

Objetivo:
Desarrollar un sistema de información contenido en el plan de desarrollo
de la empresa desarrolladora de Sistemas de Información y de
Conocimiento, considerando las metas organizacionales que los sistemas
deben apoyar.
Actividades:

1-Definición del Sistema. Considera los conocimientos de los contextos

social y organizacional en torno a a las necesidades manifiestas dentro de
estos contextos, las exigencias que se les planten en el presente y hacia el
futuro, los agentes implicados en estas exigencias, sus intenciones y sus
intervenciones en dichos contextos; la existencia de recursos científicos,
tecnológicos y técnicos; y las nuevas tendencias que afecten las
intervenciones de los agentes; las fuentes de conocimiento útil acerca de
los dominios de interés, así como las fuentes de conocimiento para
soportar las intervenciones de los agentes sobre estos dominios.
 PROYECTO DE DESARROLLO DE UN SISTEMA DE
INFORMACION
2-Etapa de la concepción Arquitectónica Preliminar
Requisitos no-funcionales básicos
Elementos de la Infraestructura
Ubicación y entorno
Módulos estructurales (capas, nodos)
3-Análisis del Sistema. Se ocupa de la adquisición y representación del
conocimiento asociado con el desarrollo del sistema

2.1-Definición de requisitos. Descubre las necesidades de los

agentes interesados en el desarrollo del sistema, elabora los
requisitos y produce el documento de requisitos.

2.2-Operacionalización de requisitos. Afina los requisitos y los

asigna a agentes autónomos
2.3-Elaboración del modelo conceptual. Representa las
funcionalidades y restricciones del sistema y los agentes
responsables de su realización.
4-Diseño arquitectónico (general)
 PROYECTO DE DESARROLLO DE UN SISTEMA DE
INFORMACION
5-Diseño detallado
6-Construcción de la solución (codificación)
7-Prueba de módulos

8-Prueba del sistema

9-Implantación de la solución

10-Evaluación y ajustes

11-Seguimiento y evaluación del desempeño

12-Asesoría y asistencia técnica

13-Documentación

14-Terminación
 Otras aplicaciones del concepto de proyecto

• Proyectos Integradores por áreas

• El curso de Ingeniería de Requisitos como proyecto

• El proyecto de Aprendizaje del estudiantes

• Proyectos de Investigación

• Proyectos de Ingeniería

• Proyectos de Desarrollo de Productos

 Diagrama de Gantt
Primera Fase Proyecto Gestión Riesgos
El link donde explican como construir el diagrama de Gantt es:
http://www.iusc.es/recursos/gesproy/textos/03.03.01.04.htm
 Metodología

Metodología
Conjunto de métodos aplicables en un dominio de la ciencia o de la
investigación

Método
Conjunto de procedimientos y de medios para llegar a un resultado.
Incluye el modelo del proceso y el modelo del producto

Método de Ingeniería de Software

Conjunto de procedimientos y de medios conceptuales y de software
utilizados para el desarrollo de un sistema de Información: modelos,
lenguajes, procesos (etapas, reglas, actividades ) y herramientas
(aplicaciones, recursos de hardware y de software)
 Metodología
Modelo
Representación simplificada de una realidad (de un sistema)
Los modelos ayudan a definir los productos mientras los lenguajes
ayudan a describir y especificar dichos productos

Proceso
Desarrollo temporal de fenómenos, cada uno de ellos indicando una
etapa
El proceso (etapas, reglas, actividades, recursos) comprende las
actividades recomendadas para obtener un producto de calidad

Esquema
representa el resultado del modelamiento

Ingeniería (Desarrollo) de un Sistema de Información

Conjunto de actividades (procesos) que realizan el ciclo de vida de un
Sistema de Información
 Paradigmas para el Desarrollo de Sistemas
Procesos de Desarrollo de Sistemas
de Información y de conocimiento

Modelos orientados Modelos orientados Modelos orientados

por la actividad por el Producto por la decision
(representa una
MODELOS MODELOS MAS •Modelos de Puntos de
intención)
INFORMALES FORMALES Vista •Modelos basados en
•Modelos de •Redes de Petri agentes
•Modelos de Transición
espiral •Reglas
de estados •Modelos basados en
•Lenguajes de
•Modelos de Prog. •Modelos de aspectos metas
cascada
•Modelos basados en •Modelos basados en
•Modelos de eventos escenarios
fuente
INTRODUCCION DE LOS CONCEPTOS DE
CONTEXTO Y DE DOMINIO
 Aspectos Centrales en la Ingeniería de Requisitos
La terminología usada en la Ingeniería de Requisitos debería fundarse en las
realidades del contexto para el cual se construye el sistema.
comprende:

- Objetos, agentes, roles, circunstancias

- Acciones, estados, eventos
- Perspectivas, vistas, aspectos, características

No es necesaria la descripción del sistema, lo esencial es la descripción del

contexto en el cual el sistema actúa

El contexto se describe en dos formas: sin el sistema y cómo sería a causa del
sistema

Es esencial determinar cuáles acciones del contexto son controladas por el

contexto, cuáles son controladas por el sistema y cuales acciones son
compartidas por el sistema y el contexto.

Si la modelación del contexto es en términos de estados es importante conocer

cuáles estados son del contexto, cuáles son del sistema y cuales implican el
sistema y el contexto.
 Requisitos
Modelos de apoyo a la educción de requisitos

Escenarios

tiene

Intervención
Casos de Uso de agente

tiene

Contexto de
Utilización de la
Solución Acciones Interacciones
Es un

Contexto
 Requisitos
Modelos de apoyo a la educción de requisitos
Producto
Es un
Problema: Es satisfecho por
Solución
Requisitos

define
tiene

Contexto de
Utilización de Intervención
Solución Casos de Uso
de agente
Es un
tiene
Es una Es una

Acción Interacción
Contexto Es una Escenarios
Es una Es una Unidad de
Se compone de
Actividad Proceso Procesos: Dominio
Servicio
 Solution CONTRIBUTION OF CONTEXT AND DOMAIN
Use Context Product
Model incorporates
Problem: Satisfied by
Requirements Solution
Agents Verb Object Means Méthod
belongs
defines
Circonstance have
requieres

Agent’s Atribute
Use Cases
Intervention
affects I- Descriptive
have
Context Is-An I- Causative
Action Interaction
Adquieres Sccenarios
Is-An Is-An
Meaning
and Worth
in Activity Unit of
Processes:
Applies Agents’ interventions of
treats
Process Service
Domain
 Fuentes de conocimiento

•Conocimientos del dominio

•Conocimientos obtenidos por razonamiento

•Conocimientos del contexto

•Contexto Social
•Contexto Organizacional
•Contexto del Sistema
 Fuentes del Conocimiento
Noción de contexto
La noción de contexto, proveniente de la lingüística, indica un espacio
donde un conocimiento adquiere significado y valor.
Tipos de contexto:
- Contexto de representación y de manipulación de
conocimiento (información).
Este concepto definido por la dupla (situación, decisión) es
utilizado para describir los pasos de desarrollo de un proceso.
- Contexto de intervención de agentes
Un contexto de intervención de agentes comprende un conjunto
de agentes, las intervenciones de éstos, las circunstancias que
determinan estas intervenciones, los medios y métodos
utilizados, los objetivos del contexto y las decisiones de los
agentes.
Una intervención de agente es una interacción con otros agentes o una
acción autónoma de dicho agente. Un agente es un objeto responsable de
una acción o de una interacción.
 modelo del contexto de utilización :
Estudio de caso (Servicios de electricidad)
Un modelo de contexto de utilización representa las acciones e interacciones
de agentes al servicio de las cuales se colocará el sistema.
Solicitud y envió de
información
Información y
términos del contrato Empresas de
comercio de
Consumidores o Venta y facuturación servicios de
usuarios electricidad

Pago

Sub-contratos

Provisión de
servicios de
electricidad Empresas
Generadoras
De servicios de
electricidad
Estudio de caso (Servicios de Turismo): modelo del contexto de
utilización

Usuario o Modo de Empresa virtual de distribución

pago
Solicitud de Cliente global de servicios de turismo
servicios

Reservación Información
(venta) Confirmación de
de disponibilidad
disponibilidad
Solicitud
Demanda de
de información
confirmación de
complementaria
disponibilidad
para los servicios Aporte de
Información
para servicios
Ofrecimiento de Búsqueda de Proveedores
alternativas para disponibilidad de servicios
los servicios

Agencias de Organizaciones Frontera del sistema

turismo Solicitud de pago
de servicios
Confirmación de pago financieros
 Fuentes de conocimiento

la ingeniería de sistemas, referida en [Reynaud, 1999], distingue entre

conocimientos del dominio y conocimientos obtenidos por razonamiento.
Estos conceptos contribuyen a precisar la relación entre los sistemas de
información y los sistemas de conocimiento.
Tendencias en la Ingeniería del dominio:
•métodos orientados a familias de aplicaciones o líneas de
producto (proviene de la comunidad de desarrollo de software).
Consideran el dominio como una familia de aplicaciones de la misma
naturaleza.

•métodos orientados a problemas (proviene de la inteligencia

artificial).
Para estos, el dominio es una clase de problemas para la cual existen
múltiples soluciones.
 Fuentes del Conocimiento
Noción de dominio
Con relación a los sistemas informáticos el dominio es considerado
como un campo de actividad.

Un conjunto de objetos y relaciones sobre los cuales intervienen unos

agentes (entre ellos los sistemas) para cumplir sus objetivos.

El espacio en el cual el sistema interviene, el ámbito en el cual

existen y se relacionan los objetos que los sistemas de información
manejan para soportar las actividades de este dominio.

Los objetos del dominio y sus relaciones son los portadores del
conocimiento que utilizan los sistemas que trabajan sobre ese
dominio.

Los sistemas utilizan los conocimientos de su dominio

 Fuentes del Conocimiento
Noción de dominio
Enfoques del concepto de dominio:
la ingeniera de sistemas de información orientados hacia la
reutilización, diferencia dos tipos de conocimiento:
conocimientos de dominio y conocimientos de ingeniería.

Los conocimientos de dominio son definidos como aquellos

conocimientos manejados por los expertos de un dominio y que
son compartidos por todas las aplicaciones de dicho dominio.

Los conocimientos de ingeniería se refieren al saber-hacer de

los desarrolladores de los sistemas de información quienes
toman problemas recurrentes dentro de la ingeniería para los
cuales utilizan a menudo los mismos métodos de solución.
Los conocimientos de ingeniería son realmente conocimientos
de un contexto particular, el contexto de realización del
sistema.
 Estudio de Caso: Estructura de Servicios y
Objetos del Dominio (ESOD)
Servicio de Electricidad

Información Distribución Pago Venta Contratación Subcontratación (con Post-venta

General empresas
generadoras)
cuenta facturación

Investigación disponibilidad elaboración de anulación de

de servicios de servicio contratos contratos

Proveedor parámetros del contrato

tarifa cantidad duración Fecha de inicio

Convenciones: : tipo de : composición : caracterización

 Niveles de abstracción por contexto
Meta
representado por 1

Meta Meta Meta Meta

convolutiva progresiva estacionaria instantánea
formula formula formula formula

servicio proceso actividad

Según nivel de abstracción

interacción acción
1

categorías de
intervención 1 1
nivel 1 1
la ontología
de agentes pertenece à
de abstracción caracterizado de verbos
par
 Diagrama de Casos de Uso: notación
UML

Lectura: todo actor Estudiante puede interactuar con el sistema para

Matricular Cursos, Cancelar Cursos y Cancelar Semestre.
 Definición
• “ Un caso de uso es una descripción de un conjunto
de secuencias de acciones, incluyendo variantes,
que ejecuta un sistema para producir un resultado
observable de valor para un actor.“ (Booch et al.,
2002)

• Secuencia de pasos o procesos realizados por un

actor ayudados por una aplicación informática para
garantizar la realización de una tarea dentro del
sistema
 Casos de uso
• Un caso de uso es un proceso que presenta la
interacción de un Actor, bajo un rol específico, con
el sistema informático.
• Actor: entidad externa al sistema informático que
participa en el proceso descrito en el caso de uso.
No se trata necesariamente de un ser humano.
– Aplicación informática que se comunica con nuestro
sistema.
MODELOS DE LA FASE DE DEFINICIÓN DEL
SISTEMA

-Modelo de Objetivos de los Contextos

-Modelo de Conceptos Preliminares:
(Modelo Verbal y Esquema Pre-conceptual)
-Modelo de Causa-Efecto
-Modelos de la Organización
MODELOS DE LA FASE DE DEFINICIÓN DEL
SISTEMA

-Modelo de Objetivos de los Contextos

 Definición del Sistema

Definir el Sistema

Recolectar Conocimientos Definir Objetivos Utilizar un Patrón de

Adecuación a otro
Contexto

Encontrar Objetivos Existentes Formular Objetivos

 Sistema de Planeación: Objetivos de contexto
Extracto de conocimientos del contexto: … ”Las metodologías de planeación
y sus herramientas de soporte no incorporan los nuevos desarrollos en las
tecnologías electrónicas y de manejo de la información y en general no son
adecuadas para ayudar las organizaciones de los diferentes sectores de la
economía en la definición de las estrategias organizacionales y en su
articulación con los cambios en un mundo globalizados “
Objetivo del contexto social:

[Los promotores del desarrollo empresarial ]Agente Principal recomiendan [el

desarrollo de soluciones de apoyo a la planeación ]Objeto [desde la adopción
de una estrategia ] Situación 1 [hasta la materialización de la solución] Situación 2

[utilizando tecnologías de la información y de la computación ] Medio

[aplicando métodos que permitan manejar las condiciones externas y

optimizar el uso de sus recursos ] Método [para las organizaciones de todos los
sectores de la economía ]Agente Interactuante
 Sistema de Planeación: Objetivos de contexto

Objetivo del contexto Organizacional:

[La organización de Investigación, Consultoría y Servicios ]Agente Principal emprende [el

desarrollo de sistemas de apoyo a la planeación ]Objeto [desde la elaboración del plan]

Situación 1 [hasta el aseguramiento de sus logros] Situación 2 [utilizando tecnologías

avanzadas de la ingeniería de Software ]Medio [aplicando métodos que contribuyan a
generación de sistemas de calidad ] Método [para las organizaciones de todos los sectores
de la economía ] Agente Interactuante.
 Sistema de Planeación: Objetivos de contexto

Objetivo del Contexto del Sistema

[El sistema de apoyo a la planeación ]Agente Principal soporta [la elaboración y ejecución
del plan de desarrollo ]Objeto [desde la convocación de los agentes interesados] Situación 1
[la evaluación y reformulación del plan] Situación 2 [utilizando plataformas de hardware y
software ]Medio [aplicando métodos avanzados de gestión de la infamación, de las
comunicaciones y de la gestión organizacional ] Método [para las dependencias de
organizaciones de todos los sectores de la economía ] Agente Interactuante.
 Descripción del procedimiento seguido por el Patrón de
ajuste de objetivos de un contexto en objetivos del contexto
inferior siguiente
El agente principal del objetivo ajustado en un contexto es un agente decisor
de este contexto, esto es un agente perteneciente al contexto precedente.

El parámetro objeto es un aspecto, sub-aspecto, o atributo del parámetro

objeto del objetivo del contexto precedente, considerando las intenciones de los
agentes y en una perspectiva determinada por el propósito del sistema que se
desea construir.

Los parámetros situación 1 y situación 2 se establecen en correspondencia

con las situaciones 1, y 2 del objeto considerado en el objetivo del contexto
precedente.

El medio y el método son componentes contenidas en los correspondientes

parámetros, medio y método, del objetivo del contexto precedente.

El agente interactuante lo constituyen agentes de los dos contextos

implicados, considerando las interacciones expresadas en el Modelo de
Contexto de Utilización de la Solución (MCUS) que consideren apropiadas el
ingeniero de aplicaciones y otros agentes implicados en las decisiones.
MODELOS DE LA FASE DE DEFINICIÓN
DEL SISTEMA

-Modelo de Conceptos Preliminares:

Modelo Verbal y Esquema Pre-conceptual
 Esquema Pre-conceptual
• Es un esquema conceptual preliminar del contexto y del
dominio

• Es una representación intermedia entre las

especificaciones textuales en lenguaje natural (“modelos
verbales”) y los diferentes esquemas conceptuales que
permiten el modelamiento de una pieza de software
[ZAPATA et al., 2006].

• Es un primer intento para modelar el dominio y el

contexto del problema. Permite identificar los agentes
interesados y el conocimiento implicado en sus
relaciones.

• Es un artefacto de la fase de definición del sistema. Se

complementa con modelos de causa-efecto, y modelos
de objetivos
 Esquema Pre-conceptual
•Ayuda a entender el problema

•Sirve para validar con los interesados (Cliente,

usuario, etc.) el conocimiento de la fase de
definición del sistema
 Esquema Pre-conceptual
•Símbolos Utilizados
 Esquema Pre-conceptual

Símbolos Utilizados: Concepto

• Un Concepto es un sustantivo o frase nominal del

discurso del interesado.

• Cada concepto se menciona sólo una vez en el

esquema preconceptual. Cuando sea necesario
mencionarlo más de una vez, para asegurar la
claridad se utilizan conectores. Para estos se usa
un pequeño círculo con un número en su interior.

• Ejemplo de conceptos : Estudiante, cursos,

programa, “Número de créditos cursados”, etc.
 Esquema Pre-conceptual
Símbolos Utilizados: Relaciones
• Son de dos tipos: Dinámicas y
Estructurales
• Sólo admiten verbos
Estructurales: Ser y Tener. Relaciones
como “incluye”, “pertenece a”, se deben
llevar a “Ser” o “Tener”.
Dinámicas: verbos que reflejen
actividad. Ej: registra, realiza, prepara,
etc.
 Esquema Pre-conceptual

• Símbolos Utilizados: Condicional

• Puede incluir expresiones que contengan
operadores lógicos y conceptos.
• En general, se refieren a restricciones o
reglas del negocio que se deben cumplir
tomando como base los conceptos del
mundo real.
• Ej:”Salario>0”, “Nro-Cuotas > 30”,
“Jornada: 6am-2pm”
 Esquema Pre-conceptual

Símbolos Utilizados: Implicación

• Unen pares de relaciones dinámicas para

representar conexiones entre relaciones.
En este sentido, convierten las relaciones
dinámicas en precondiciones de una
determinada relación dinámica.

• Unen condicionales con relaciones

dinámicas, también para expresar
precondiciones.
 Esquema Pre-conceptual

Símbolos Utilizados: Conexión

• Unir conceptos con relaciones, con el

fin de que la acción denotada por la
relación sea ejecutada por el concepto.

• Unir relaciones con conceptos, para que

la acción expresada por la relación se
transfiera a un concepto.
 Esquema Pre-conceptual

concepto1 relación concepto2

concepto1 relación concepto2

sí
condición relación

no

relación
Esquema Pre-conceptual

Concepto1 concepto3

relación relación

concepto2 concepto4
 Ejemplo
Proceso de Registro de Logros (Competencias)
Académicos

Modelo Verbal

Un estudiante que ingresa a un Programa de la Universidad tiene un

nombre y número de identificación. El programa tiene un número total
de competencias con las cuales el estudiante se compromete, y va
asumiendo y acumulando progresivamente el logro de las mismas.
Las competencias tienen una descripción precisa de las capacidades
que el estudiante debe desarrollar. Un docente evalúa periódicamente
las competencias alcanzadas por le estudiante. Cundo la relación de
las competencias logradas por el estudiante con respecto a las
competencias que ha asumido, es inferior a 0.40, el estudiante pierde
el derecho a permanecer en la Universidad, y una autoridad
académica decreta su expulsión. Cuando las competencias logradas
igualan o superan las competencias estipuladas por el programa, la
autoridad académica aprueba la graduación del estudiante.
IDENTIFICACIÓN NOMBRE

Tiene

ESTUDIANTE
 Identificación Nombre Compromiso Logro Enunciado

tiene Total
tiene

ESTUDIANTE COMPETENCIA PROGRAMA tiene

Alcanza

evalúa Docente
 Identificación Nombre Compromiso Logro Enunciado

tiene Total
tiene

tiene
ESTUDIANTE COMPETENCIA PROGRAMA

Alcanza

evalúa Docente

ESTUDIANTE.Logro/ Autoridad
ESUDIANTE.Compromiso expulsa Académica
<0.40

ESTUDIANTE.Logro= >
gradúa
PROGRAMA.Total
 Identificación Nombre Compromiso Logro Enunciado ESTUDIANTE
tiene Total
tiene Identificación

tiene
Nombre
ESTUDIANTE COMPETENCIA PROGRAMA
Compromiso
Alcanza Logro
evalúa Docente

ESTUDIANTE.Logro/ Autoridad
ESUDIANTE.Compromiso expulsa Académica
<0.40
COMPETECIA
ESTUDIANTE.Logro>
gradúa Enunciado
PROGRAMA.Total

PROGRAMA

Total
 MODELOS DE LA FASE DE DEFINICIÓN
DEL SISTEMA

-Modelo de Causa-Efecto
 Diagrama de Causa-Efecto o Diagrama de Ishikaua o Diagrama
de Espina de Pescado
Deficiente información Falta información
sobre el estudiante y sobre el programa
su desempeño
Identificación No se identifican los
incompleta o ambigua programas

No se conocen Dificultad para

Deficiente registro las exigencias establecer la situación
de logros académica de los
estudiantes (no se
sabe quien se puede
Falta definición sobre
qué y quién evalúa.
graduar y quien no).
No está explícita
la forma como
se evalúa

Falta información
sobre los criterios
de evaluación

No está clara la aplicación de

las condiciones de graduación
o de exclusión
 MODELOS DE LA FASE DE DEFINICIÓN DEL
SISTEMA

-Modelos de la Organización
 Modelo del Negocio
-Es el modo como una empresa crea, obtiene o entrega valor.

Responde a cómo la empresa atrae, entrega beneficios y maneja sus clientes.

Cómo maneja sus recursos. Cómo genera sus utilidades. Cómo se promueve.
Cómo configura sus procesos. Cómo establece y modifica su oferta de
productos.
En suma Cómo logra sus objetivos

ejemplo: Los negocios en los semáforos

La venta de impresoras (La impresora es el cebo y las tintas
son el anzuelo)

-Considera cómo la empresa se propone cumplir su objeto social, satisfacer los

requisitos de sus clientes

-Está soportado por estrategias

Éstas constituyen caminos para lograr sus objetivos
 Proceso del Negocio

Un Proceso del Negocio lo constituye un conjunto de actividades, dentro de

condiciones espacio temporales, que dan un resultado importante para la
organización a partir de unos elementos iniciales o de entrada, utilizando
medios e información, consumiendo recursos, sujeto a eventos que
determinan su dinámica, en busca de un objetivo específico que expresa o
está alineado con los objetivos de más alto nivel de la empresa.

-Permite conocer los procedimientos del negocios

-Allí se visualizan cuáles actividades o acciones van a ser asumidas por el

sistema de información y cuales no.

-Muestran el marco en el cual se inserta el sistema que se construye.

 REGLAS DE NEGOCIOS

Las reglas de negocios (o las directivas empresariales) definen

y controlan la estructura, el funcionamiento y la estrategia de
una organización.
Las reglas de negocios pueden estar formalmente definidas en
manuales de procedimiento, contratos o acuerdos, o bien
pueden existir como conocimiento o experiencia que tienen los
empleados.

Todos estos ámbitos de negocio comparten la necesidad de

transmitir estrategias, directivas y regulaciones empresariales al
personal de tecnologías de la información (TI) para su inclusión
en aplicaciones de software.
http://msdn.microsoft.com/es-
es/library/aa577691%28v=bts.10%29.aspx
COMPARACIÓN DE MODELOS DE PROCESO

-TRADICIONAL(HARRINGTON)

-CENTRADO EN AGENTES (MODELO DE

CONTEXTO DE UTILZACIÓN DE LA SOLUCIÓN)

-MODELO INTERMEDIO (ESTÁNDARD)

- MODELO CON LA NOTACIÓN BPML

bn GESTIÓN DE COMPETENCIAS ACADEMICAS

Adquiere Alcanza
Ingreso a un Compromiso Competencias
Programa (Total Competencias) 1

Información Identificación
Nombre
Logro s Compromiso
Logro
Estudiante
ESTUDIANTE

Evalúa Reporta Logro

Competencias de
Competencias
DOCENTE

(ESTUDIANTE.Logro/ Espulsar
Acumula Logros ESTUDIANTE.Compromi
Si Estudiante
estudiante
(Competencias) so) <0.40 Expulsado

No

ESTUDIANTE.Logro>= Si Graduar Estudiante

PROGRAMA.Total estudiante Graduado

No

AUTORIDAD
1
ACADÉMICA
GESTIÓN DE COMPETENCIAS ACADÉMICAS

Evalúa compromisos totales (Gradúa estudiante si logros<= Total competencias)

Evalúa compromisos Parciales (Expulsa estudiante si logros/compromisos parciales< 0.40)

Adquiere compromiso (Total competencias)

Acumula logros de competencias

Reporta logros de
competencias AUTORIDAD
ESTUDIANTE
Evalúa ACADÉMICA
competencias

Alcanza
competencias
DOCENTE
DIAGRAMA DE PROCESO INTERMEDIO ESTÁNDAR
 MODELOS DE CONCEPCIÓN ARQUIECTÓNICA
PRELIMINAR

-Modelos Básicos de la Fase de Análisis de

Sistemas

-Modelos de Contexto

-Modelos de Dominio
 Modelo de la Fase de Definición
del Sistema

Objetivos del Contexto Social

Conocimiento Representado por
Ajustado a
Existente y
Emergente Objetivos del Contexto
Adjusted to
Organizacional
Aporta Ajustado a Aporta
conocimientos conocimientos
Objetivos del Contexto del
Sistema
A partir de las
A partir de los interacciones de
Modelado
Conceptos de la ESOD Modelado del agentes en MCUS
del
Dominio
Contexto
Objetivos Objetivos
Operacionalizables Estructura de Servicios y de Modelo de Contexto Operacionalizables
Centrados en el Objetos de la Solución de Utilización de la Centrados en el
Dominio (ESOD) Solución (MCUS) Contexto
Concreta Determina

Operacionalizar por: Operacionalizar por:

-Despliegue de Metas (COMO) Requisitos de la Solución -Despliegue de Metas (COMO)
-Desagregación en procesos -Desgregación en procesos
-Patrón de Desagregación -Patrón de Desagregación
Transformados en

Objetivos Operacionalizables del

Sistema

Operacionalizar

Meta Operacionalizadas Meta Operacionalizadas Meta Operacionalizadas

Centrada en el Dominio del Sistema Centrada en el Contexto
MODELOS DE CONTEXTO
 Modelo de la Fase de Definición Modelo de la Fase de Definición
del Sistema del Sistema

Objetivos del Contexto Social

Conocimiento Representado por
Ajustado a
Existente y
Emergente Objetivos del Contexto MODELO PRE-CONCEPTUAL
Adjusted to
Organizacional
Aporta Ajustado a
conocimientos
Objetivos del Contexto del
Sistema

Modelado del Modelado

Dominio del
Contexto

Estructura de Servicios y de Modelo de Contexto

Objetos de la Solución de Utilización de la
(ESOD) Solución (MCUS)

Concreta Determina

Requisitos de la Solución

Transformados en

Objetivos Operacionalizables del

Sistema Operacionalizar por:
-Despliegue de Metas (COMO)
Operacionalizar -Desgregación en procesos
-Patrón de Desagregación
Meta Operacionalizadas
del Sistema
 Modelo de la Fase de Definición
del Plan de Desarrollo

Objetivos del Contexto Social

Conocimiento Representado por
Ajustado a
Existente y
Emergente Objetivos del Contexto
Adjusted to
Organizacional
Aporta Ajustado a Aporta
conocimientos conocimientos
Objetivos del Contexto del Plan de
desarrollo
A partir de las
A partir de los interacciones de
Modelado
Conceptos de la ESOD Modelado del agentes en MCUS
del
Dominio
Contexto
Objetivos Objetivos
Operacionalizables Estructura de Servicios y de Modelo de Contexto Operacionalizables
Centrados en el Objetos de la Solución de Utilización de la Centrados en
Dominio (ESOD) Solución (MCUS) Agentes

Operacionalizar por: Operacionalizar por:

-Despliegue de Metas (COMO) -Despliegue de Metas (COMO)
-Desagregación en procesos -Desgregación en procesos
-Patrón de Desagregación -Patrón de Desagregación

Meta Operacionalizadas Meta Operacionalizadas

Centrada en el Dominio Centrada en Agentes
 modelo del contexto de utilización :
Estudio de caso (Servicios de electricidad)
Un modelo de contexto de utilización representa las acciones e interacciones
de agentes por medio del sistema.
Solicitud y envió de
información
Información y
términos del contrato Empresas de
comercio de
Consumidores o Venta y facuturación servicios de
usuarios electricidad

Pago

Sub-contratos

Provisión de
servicios de
electricidad Empresas
Generadoras
De servicios de
electricidad
Estudio de caso (Servicios de Turismo): modelo del contexto de
utilización

Usuario o Modo de Empresa virtual de distribución

pago
Solicitud de Cliente global de servicios de turismo
servicios

Reservación Información
(venta) Confirmación de
de disponibilidad
disponibilidad
Solicitud
Demanda de
de información
confirmación de
complementaria
disponibilidad
para los servicios Aporte de
Información
para servicios
Ofrecimiento de Búsqueda de Proveedores
alternativas para disponibilidad de servicios
los servicios

Agencias de Organizaciones Frontera del sistema

turismo Solicitud de pago
de servicios
Confirmación de pago financieros
GESTIÓN DE COMPETENCIAS ACADÉMICAS

Evalúa compromisos totales (Gradúa estudiante si logros<= Total competencias)

Evalúa compromisos Parciales (Expulsa estudiante si logros/compromisos parciales< 0.40)

Adquiere compromiso (Total competencias)

Acumula logros de competencias

Reporta logros de
competencias AUTORIDAD
ESTUDIANTE
Evalúa ACADÉMICA
competencias

Alcanza
competencias
DOCENTE
ESTUDIANTE PROGRAMA

Identificación Total
Nombre
Compromiso
Logro
COMPETECIA

Enunciado
GESTIÓN DE COMPETENCIAS ACADÉMICAS

Evalúa compromisos totales (Gradúa estudiante si logros<= Total competencias)

Evalúa compromisos Parciales (Expulsa estudiante si logros/compromisos parciales< 0.40)

Adquiere compromiso (Total competencias)

Acumula logros de competencias

Reporta logros de
competencias AUTORIDAD
ESTUDIANTE
Evalúa ACADÉMICA
competencias

Alcanza
competencias
DOCENTE
 MODELO DE CONTEXTO DE ELABORACIÓN Y EJECUCIÓN
DEL PLAN DE DESARROLLO
Aportan ideas y sugerencias

Aportan conocimiento e información de servicios, procesos, necesidades y proyecciones de las o las áreas

Comunica las políticas, estrategias , metodología y conocimientos para la realización del plan

Solicita conocimiento e información para la realización del plan

Entrega el plan del área con objetivos, metas, proyectos, tiempos, recursos, indicadores

Provee el plan general con objetivos, metas, proyectos, tiempos, recursos, indicadores

Presenta plan de acción, indicadores, recursos, y responsables

ÁREAS DE LA
ÁREA DE ORGANIZACION
PLANEACIÓN Hace un seguimiento y control periódico sobre las metas y proyectos

Entrega informes
Provee periódicos
información de servicios,
de sus cumplimiento de metas
procesos y proyectos
y necesidades

Presenta metodologías de planeación Presenta resultados finales del proyecto

Determina una alternativas de planeación Presenta modificaciones a los proyectos
Establece objetivos de la organización Establece objetivos de la organización

Define acciones sobre el plan Informa desarrollo de proyectos

Presenta evaluación final del plan GERENCIA DE Define acciones sobre los proyectos
LA
Comunica estado de desarrollo del plan ORGANIZACIÓN Provee recursos aprobados
Presenta el plan de la organización y de las áreas Solicita recursos para ejecución de proyectos
 ESTRUCTURA SERVICIOS Y OBJETOS DEL DOMINIO
SISTEMA PLANEACIÓN

Servicios de
planeación

Tipo de

Adopción de Gestión de Determinación Formulación de Despliegue Ejecución

Metodología Conocimiento de agentes y metas básicas de metas del plan
relaciones

Compuesto por Permite elaborar Permite

Usando Contiene Mediante
Del plan Conocimiento Diagrama de Control
general a los social contexto de El contexto Objetivos
particulares utilización de
utilización Informes
Conocimiento Metas
De planes organizacional Estructura de
particulares al servicios y La Estructura
de servicios y Evaluación
general objetos del
objetos del Proyectos
dominio Mediante
dominio
Elaboración
De doble vía: Necesidades continua
del esbozo del de los agentes El contexto
plan general a de utilización
y Estructura Compuesto por
los planes
particulares y de servicios y
objetos del Responsables
de estos al
plan general dominio
Recursos
 PROGRAMA
ESTUDIANTE
Total
Identificación
Nombre
Compromiso
Logro COMPETECIA

Enunciado
MODELOS DE DOMINIO
 Directrices para Definir las Categorías Superiores de la ESOD
Productos o Servicios
del Dominio

Categorías de Categorías de Categorías de Categorías de

entrada Evolución Decisión Salidas
Adquirir Incrementar Validar Actualizar
Conocimiento. Conocimiento. Conocimiento. Conocimiento.

Obtener Objetos Completar o Diagnosticar Objetos Salvar Objetos

Tangibles. Desarrollar Objetos Tangibles. Tangibles.
Tangibles.
Recibir Señales, Adoptar Objetos Explotar Objetos
Flujos, Energías Incorporar Objetos Tangibles. Tangibles.
Tangibles
Presentar Asumir Señales, Inducir Señales,
conocimientos Tratar Señales, Flujos Flujos, Energías Flujos, Energías
técnicos, de Energías
normativos,
promocionales
 Directrices para Obtener las Categorías
Superiores de la ESOD
Las categorías superiores previamente definidas, tienen
relaciones de especialización respecto al encabezado de
Productos o Servicios del Dominio

Las categorías superiores son grandes funcionalidades del

sistema , referentes a sus ENTRADAS, OPERACIONES,
EVALUACIONES O DECISIONES, Y SALIDAS. Por esto, se
determinan de acuerdo con los 16 tipos de funcionalidades que
identificamos en un proceso

Algunas pautas para determinar estas categorías son:

1-Definir cuales de los 16 de funcionalidades se tendrán en

… de acurdo con la naturaleza del sistema en estudio.
cuenta,
2-Enunciar funcionalidades, con base en el conocimiento obtenido
en la fase de definición.
3-Completar las funcionalidades mediante analogía con otros
dominios, la consulta con expertos, y/o con los agentes
interesados en el sistema
Directrices para Definir las Categorías Superiores
de la ESOD

PROCEDIMIENTO

1-Con base en la segunda y tercera categoría de Productos y Servicios (de operación y

transformación, y de evaluación y decisión) se definen los productos o servicios que
en estas categorías el sistema debe realizar.

2-Con relación a la primera categoría de Productos y Servicios (de Entrada y de

preparación) se definen los servicios que el sistema puede ofrecer antes de ofrecer
los servicios de las categorías dos y tres (por ejemplo información técnica de los
productos y servicios, condiciones de acceso, normas, métodos aplicables,
tratamientos previos del conocimiento, de objetos tangibles o intangibles, etc.).

3-De acuerdo con la cuarta categoría de Productos o Servicios (de aporte y de

aprovechamiento) se define los productos y servicios que el sistema puede ofrecer
luego de la realización de los servicios operativos que determinan la naturaleza y
objeto central del sistema (Actualizaciones de conocimiento, entrega de objetos
tangibles o intangible, garantías, soporte técnico, historial y estadísticas de
conocimientos, de objetos tangibles o intangibles, tratamiento de señales, flujos de
energía, y de otros objetos intangible).
Directrices para Obtener las Categorías Inferiores
de la ESOD
1.Utilizar 4 tipos de relaciones para los conceptos inferiores:

1.1 Generalización/Especialización (El concepto inferior es

un tipo del conceptos superior).

1.2 Composición (Los conceptos inferiores son

componentes del concepto superior).

1.3 Caracterización (los conceptos inferiores son atributos

del concepto precedente).

1.4 Específicas del Dominio (relaciones particulares,

usuales en dominio. Las introduce el conceptualizador
del sistema, quien le asigna un nombre representativo).

2- Introducir en cada gran funcionalidad los conceptos detallados

que se requieren para realizarla
Structure of Domain Services and Objects
(SDSO):
-System for Selecting co-created Ideas- Contributions (Ideas)
Selection Services

Selection of Definition of Objectives, Establishment of Management of

Contributions Functions and Elements Contributions Selected
(ideas) in the Use Context of the Selection Methods Contributions (Ideas)
Product or Service
Recovering of
Contributions Creation or Recovering and
Modification of use of Selected
Applying a Selection Methods Contributions
Selection Method
Definition of
Elaboration of Possible Functions Choice of a Classification
Selected and Uses of a New Selection Method of Selected
Contributions Product or Service Contributions

Protect and Make Definition of Objectives Suppression of a Modification or

Available Selected for Searching a New Selection Method new elaboration
Contributions Product or Service of Contributions

Protect and Make General and technical General and technical

Available Non- Information about the Information about the
Selected Possible to be Innovative organization and Contribution
Contributions Product or Service Selection services
 Representación de una ontología Servicios de
turismo

Tipo de

Servicios de Servicios de Servicios de Servicios de seguros

hotel vuelo alquiler de autos de viaje

Tipo de

Búsqueda
Información del
proveedor Disponibilidad Reservación (venta) Pago Solicitud de anulación
servicio

Caracterizado
Compuesto por
Estado reservación
de

Parámetros
del
servicio

Compuesto de
Cantidad

Tarifa

Duración

Fecha de inicio

Información del
demandante

Tipo de

Mensaje

Tipo
Caracterizado
por
 Interacciones Típicas de Agentes
Para cada sistema las interacciones entre agentes, en el Contexto de
Utilización de la Solución son identificadas con base en los
conocimientos de los contextos social y organizacional y
considerando las siguientes intervenciones típicas entre agentes
comerciales propuestas en [Urrego, 2005]:
• Establecer relación
• Solicitud de objetos y/o de servicios
• Contratación de objetos y/o servicios
• Realización de servicios
• Entrega de servicios y/o de objetos en el sitio
• Entrega de servicios y/o de objetos a domicilio
• Facturación-cobro
• Pago-retribución
• Solicitud o entrega de informaciones técnicas, comerciales, legales,
organizacionales y personales.
• Entrega o Recibo de objetos y/o de informaciones de postventa.
 Requisitos

Requisitos Funcionales
•Indican lo que hacen o deben hacer los sistemas.
•Necesidades de los agentes
•Intervenciones del sistema propuesto
•Se enuncian como:
•Expresiones lógicas
•Expresiones de lenguajes técnicos (Lenguajes de
requisitos, lenguaje natural restringido)
•Lenguaje natural

•Son generalmente representados por metas

 Requisitos
Estrategias de descubrimiento de requisitos
- Centradas en modelos del contexto
-Modelos de Contexto: Globales y Específicos
-Modelos basados en Elementos de los Contextos
-Modelos de contexto y de Dominio
-Modelos Centrados en el ciclo de vida
- Centradas en Categorías de Requisitos
-Taxonomías
- Frames
- Centradas en representaciones del Conocimiento
- Metas
- Unidades de Conocimiento (Agrupaciones de metas)
-Centrados en Técnicas de Obtención de Conocimiento
-Centradas en Modelos de la Naturaleza y de las Ciencias
 Requisitos

Definition Analysis
Verbs : Verbs:
reason, think,
Design
require, need, Verbs:
wish conceive analyze,
make, draw, plan,
conceptualize
delineate, create,
Construction(code)
specify, design
Verbs:
construct, code,produce

Goals/
Test
Requirements Verbs :
The verbs in each phase test, verify, examine,
characterize the goals and compare
requirements
Operation
End Verbs :
Maintenance
Verbs : make, inform, apply,
Verbs :
End, finish, verify, perform effectuate
maintain, manage,
decommission give, execute
preserve
 Requisitos
Requisitos No-Funcionales

Expresan cualidades de los sistemas, de sus

componentes, de sus objetivos, de sus procesos, de las
metas o intenciones de los agentes de los contextos
externos e interno del sistema, de los objetos
implicados por las intervenciones de los agentes y del
sistema
Se representan por metas o por características
incorporadas en las metas
 Requisitos No-Funcionales
Estrategias para el descubrimiento de Requisitos No-Funcionales:

- Se tratan dentro de los mismos modelos adoptados para

el descubrimiento de los Requisitos Funcionales.

- Se tratan a la par que los requisitos Funcionales y en las

mismas etapas de la fase de análisis

Se deben transformar en Requisitos operacionalizables

Una vez transformados en requisitos operacionalizables

reciben los mismos tratamientos que los requisitos
funcionales
 Requisitos No-Funcionales

Definition
feasibility Analysis
generality, scalability Design
usability simplicity consistency
trainability
Construction(code)
compatibility
modularity
external consistency
orientation

Non-functional
Test
features ready to operation
availability
accessibility

Operation
End Maintenance maintain
obsolete preventability programmability
recyclable maturity
 Requisitos
Ejemplo de expresión de Requisitos No-Funcionales
Meta (Intervención de Agente):

El gestor de servicios de hotel ]Agente principal maneja (gère)

(manage) [servicios de reservación de hotel ]Objeto [desde la
creación del servicio] Situación 1 [hasta la realización del servicio
]Situación 2 [por medio de un sitio Web] Medio [utilizando un
método para el caso normal ]Método [para el gestor de
reservaciones] Agente interactuante

- Adjetivos o expresiones adjetivas afectando los agentes, los

objetos, los medio, los métodos
- Adverbios o expresiones adverbiales afectando la meta
completa, el verbo, otros parámetros representados por metas
 Modelos de Requisitos
Metodologías

Metodologías Metodologías
orientadas por orientadas por
agentes metas y escenarios
KAOS Metodologías Crews-
Metodologías
L’Ecritoire
I*
orientadas por orientadas por
GBRAM metas escenarios
ABC-Besoins
KAOS ScenIC
I* SCRAM
GBRAM ECSAM
ABC-Besoins
 Taxonomías de Requisitos

Categorías de Requisitos
Descripción o caracterización Física
de agentes y de objetos de un Mental
dominio
Disponibilidad de objetos (espacio, tiempo)
Convocación a un agente o demostración de la existencia de
un agente
Proposición y escogencia de alternativas
Demandas (de acceso o interrogación)
Aportes (entradas o respuestas)
Verificación y decisión
Acciones de agentes Concretas
Abstractas
Interacciones de agentes Concretas
Abstractas
Transferencia o actualización
interrupción o restitución o conservación
Rendimiento
Evolución o Cambio
Precios y costos
 Obtención de Requisitos de los agentes
1- Expresar los objetivos de los contextos social y organizacional que recogen el conocimiento de
estos contextos y en los cuales se propone y se asume el reto de la realización del sistema

2- Construir el diagrama de Contexto de Utilización de la Solución.

Este diagrama permite conocer los agentes y sus interacciones con base en los
conocimientos que se tengan de los contextos social y organizacional.

3- Servirse del modelo de interacciones típicas entre agentes comerciales para completar las
interacciones entre agentes en el diagrama de contexto de utilización.
4- Construir la Estructura de Servicios y de Objetos del Dominio
5- Con base en dichas interacciones entre agentes se pregunta "qué es lo que desea,
pretende, aspira, necesita, prevé, etc. un agente en su interacción con otro, por medio del
sistema?, en relación con cada una de las interacciones del diagrama de Contexto de Utilización
de la Solución y refiriendo la pregunta a cada una de las categorías de la taxonomía de
requisitos. Todo esto en función de los conceptos de la Estructura de Servicios y de Objetos del
Dominio.
6- Tener presente que para cada interacción de un par de agentes se construyen dos tablas de
requisitos, una por cada agente actuando como agente principal.

7- Las respuestas a las preguntas "qué es lo que...............? “, constituyen los requisitos de los
agentes con relación al sistema.
 Obtención de Requisitos de los agentes
Forma Directa
1- Expresar los objetivos de los contextos social y organizacional que recogen el conocimiento de
estos contextos y en los cuales se propone y se asume el reto de la realización del sistema

2- Construir el diagrama de Contexto de Utilización de la Solución.

Este diagrama permite conocer los agentes y sus interacciones con base en los
conocimientos que se tengan de los contextos social y organizacional.

3- Servirse del modelo de interacciones típicas entre agentes comerciales para completar las
interacciones entre agentes en el diagrama de contexto de utilización.
4- Construir la Estructura de Servicios y de Objetos del Dominio
5- Con base en dichas interacciones entre agentes se pregunta "qué es lo que desea,
pretende, aspira, necesita, prevé, etc. un agente en su interacción con otro, QUE EL SISTEMA
HAGA ?, en relación con cada una de las interacciones del diagrama de Contexto de Utilización
de la Solución y refiriendo la pregunta a cada una de las categorías de la taxonomía de
requisitos. Todo esto en función de los conceptos de la Estructura de Servicios y de Objetos del
Dominio.
6- Tener presente que para cada interacción de un par de agentes se construyen dos tablas de
requisitos, una por cada agente actuando como agente principal.

7- Las respuestas a las preguntas "qué es lo que...............? “, constituyen los REQUISITOS DEL
SISTEMA .
Obtención de Requisitos No-Funcionales con ABC-Requisitos
En ABC-Requisitos se pretende obtener los Requisitos No-Funcionales en los
mismos procesos de análisis aplicados para la obtención de los Requisitos
Funcionales, y al mismo tiempo que se obtienen éstos, Así:
1-Seguir los primeros cuatro pasos del procedimiento para obtener Requisitos
Funcionales (RFs).

2-Retomar los requisitos obtenidos con el procedimiento para obtener los RFs
utilizando la primera de las catorce categoría de la taxonomía de requisitos.
Completar y confirmar estos requisitos con base en los conceptos expresados en los
objetivos del contexto del sistema (ajustados de los objetivos del contexto
organizacional mediante un patrón de ajuste), en el Modelo de Contexto de
Utilización de la Solución (MCUS), y de la Estructura de Servicios y de Objetos del
Dominio (ESOD).
Esta primera categoría estipula:
“Descripción o caracterización de agentes interactuantes, y de los objetos de un
dominio”

3-Tomar cada uno de los Requisitos Funcionales obtenidos previamente usando las
otras trece categorías (de la segunda a la catorce) de la taxonomía de requisitos y
asignarles los atributos de calidad que correspondan conforme a un modelo de
calidad vigente. Esta asignación de atributos de calidad se hace en la expresión de
cada Requisito Funcional para el verbo (las acciones expresadas por el verbo) y los
objetos contenidos en dicha expresión.
Obtención de Requisitos No-Funcionales con ABC-Requisitos
-Esta asignación corresponde a completar con atributos de calidad las exigencias de
los agentes previamente obtenidos.

-O se puede hacer la asignación de los atributos de calidad en el mismo procesos

donde se identifican los Requisitos Funcionales esto, agregando los atributos de
calidad al mismo tiempo que se responde a la pregunta:

"qué es lo que desea, pretende, aspira, necesita, prevé, etc. un agente en su

interacción con otro, por medio del sistema?, en relación con cada una de las
interacciones del diagrama de Contexto de Utilización de la Solución y refiriendo la
pregunta a cada una de las categorías de la taxonomía de requisitos (de la segunda
a la catorce). Todo esto en función de los conceptos de la Estructura de Servicios y
de Objetos del Dominio”.
MODELOS CONCEPTUALES (LOGICOS ) DE LA
FASE ANALISIS DE SISTEMAS
 Modelo Conceptual y
Modelo de Diseño

German Urrego Giraldo

Universidad de Antioquia
 Modelo Conceptual

En la metodología de diseño UdeA propuesta se adopta un modelo conceptual

denominado Diagrama de Funcionalidades y Clases y compuesto por la unión de
los dos diagramas siguientes: Diagrama de Funcionalidades y Extracto del
Diagrama de Clases.
 Modelo Conceptual
-Diagrama de Funcionalidades. Se expresa como un grafo de Casos de Uso.
El grafo muestra caminos principales y caminos subordinados. Un camino principal y
sus caminos subordinados constituye un sub-sistema (Unidad de Procesos).

Caso de uso

Caso de uso

Caso de uso

Caso de uso
Caso de uso

Caso de uso

Caso de uso

Caso de uso Subsistema 3

Caso de uso

Subsistema 2
Subsistema 1
 Modelo Conceptual

Caso de Uso: Conjunto de acciones interrelacionadas de un conjunto de

agentes, las cuales que producen resultados consolidados que satisfacen
un objetivo común de dichos agentes.
Un Caso de Uso, contribuye a un objetivo final, definitivo, de valor para uno
o varios agentes y constituye un proceso definido (varias Interacciones),
dividido en sub-procesos, que determinan estados y resultados
aprovechables, estables, almacenables y recuperables.
El sub-proceso tiene la misma definición que un proceso, pero con
resultados intermedios y parciales pertenecientes al resultado del proceso.
 Modelo Conceptual y de Diseño

Unidad de Casos de Uso (Subsistema)

Unidad de Casos de Uso o Sub-sistema: Conjunto de Casos de Uso que

colaboran o cooperan para el logro de un objetivo.

Determina un resultado final próximo a los objetivos de alto nivel de la

organización.

La Unidad de Casos de Uso tiene valor para varios agentes y determina

estados y resultados que además de aprovechables, estables, almacenable
y recuperables vinculan agentes por fuera de la organización son
transferibles a dichos agentes.

El Caso de Uso constituye una contribución identificable y separable dentro

de una Unidad de Casos de Uso.
 Modelo Conceptual y de Diseño

- Extracto del Diagrama de Clases. Consiste en un grafo de Clases cuyas

relaciones indican el aprovechamiento (conjunto de operaciones) que
una Clase hace de otra y el aprovechamiento que los Casos de Uso del
Diagrama de Funcionalidades hacen de las Clases.

El Extracto del Diagrama de Clases se construye con las Clases

extraídas de la Estructura de Servicios y de Objetos del Dominio (ESOD) y
considerando el aprovechamiento de Clases requeridas por los Casos de
Uso del Diagrama de Funcionalidades y el aprovechamiento que unas
Clases hacen de otras Clases.
 Modelo Conceptual y Diseño

El Diagrama de Funcionalidades y de Clases se construye a partir de las

Funcionalidades obtenidas de los requisitos de los agentes (metas), agrupando
dichas funcionalidades en Casos de Usos organizados en un grafo jerárquico y
adjuntando el Extracto de un Diagrama de Clases afectado por los Casos de
Uso.
Las Clases se conectan entre si y con los Casos de Uso por los
aprovechamientos (conjunto de operaciones) que hagan de una Clase, bien sea
un Caso de Uso u otra Clase.
Así, el diagrama de Funcionalidades y Clases integra los dos diagramas
anteriores en un solo diagrama consistente en un grafo con dos tipos de nodos:
Casos de Uso y Clases.

El resultado es un grafo que constituye el Diagrama de Funcionalidades y

Clases
 Del Modelo Conceptual al Modelo de Diseño
Diagrama de Funcionalidades y Clases

Caso de uso

Caso de uso
Clase A Usa

Usa
Caso de uso

Caso de uso Clase B

Caso de uso

Usa
Caso de uso

Caso de uso

Clase C
Usa
Subsistema 3 Usa
Caso de uso
Caso de uso

Subsistema 1 Subsistema 2
 Del Modelo Conceptual al Modelo de Diseño
Modelo de Diseño
Se consideran dos niveles de diseño: General y de Detalle

1-Modelo de Diseño general o de alto nivel

Se adopta un modelo de tres capas, las cuales a su vez se pueden dividir, dando
lugar a un modelo de un mayor numero de capas. Las tres capas básicas generales
son: Capa Básica, Capa de Funcionalidades, y Capa de Interacción Externa.

•La Capa Básica comprende: Infraestructura de hardware y de Software, algunos

servicios comunes de bajo nivel, mecanismos de apoyo, tales como:
administradores de recursos, comunicaciones, almacenamientos,

•La Capa de funcionalidades contiene las funcionalidades y los dispositivos que los
soportan. Se desarrolla a partir del Diagrama de Funcionalidades y Clases.

•La Capa de Interacción externa la conforman las interfaces con los agentes
externos (usuarios, sistemas, otros agentes). Se desarrolla a partir del Diagrama de
Contexto de Utilización de la Solución).
 Del Modelo Conceptual al Modelo de Diseño
Modelo de Diseño general o de alto nivel

Capa de Interacción Externa

Capa de Funcionalidades
Capa Básica

Estas capas construyen el diseño general o de alto nivel. Dentro de las capas
pueden existir Sistemas, subsistemas, módulos, servicios, procesos, actividades.
 MEDIOS ARQUITECTURA LOGICA GENERAL LENGUAJES

INTERFACES
MODULOS (VISTA) PHP
DE
INTERFACES INFORMACION
(MODELO)

MODELO DE BASE DE
CLASES DATOS LENGUAJES
DE BASES DE
LOGICA DEL DATOS
MODELO

MODULO DE
CONTROLADOR
SERVICIOS
(CONTROL)
LOGICA DE LAS
JAVA
FUNCIONALIDADES (CASOS DE
C++
USO)

ARQUITECTURA DEL CONTROLADOR

(CONTROL)
 Del Modelo Conceptual al Modelo de Diseño
Modelo de diseño Específico (de Detalle o de Bajo Nivel)
El diseño especifico, de detalle o de bajo nivel se expresa mediante Diagramas Operativos
del Sistema, agrupados en módulos, sistemas y subsistemas. Dichos Diagramas están
compuestos por conjuntos de Servicios, Procesos, actividades, o acciones, representadas en
escenarios, y por clases.
A partir del grafo denominado Diagrama de Funcionalidades y Clases y que constituye el
Modelo conceptual del Sistema, se construye el Diagrama Operativo del Sistema o modelo
de diseño específico, de la siguiente forma:

1-Para cada nodo representando un caso de uso, en el Diagrama de Funcionalidades y

Clases se construyen uno o varios escenarios. Se adopta el tipo de escenario Operativo,
constituido por un estado inicial o pre-condiciones y un estado final o pos-condiciones
como puntos inicial y final de un diagrama de flujo de datos o modelo lógico asociado al
caso de uso.
 Del Modelo Conceptual al Modelo de Diseño

Modelo de diseño Específico (de Detalle o de Bajo Nivel)

2-Las clases del Diagrama de Funcionalidades y Clases se pasan al Diagrama

Operativo, conectándolas a uno o varios servicios, procesos, actividades o
acciones de un escenario correspondiente al caso de uso al cual estaba
originalmente conectada la clase. Para nuestro caso tomaremos escenarios a nivel
de actividad.
Una actividad se define como un conjunto de acciones con agente responsable y
otro u otros agentes interactuantes, operando sobre un objeto sin causarle un
cambio de estado significativo para el sistema en estudio.

3- Las relaciones entre las actividades del escenario y las clases y las relaciones
entre estas son operaciones que deben ser definidas en las clases direccionadas
por una actividad o por otra clase. En la codificación del sistema lo que realmente
se implementa de estas operaciones son sus métodos..Una clase es invocada
(activada) mediante el paso de método para una operación definida en esta clase.
Del Modelo Conceptual al Modelo de Diseño
Diagrama Operativo del Sistema

Procesador
Estado Inicial
(Precondiciones) Clase A

Operación 1
Clase B
Operación 2
Operaciones
1y2
Operación 3
Operación 3

Actividad

Procesador
Clase C

Estado final
(Poscondiciones)