SlideShare ist ein Scribd-Unternehmen logo
1 von 10
Downloaden Sie, um offline zu lesen
Instituto Universitario de Tecnología
“Antonio José de Sucre”
Estudio De Factibilidad.
24/07/2013
Alberlis Vasquez 24.159.956
José Tua 20.017.686
Introducción
En la siguiente presentación de dará a conocer los casos de Estudio de
Factibilidad, su diseño, sus métodos, pasos, el Ciclo de Vida de lo Sistemas de
Información, el Estudio de Factibilidad en los Sistemas de Información, entre
otras cosas que verán mas adelante en la presentación realizada.
Estudio de Factibilidad
Un estudio de factibilidad es una versión comprimida del proceso total de
análisis y diseño del sistema.
El estudio comienza clarificando la definición del problema. Se confirma o se
corrige la definición inicial de alcances y objetivos, y se identifica cualquier
restricción impuesta sobre el sistema.
Al menos se pueden considerar tres tipos diferentes de factibilidad:
Técnica: ¿Puede implementarse el sistema usando la tecnología
actual?
Económica: ¿Los beneficios superan los costos?
Operacional u organizacional: ¿Puede implementarse el sistema en
esta organización?
Para cada solución factible, el analista prepara una planificación
preliminar de la implementaron, luego de esto se le presenta al gerente y
seguidamente al usuario.
Pasos para el estudio típico de Factibilidad.
Definir los alcances y objetivos del sistema.
Se requerirá realizar entrevistas con personal clave y alguna revisión del
material escrito. Esencialmente, el analista intenta responder una pregunta muy
simple: ¿Estoy trabajando en el problema correcto?.
Se requerirá realizar entrevistas con personal clave y alguna revisión del
material escrito. Esencialmente, el analista intenta responder una pregunta muy
simple: ¿Estoy trabajando en el problema correcto?.
Estudio del sistema existente
Esto se da obviamente, si un sistema se usa, debe estar realizando algún
trabajo útil, y sus funciones básicas deben incorporarse al nuevo sistema.
Por otro lado no de tendría que modificar nada si el programa o el sistema
existente esta en un buen estado y aun funciona como debe de funcionar.
Por consiguiente tenemos que analizar cuidadosamente los procedimiento y
la información escrita. Aprendamos que hace el sistema y el porque lo hace de
esa manera.
Desarrolle un modelo lógico de alto nivel del sistema propuesto.
En este momento, el analista debe tener un buen sentido de las
funciones y restricciones del sistema nuevo. Un modelo lógico del sistema
nuevo puede construirse usando un diagrama de flujo de datos y tal vez un
diccionario de datos
Redefinir el problema a la luz de los nuevos conocimientos.
En este paso o fase el analista debe tener la definición del problema, el
alcance y los objetivos con el personal clave para esto. Si el analista no ha
entendido y el usuario tampoco o a pasa por alto algunas cosas, ahora es el
momento de solucionarlo
.
El analista define el problema, lo analiza, desarrolla una solución
tentativa, redefine el problema, lo reanaliza, revisa la solución, y continúa este
proceso cíclico hasta que el modelo lógico reúne los objetivos del sistema.
“Piense a los primeros cuatro pasos del estudio de factibilidad
como un todo.”
Desarrollar y evaluar soluciones alternativas.
Dado un modelo lógico del sistema propuesto, el analista puede comenzar a
generar alternativas de soluciones físicas de alto nivel.
El estudio de Factibilidad de los S.I.
Diseños de Sistemas de Información.
A partir de este paso el analista y el diseñador del sistema en conjunto
con el usuario, deben de encontrar una solución que conviertan los requisitos
encontrado en la fase de análisis de sistema en un sistema real.
El análisis de sistema se centraba en lo que se debe hacer, es decir, en
los requisitos del sistema desde el punto de vista de los usuarios, mientras que
el diseño se enfoca en lo que se tiene que realizar. Por lo tanto en la etapa de
diseño se debe de investigar que datos se usaran y como se alcanzaran.
Inicio de un Nuevo Sistema
Planificacion de
Sistemas
Analisis del
Sistema aCTUAL
Analisis de
Requisitos
Diseño Logico
Diseño Fisico
Implementacion
Para el alcance de estos objetivos, la etapa de diseño esta comprendida
por 2 fases.
Diseño lógico del nuevo sistema.
Diseño físico del nuevo sistema.
Diseño lógico del nuevo sistema.
Es la fase donde se debe de enlazar o llevar a cabo lo que el usuario
desea, y de esta manera levarlo al la fase 2 que seria llevar el sistema a lo
físico, es decir, a lo que se llamaría sistema funcional.
Diseño físico del nuevo sistema.
Es donde el diseño lógico se pone en marcha donde se le harán
correcciones necesarias para que el usuario pueda disfrutar del sistema
correctamente.
Relación entre los sistemas.
Modelo Lógico Modelo Físico
Modelo de Datos Representación de la
estructura y la relación de
los datos esenciales
Representación de las
estructura y las relaciones
de los datos para la
implementación del
diseño lógico
Modelo de Procesos Representación de los
procesos y los flujos de
datos esenciales
Representación de los
flujos de los datos para
implementar el modelo
lógico de los datos del
proceso.
Ciclo de vida de un sistema informático
Estudio de
Factibilidad
Análisis de
Requerimiento
Diseños
Creación de
PROTOTIPOS
Implementación
Validación y Prueba
Operación y
Mantenimiento
Es el tiempo que vive un sistema desde el momento en que es pensado
hasta que muere o no es útil
Las actividades típicas del ciclo de vida son:
 Reconocimiento del problema
 Estudio de factibilidad
 Análisis
 Diseño
 Implementación (Codificación)
 Prueba
 Mantenimiento
Reconocimiento del problema: Surge cuando el usuario reconoce que
tiene problemas con los medios con que cuenta actualmente para llevar a
cabo su trabajo. Así comienza esta fase que trata de reemplazar el sistema
existente por otro. En esta fase interviene totalmente el usuario.
Estudio de la factibilidad: Se decide si el usuario necesita o no una
computadora. Este estudio sirve para:
- Identificar los problemas con el sistema actual.
- Identificar el alcance del sistema a ser estudiado.
-Identificar los principales objetivos del nuevo sistema.
- Identificar un número de soluciones que pueden satisfacer las necesidades
del usuario dentro de su esquema.
- Desarrollar estimados de los beneficios y desventajas de cada solución.
- Desarrollar esquemas de cómo puede llevarse a cabo el proyecto teniendo
una idea de los recursos que se requieren.
-Obtener puntos de vista del usuario y el administrador sobre las
Modificaciones.
- Obtener una decisión de si se lleva a cabo la parte de análisis.
Todo este estudio evitará el gasto de un análisis de un proyecto imposible. En
él intervienen el usuario y el analista.
Análisis: Es la fase de diseño externo. Consiste en cuestionar al usuario sobre
qué hace el sistema, qué características extras él quiere en su nuevo sistema y
qué restricciones debe satisfacer. La salida del análisis debe incluir una
especificación funcional y un análisis estructurado que contiene los
requerimientos para el nuevo sistema, los cuales el usuario debe leer, analizar
y señalar lo que él quiere.
Diseño: Es la fase de diseño interno. Consiste en definir cómo organizar lo
anterior de forma adecuada para la ejecución. Incluye la realización de
diagramas de estructura, explicaciones del programa, etc. (diseño
preliminar). Posteriormente se lleva a cabo un diseño detallado donde se
describen las especificaciones de los módulos.
Implementación: Es la fase de programación o escritura del código. Lo que se
produce en el diseño se lleva a código.
Prueba: En esta etapa se planea el diseño de casos de prueba con el fin
de "asegurar" la co-rectitud de los programas.
Modelos de caso de uso
Un caso de uso es una secuencia de interacciones que se desarrollarán
entre un sistema y sus actores en respuesta a un evento que inicia un actor
principal sobre el propio sistema.
Relación: es una conexión entre los elementos del modelo, por ejemplo la
especialización y la generalización son relaciones
Actor: es toda entidad externa al sistema que guarda una relación con este
y que le demanda una funcionalidad. Esto incluye a los operadores
humanos pero también incluye a todos los sistemas externos así como a
entidades abstractas como el tiempo.
Tipos de relaciones
Comunica (<<communicates>>): Asociación entre un actor y un caso de
uso que denota la participación del actor en dicho caso de uso.
usa (<<uses>>) (o<<include>> en la nueva versión de UML): Relación de
dependencia entre dos casos de uso que denota la inclusión del
comportamiento de un escenario en otro.
extiende (<< extends>>): Relación de dependencia entre dos casos de uso
que denota que un caso de uso es una especialización de otro. Por ejemplo,
podría tenerse un caso de uso que extienda la forma de pedir azúcar, para
que permita escoger el tipo de azúcar (normal, dietético o moreno) y
además la cantidad en las unidades adecuadas (cucharadas o bolsas).
“El modelo de casos de uso es la combinación de casos de uso y sus
correspondientes diagramas.”
Pasos para la Definición de un Caso de Uso:
ID
NOMBRE
REFERENCIAS CRUZADAS
CREADO POR
ULTIMA ACTUALIZACION POR
FECHA DE CREACION
FECHA DE ULTIMA ACTUALIZACION
ACTORES
DESCRIPCION
TRIGGER
PRE-CONDICION
POST-CONDICION
FLUJO NORMAL
FLUJOS ALTERNATIVOS
INCLUDES
FRECUENCIA DE USO
REGLAS DE NEGOCIO
REQUERIMIENTOS ESPECIALES
NOTAS Y ASUNTOS
Normas de aplicación
Los casos de uso pretenden ser herramientas simples para describir el
comportamiento del software o de los sistemas. Un caso del uso contiene una
descripción textual de todas las maneras que los actores previstos podrían
trabajar con el software o el sistema. Los casos del uso no describen ninguna
funcionalidad interna (oculta al exterior) del sistema, ni explican cómo se
implementará. Simplemente muestran los pasos que el actor sigue para realizar
una tarea.
Un caso de uso debe:
describir una tarea del negocio que sirva a una meta de negocio
tener un nivel apropiado del detalle
ser bastante sencillo como que un desarrollador lo elabore en un único
lanzamiento
Situaciones que pueden darse:
Un actor se comunica con un caso de uso (si se trata de un actor primario la
comunicación la iniciará el actor, en cambio si es secundario, el sistema será el
que inicie la comunicación).
Un caso de uso extiende otro caso de uso

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (6)

Funciones
FuncionesFunciones
Funciones
 
Estructuras de control
Estructuras de controlEstructuras de control
Estructuras de control
 
Elementos
ElementosElementos
Elementos
 
Arrays
ArraysArrays
Arrays
 
Estructuras en C
Estructuras en CEstructuras en C
Estructuras en C
 
Sentencias de control
Sentencias de controlSentencias de control
Sentencias de control
 

Ähnlich wie Estudio de Factibilidad

Clase Once DiseñO De Sistemas 2009
Clase Once DiseñO De Sistemas 2009Clase Once DiseñO De Sistemas 2009
Clase Once DiseñO De Sistemas 2009infosistemasuno
 
Metodologías De Diseño Y Desarrollo De Sistemas De Información
Metodologías De Diseño Y Desarrollo De Sistemas De InformaciónMetodologías De Diseño Y Desarrollo De Sistemas De Información
Metodologías De Diseño Y Desarrollo De Sistemas De Informaciónjorgeluisguzmntorres1
 
Ciclo de aplicaciones
Ciclo de aplicacionesCiclo de aplicaciones
Ciclo de aplicacionesJenny Ramos
 
Sistemas Unidad IV
Sistemas Unidad IVSistemas Unidad IV
Sistemas Unidad IVCasssandraG
 
Metodologías para el Diseño de Sistemas
Metodologías para el Diseño de SistemasMetodologías para el Diseño de Sistemas
Metodologías para el Diseño de SistemasIsidro Gonzalez
 
Ciclo de vida de un proyecto informatíco
Ciclo de vida de un proyecto informatícoCiclo de vida de un proyecto informatíco
Ciclo de vida de un proyecto informatícoKatherineSanchezAsanza
 
Presentacion de sistemas
Presentacion de sistemasPresentacion de sistemas
Presentacion de sistemascarloschavezsdi
 
Ciclo de Vida
Ciclo de VidaCiclo de Vida
Ciclo de VidaR.M. M.H.
 
Presentacion de sistemas
Presentacion de sistemasPresentacion de sistemas
Presentacion de sistemascarloschavezsdi
 
Ciclo de Vida y Diseño de Sistemas de Informacion
Ciclo de Vida y Diseño de Sistemas de InformacionCiclo de Vida y Diseño de Sistemas de Informacion
Ciclo de Vida y Diseño de Sistemas de InformacionJonathanCarrillo46
 
Sistemas De Informacion IV
Sistemas De Informacion IVSistemas De Informacion IV
Sistemas De Informacion IVnattalia_3
 
Sistemas de Informacion
Sistemas de InformacionSistemas de Informacion
Sistemas de InformacionCasssandraG
 
Unidad III Sistemas de Informacion
Unidad III Sistemas de InformacionUnidad III Sistemas de Informacion
Unidad III Sistemas de InformacionCasssandraG
 
Análisis del sistema de información
Análisis del sistema de informaciónAnálisis del sistema de información
Análisis del sistema de informaciónalmayor
 
Metodologías para el desarrollo de sistemas
Metodologías para el desarrollo de sistemasMetodologías para el desarrollo de sistemas
Metodologías para el desarrollo de sistemasUNEFA
 
Sistemas de Informacion Unidad 4
Sistemas de Informacion Unidad 4Sistemas de Informacion Unidad 4
Sistemas de Informacion Unidad 4CasssandraG
 

Ähnlich wie Estudio de Factibilidad (20)

El estudio de factibilidad
El estudio de factibilidadEl estudio de factibilidad
El estudio de factibilidad
 
Clase Once DiseñO De Sistemas 2009
Clase Once DiseñO De Sistemas 2009Clase Once DiseñO De Sistemas 2009
Clase Once DiseñO De Sistemas 2009
 
SSADM Material de apoyo
 SSADM Material de apoyo SSADM Material de apoyo
SSADM Material de apoyo
 
Metodologías De Diseño Y Desarrollo De Sistemas De Información
Metodologías De Diseño Y Desarrollo De Sistemas De InformaciónMetodologías De Diseño Y Desarrollo De Sistemas De Información
Metodologías De Diseño Y Desarrollo De Sistemas De Información
 
Ciclo de aplicaciones
Ciclo de aplicacionesCiclo de aplicaciones
Ciclo de aplicaciones
 
Sistemas Unidad IV
Sistemas Unidad IVSistemas Unidad IV
Sistemas Unidad IV
 
Metodologías para el Diseño de Sistemas
Metodologías para el Diseño de SistemasMetodologías para el Diseño de Sistemas
Metodologías para el Diseño de Sistemas
 
Ciclo de vida de un proyecto informatíco
Ciclo de vida de un proyecto informatícoCiclo de vida de un proyecto informatíco
Ciclo de vida de un proyecto informatíco
 
Presentacion de sistemas
Presentacion de sistemasPresentacion de sistemas
Presentacion de sistemas
 
Ciclo de Vida
Ciclo de VidaCiclo de Vida
Ciclo de Vida
 
Sistemas
SistemasSistemas
Sistemas
 
Presentacion de sistemas
Presentacion de sistemasPresentacion de sistemas
Presentacion de sistemas
 
Ciclo de Vida y Diseño de Sistemas de Informacion
Ciclo de Vida y Diseño de Sistemas de InformacionCiclo de Vida y Diseño de Sistemas de Informacion
Ciclo de Vida y Diseño de Sistemas de Informacion
 
Sistemas De Informacion IV
Sistemas De Informacion IVSistemas De Informacion IV
Sistemas De Informacion IV
 
Sistemas de Informacion
Sistemas de InformacionSistemas de Informacion
Sistemas de Informacion
 
Unidad III Sistemas de Informacion
Unidad III Sistemas de InformacionUnidad III Sistemas de Informacion
Unidad III Sistemas de Informacion
 
Análisis del sistema de información
Análisis del sistema de informaciónAnálisis del sistema de información
Análisis del sistema de información
 
Metodologías para el desarrollo de sistemas
Metodologías para el desarrollo de sistemasMetodologías para el desarrollo de sistemas
Metodologías para el desarrollo de sistemas
 
Sistemas de Informacion Unidad 4
Sistemas de Informacion Unidad 4Sistemas de Informacion Unidad 4
Sistemas de Informacion Unidad 4
 
Ciclo de vida
Ciclo de vidaCiclo de vida
Ciclo de vida
 

Estudio de Factibilidad

  • 1. Instituto Universitario de Tecnología “Antonio José de Sucre” Estudio De Factibilidad. 24/07/2013 Alberlis Vasquez 24.159.956 José Tua 20.017.686
  • 2. Introducción En la siguiente presentación de dará a conocer los casos de Estudio de Factibilidad, su diseño, sus métodos, pasos, el Ciclo de Vida de lo Sistemas de Información, el Estudio de Factibilidad en los Sistemas de Información, entre otras cosas que verán mas adelante en la presentación realizada.
  • 3. Estudio de Factibilidad Un estudio de factibilidad es una versión comprimida del proceso total de análisis y diseño del sistema. El estudio comienza clarificando la definición del problema. Se confirma o se corrige la definición inicial de alcances y objetivos, y se identifica cualquier restricción impuesta sobre el sistema. Al menos se pueden considerar tres tipos diferentes de factibilidad: Técnica: ¿Puede implementarse el sistema usando la tecnología actual? Económica: ¿Los beneficios superan los costos? Operacional u organizacional: ¿Puede implementarse el sistema en esta organización? Para cada solución factible, el analista prepara una planificación preliminar de la implementaron, luego de esto se le presenta al gerente y seguidamente al usuario. Pasos para el estudio típico de Factibilidad. Definir los alcances y objetivos del sistema. Se requerirá realizar entrevistas con personal clave y alguna revisión del material escrito. Esencialmente, el analista intenta responder una pregunta muy simple: ¿Estoy trabajando en el problema correcto?. Se requerirá realizar entrevistas con personal clave y alguna revisión del material escrito. Esencialmente, el analista intenta responder una pregunta muy simple: ¿Estoy trabajando en el problema correcto?. Estudio del sistema existente Esto se da obviamente, si un sistema se usa, debe estar realizando algún trabajo útil, y sus funciones básicas deben incorporarse al nuevo sistema. Por otro lado no de tendría que modificar nada si el programa o el sistema existente esta en un buen estado y aun funciona como debe de funcionar. Por consiguiente tenemos que analizar cuidadosamente los procedimiento y la información escrita. Aprendamos que hace el sistema y el porque lo hace de esa manera.
  • 4. Desarrolle un modelo lógico de alto nivel del sistema propuesto. En este momento, el analista debe tener un buen sentido de las funciones y restricciones del sistema nuevo. Un modelo lógico del sistema nuevo puede construirse usando un diagrama de flujo de datos y tal vez un diccionario de datos Redefinir el problema a la luz de los nuevos conocimientos. En este paso o fase el analista debe tener la definición del problema, el alcance y los objetivos con el personal clave para esto. Si el analista no ha entendido y el usuario tampoco o a pasa por alto algunas cosas, ahora es el momento de solucionarlo . El analista define el problema, lo analiza, desarrolla una solución tentativa, redefine el problema, lo reanaliza, revisa la solución, y continúa este proceso cíclico hasta que el modelo lógico reúne los objetivos del sistema. “Piense a los primeros cuatro pasos del estudio de factibilidad como un todo.” Desarrollar y evaluar soluciones alternativas. Dado un modelo lógico del sistema propuesto, el analista puede comenzar a generar alternativas de soluciones físicas de alto nivel. El estudio de Factibilidad de los S.I. Diseños de Sistemas de Información. A partir de este paso el analista y el diseñador del sistema en conjunto con el usuario, deben de encontrar una solución que conviertan los requisitos encontrado en la fase de análisis de sistema en un sistema real. El análisis de sistema se centraba en lo que se debe hacer, es decir, en los requisitos del sistema desde el punto de vista de los usuarios, mientras que el diseño se enfoca en lo que se tiene que realizar. Por lo tanto en la etapa de diseño se debe de investigar que datos se usaran y como se alcanzaran.
  • 5. Inicio de un Nuevo Sistema Planificacion de Sistemas Analisis del Sistema aCTUAL Analisis de Requisitos Diseño Logico Diseño Fisico Implementacion
  • 6. Para el alcance de estos objetivos, la etapa de diseño esta comprendida por 2 fases. Diseño lógico del nuevo sistema. Diseño físico del nuevo sistema. Diseño lógico del nuevo sistema. Es la fase donde se debe de enlazar o llevar a cabo lo que el usuario desea, y de esta manera levarlo al la fase 2 que seria llevar el sistema a lo físico, es decir, a lo que se llamaría sistema funcional. Diseño físico del nuevo sistema. Es donde el diseño lógico se pone en marcha donde se le harán correcciones necesarias para que el usuario pueda disfrutar del sistema correctamente. Relación entre los sistemas. Modelo Lógico Modelo Físico Modelo de Datos Representación de la estructura y la relación de los datos esenciales Representación de las estructura y las relaciones de los datos para la implementación del diseño lógico Modelo de Procesos Representación de los procesos y los flujos de datos esenciales Representación de los flujos de los datos para implementar el modelo lógico de los datos del proceso.
  • 7. Ciclo de vida de un sistema informático Estudio de Factibilidad Análisis de Requerimiento Diseños Creación de PROTOTIPOS Implementación Validación y Prueba Operación y Mantenimiento
  • 8. Es el tiempo que vive un sistema desde el momento en que es pensado hasta que muere o no es útil Las actividades típicas del ciclo de vida son:  Reconocimiento del problema  Estudio de factibilidad  Análisis  Diseño  Implementación (Codificación)  Prueba  Mantenimiento Reconocimiento del problema: Surge cuando el usuario reconoce que tiene problemas con los medios con que cuenta actualmente para llevar a cabo su trabajo. Así comienza esta fase que trata de reemplazar el sistema existente por otro. En esta fase interviene totalmente el usuario. Estudio de la factibilidad: Se decide si el usuario necesita o no una computadora. Este estudio sirve para: - Identificar los problemas con el sistema actual. - Identificar el alcance del sistema a ser estudiado. -Identificar los principales objetivos del nuevo sistema. - Identificar un número de soluciones que pueden satisfacer las necesidades del usuario dentro de su esquema. - Desarrollar estimados de los beneficios y desventajas de cada solución. - Desarrollar esquemas de cómo puede llevarse a cabo el proyecto teniendo una idea de los recursos que se requieren. -Obtener puntos de vista del usuario y el administrador sobre las Modificaciones. - Obtener una decisión de si se lleva a cabo la parte de análisis. Todo este estudio evitará el gasto de un análisis de un proyecto imposible. En él intervienen el usuario y el analista. Análisis: Es la fase de diseño externo. Consiste en cuestionar al usuario sobre qué hace el sistema, qué características extras él quiere en su nuevo sistema y qué restricciones debe satisfacer. La salida del análisis debe incluir una especificación funcional y un análisis estructurado que contiene los requerimientos para el nuevo sistema, los cuales el usuario debe leer, analizar y señalar lo que él quiere. Diseño: Es la fase de diseño interno. Consiste en definir cómo organizar lo anterior de forma adecuada para la ejecución. Incluye la realización de
  • 9. diagramas de estructura, explicaciones del programa, etc. (diseño preliminar). Posteriormente se lleva a cabo un diseño detallado donde se describen las especificaciones de los módulos. Implementación: Es la fase de programación o escritura del código. Lo que se produce en el diseño se lleva a código. Prueba: En esta etapa se planea el diseño de casos de prueba con el fin de "asegurar" la co-rectitud de los programas. Modelos de caso de uso Un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Relación: es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones Actor: es toda entidad externa al sistema que guarda una relación con este y que le demanda una funcionalidad. Esto incluye a los operadores humanos pero también incluye a todos los sistemas externos así como a entidades abstractas como el tiempo. Tipos de relaciones Comunica (<<communicates>>): Asociación entre un actor y un caso de uso que denota la participación del actor en dicho caso de uso. usa (<<uses>>) (o<<include>> en la nueva versión de UML): Relación de dependencia entre dos casos de uso que denota la inclusión del comportamiento de un escenario en otro. extiende (<< extends>>): Relación de dependencia entre dos casos de uso que denota que un caso de uso es una especialización de otro. Por ejemplo, podría tenerse un caso de uso que extienda la forma de pedir azúcar, para que permita escoger el tipo de azúcar (normal, dietético o moreno) y además la cantidad en las unidades adecuadas (cucharadas o bolsas). “El modelo de casos de uso es la combinación de casos de uso y sus correspondientes diagramas.”
  • 10. Pasos para la Definición de un Caso de Uso: ID NOMBRE REFERENCIAS CRUZADAS CREADO POR ULTIMA ACTUALIZACION POR FECHA DE CREACION FECHA DE ULTIMA ACTUALIZACION ACTORES DESCRIPCION TRIGGER PRE-CONDICION POST-CONDICION FLUJO NORMAL FLUJOS ALTERNATIVOS INCLUDES FRECUENCIA DE USO REGLAS DE NEGOCIO REQUERIMIENTOS ESPECIALES NOTAS Y ASUNTOS Normas de aplicación Los casos de uso pretenden ser herramientas simples para describir el comportamiento del software o de los sistemas. Un caso del uso contiene una descripción textual de todas las maneras que los actores previstos podrían trabajar con el software o el sistema. Los casos del uso no describen ninguna funcionalidad interna (oculta al exterior) del sistema, ni explican cómo se implementará. Simplemente muestran los pasos que el actor sigue para realizar una tarea. Un caso de uso debe: describir una tarea del negocio que sirva a una meta de negocio tener un nivel apropiado del detalle ser bastante sencillo como que un desarrollador lo elabore en un único lanzamiento Situaciones que pueden darse: Un actor se comunica con un caso de uso (si se trata de un actor primario la comunicación la iniciará el actor, en cambio si es secundario, el sistema será el que inicie la comunicación). Un caso de uso extiende otro caso de uso