EN ESTE TRABAJO LES PRESENTAMOS UNA PARTE FUNDAMENTAL PARA PROYECTOS, LAS CUALES SE DEBE TENER EN CUENTA POR SU GRAN IMPORTANCIA DE COMO SE VA MANEJANDO
3. DEFINICIÓN
UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente. A través del modelado de
casos de uso, los actores externos que tienen interés en el sistema son modelados con la funcionalidad que
ellos requieren del sistema (los casos de uso). Los actores y los casos de uso son modelados con relaciones
y tienen asociaciones entre ellos o éstas son divididas en jerarquías. Los actores y casos de uso son
descritos en un diagrama use-case. Cada use-case es descrito en texto y especifica los requerimientos del
cliente: lo que él (o ella) espera del sistema sin considerar la funcionalidad que se implementará. Un análisis
de requerimientos puede ser realizado también para procesos de negocios, no solamente para sistemas de
software.
4. MODELADO DE NEGOCIOS
Se define como un proceso de representación de uno o más
aspectos o elementos de una empresa como el propósito, su
estructura, funcionalidad, dinámica, lógica de negocios y
componentes como fines, procesos, reglas, objetos, actores y
unidades organizativas entre otras.
5. MODELADO DE NEGOCIO
MODELO DE CASOS DE USO DEL NEGOCIO
Modela la forma en que el negocio es usado por sus clientes, stakeholders, etc.
Está formado por:
Actores del negocio identificados previamente.
Casos de uso del negocio identificados previamente.
Asociaciones entre los actores y los casos de uso del negocio.
Diagrama de Casos de Uso del negocio.
Identificar los casos de uso del negocio
Sugerencias para identificar adecuadamente los casos de uso del negocio.
Son proceso complejos del negocio, no actividades simples.
6. MODELADO DE NEGOCIO
MODELO DE OBJETO DEL NEGOCIO
Para crear el Modelo de Objeto del Negocio se deben
utilizar los siguientes estereotipos.
El Modelo de Objeto es creado a través de los Diagramas de
Actividad que describen los Casos de Uso del Negocio con
los objetos o documentos incluidos. Generalmente la
primera calle que inicia el Diagrama de Actividad
corresponde a un Actor del Negocio, las restantes
pertenecen a un Trabajador del Negocio.
7. MODELADO DE NEGOCIO
MODELO DE DOMINIO
Un modelo de dominio en la resolución de
problemas e ingeniería de software, es un modelo
conceptual de todos los temas relacionados con un problema
específico. En él se describen las distintas entidades, sus
atributos, papeles y relaciones, además de las restricciones que
rigen el dominio del problema.
IMPORTANTE
Un modelo del dominio es una representación de las
clases conceptuales del mundo real, no de componentes
software. No se trata de un conjunto de diagramas que
describen clases software, u objetos software con
responsabilidades.
8. RESUMEM
En este trabajo se da a entender que el análisis de requerimiento puede parecer una tarea relativamente
sencilla. Este análisis abunda una tarea la cual cubre el hueco entre la definición del software a nivel sistema
y el diseño de software.
Entonces el análisis de requerimiento nos permitirá especificar las características operacionales del software,
indicando la interfaz del software con otros elementos y establece las restricciones que debe cumplir el
software.
9. SUMMARY
This paper suggests that the requirement analysis may seem a relatively simple task. This analysis abounds
a task which bridges the gap between the definition of system-level software and design software.
Then the requirement analysis will allow us to specify the operational characteristics of the software,
indicating the software interface with other elements and sets restrictions to be met by software.
10. RECOMENDACIÓN Y CONCLUSIONES
RECOMENDACIONES
Para poder hacer un análisis de requerimientos con los modelados se debe conocer a los clientes y
usuarios.
Deben realizar la entrega de software de calidad, a tiempo y dentro de un presupuesto cómodo.
Establecer las buenas relaciones con los clientes al brindarles el requerimiento de software.
CONCLUSIONES
Llegamos a la conclusión que cada análisis que se realiza se debe tener en cuenta los requisitos que este
tiene.
También podemos decir que esta es una estructura que puede requerir de cambios sin perder la
estructura y el estilo
Finalmente concluimos que es el conjunto completo de capacidades para reconocer cuán importante es
el software.
11. APRECIACIÓN DEL EQUIPO
Para nosotros el análisis de requerimiento en una parte fundamental, para poder realizar cualquier
proyecto, se debe realizar un análisis el cual pueda estar enfocado en la descripción del propio sistema, de
tal manera que representaría una base de la comunicación entre los desarrolladores. Teniendo en cuenta de
los requisitos que esto lleva y seguir al pie de la letra, para poder realizar bien un análisis de requerimiento.
12. GLOSARIO DE TÉRMINOS
Diagramas:
Un diagrama o gráfico es un tipo de esquema de información que representa datos numéricos tabulados.
Casos:
Ocasión, situación o conjunto de circunstancias.
Roles:
Está vinculado a la función o papel que cumple alguien o algo.
Análisis
Es el proceso de extraer las cosas más importantes para poder quedarte con lo esencial de esa cosa, lo cual
hay muchas formas de poder llamarlo análisis.
Dominio
Acción de dominar
13. GLOSARIO DE TÉRMINOS
Entidad
Asociación de personas de cualquier tipo, en especial la que se dedica a una actividad laboral.
Jerarquías
Organización de personas o cosas en una escala ordenada y subordinante según un criterio de mayor o menor importancia o
relevancia dentro de la misma.
Procesos
Es un conjunto de actividades mutuamente relacionadas o que al interactuar juntas en los elementos de entrada los
convierten en resultados.
Ejecución
Realización de una acción, especialmente en cumplimiento de un proyecto, un encargo o una orden.
Innovación
Acción de innovar.