Modelado de Negocios
8
4.5 Modelo de negocios La razón para construir un modelo de negocios es, primero, que proporcione una comprensión de los negocios del cliente como un todo. Para construir un modelo de negocios un analista de sistemas debe comprender con todo detalle los diversos procesos de negocios. Por ejemplo, los procesos de negocios de una empresa de servicios de banquetes incluyen comprar los ingredientes, preparar os alimentos y servir la comida. Estos procesos ahora están refinados, es decir, analizados con gran detalle, Por ejemplo pueden utilizarse una serie de técnicas diferentes para obtener la información necesaria para construir el modelo de negocios. Modelado de Negocios Es particularmente utilizar la terminología correcta cuando se comunique con el cliente y con los usuarios potenciales en información. Después de todo, es difícil ser tomado en serio por alguien que trabaja en un dominio específico a menos que el analista de 4.3 Comprensión del dominio sistemas utilice el mismo vocabulario. Aún más importante, el uso de una palabra inapropiada puede conducir a una mala interpretación, provocando que al final se entregue un sistema de información con fallas 4.3 Comprensión del dominio La primera tarea de cada miembro del equipo de requisitos es familiarizarse con el dominio de aplicaciones, a menos que él o ella ya tengan experiencias en esta tarea
description
Resumen Modelado de negocios Camilo Eusebio Rogelio 6751
Transcript of Modelado de Negocios
4.5 Modelo de negocios
La razón para construir un modelo de negocios es, primero, que proporcione una comprensión de los negocios del cliente como un todo.
Para construir un modelo de negocios un analista de sistemas debe comprender con todo detalle los diversos procesos de negocios.
Por ejemplo, los procesos de negocios de una empresa de servicios de banquetes incluyen comprar los ingredientes, preparar os alimentos y servir la comida.
Estos procesos ahora están refinados, es decir, analizados con gran detalle, Por ejemplo pueden utilizarse una serie de técnicas diferentes para obtener la información necesaria para construir el modelo de negocios.
Modelado de Negocios
Es particularmente utilizar la terminología correcta cuando se comunique con el cliente y con los usuarios potenciales en información. Después de todo, es difícil ser tomado en serio por alguien que trabaja en un dominio específico a menos que el analista de
4.3 Comprensión del dominio
sistemas utilice el mismo vocabulario. Aún más importante, el uso de una palabra inapropiada puede conducir a una mala interpretación, provocando que al final se entregue un sistema de información con fallas
4.3 Comprensión del dominio La primera tarea de cada miembro del equipo de requisitos es familiarizarse con el dominio de aplicaciones, a menos que él o ella ya tengan experiencias en esta tarea
4.5 Entrevistas
4.5 Entrevistas
Leyenda que describe una imagen o un gráfico.
Una vez concluida la entrevista, el entrevistador debe preparar un informe por escrito que resuma los resultados. Se recomienda ampliamente dar una copia del informe a la persona que se entrevistó. Realizar una entrevista no es fácil. Primero, el entrevistador debe estar completamente familiarizado con el terreno de las aplicaciones.
Asimismo hay dos tipos básicos de entrevistas, a saber, estructuradas y ni estructuradas. En las primeras se plantean preguntas preplaneadas, con frecuencia cerradas. En las segundas el entrevistador puede iniciar con una o dos preguntas cerradas preparadas, pero las preguntas subsiguientes se plantean basándose en las respuestas que proporciona la persona a quien se está entrevistando.
Es probable que muchas de las preguntas subsiguientes sean de naturaleza abierta con el fin de proporcionar al entrevistador información variada.
Una vez concluida la entrevista, el entrevistador debe preparar un informe por escrito que resuma los resultados. Se recomienda ampliamente dar una copia del informe a la persona que se entrevistó.
4.5 Entrevistas
4.5.2 Otras técnicas
Una manera diferente de obtener los requisitos es examinar los diversos formularios utilizados por el negocio. Por ejemplo, un formulario de una imprenta podría reflejar el número de prensa, el tamaño de rollo de papel y así por el estilo.
Los distintos campos de este formulario proporcionan datos sobre flujo de los trabajos de impresión y la importancia relativa de los pasos en el proceso de impresión.
Otros documentos, como los procedimientos operativos y las descripciones del trabajo, también pueden se herramientas poderosas para saber de una manera exacta que se está haciendo bien y como.
4.5.2 Otras técnicas
4.5.2 Otras técnicas
Leyenda que describe una imagen o un gráfico.
Esta información global respecto de cómo se hacen los negocios en la actualidad puede ser muy útil para determinar las necesidades del cliente. Otra manera de obtener esta información es la observación directa de los usuarios; es decir, los miembros del equipo de requisitos que observan y anotan las acciones de los empleados mientras llevan a cabo sus tareas.
Una versión moderna de esta técnica es instalar cámaras de video dentro de las áreas de trabajo áreas de trabajo para registrar exactamente que se está haciendo.
4.7 Requisitos iniciales
Los requisitos son dinámicos es decir hay cambios frecuentes no sólo en ellos, sino también en las actitudes de los miembros del equipo de requisitos, los clientes y los futuros usuarios con respecto a cada requisito
Después de un análisis posterior, tal requisito puede parecer de fundamental importancia. Sin embargo
después de la conversación del cliente se rechaza el mismo.
Los requisitos funcionales se manejan cuando los workflows de los requisitos y del análisis se están realizando, mientras que algunos requisitos no funcionales pueden tener que esperar hasta el workflog diseño.
Modelado de Negocios
Por lo común es fácil identificar a un actor.
Un actor con frecuencia es u usuario del sistema de información.
En el caso de un sistema de información bancario, los usuarios del sistema son los clientes y el personal del banco,
4.5.3 Casos de uso
incluidos los cajeros, administradores etc. En general un actor desempeña un papel al sistema. Este papel puede ser como usuario del mismo. Sin embargo, un iniciador de un caso de uso o alguien que tiene una función crítica en un caso de uso también desempeña un papel y por lo tanto es visto como un actor sin importar si es o no usuario del sistema de información.
.
4.5.3 Casos de uso Un caso de uso hace un modelo e interacción entre el sistema de información y los usuarios de este.
4.7 Requisitos iniciales
4.7 Requisitos iniciales
Leyenda que describe una imagen o un gráfico.
Los requisitos iniciales se clasifican en funcionales y no funcionales
Un requisito funcional es aquel que específica una acción que el sistema de información debe de ser capaz de realizar.
Los requisitos funcionales se expresan con frecuencia en términos de entrada y salida
Un requisito no funcional específica las propiedades del sistema de información mismo, como las restricciones de plataforma, los tiempos de respuesta o la fiabilidad. Los requisitos funcionales se manejan cuando los workflows de los requisitos y análisis se están realizando.
.
4.8 Requisitos iniciales caso práctico Osbert Oglesby
El paso siguiente es decidir cuál de estos eventos de uso son también requisitos del sistema de información computarizado que se va a construir. Entonces se refina la lista de requisitos iniciales resultantes, sumando, modificando y eliminando, hasta que tanto Osbert y el equipo de requisitos estén satisfechos.
4.9 Continuación del Workflow
Al examinar la documentación relevante, concretamente los registros manuales actuales de Osbert se aprende que Osbert necesitará registrar datos
Explorar los requisitos de subastas en todo el mundo de los 25 años pasados para la obra más parecida hecha por el mismo, ignorando cualquier signo de interrogación en el nombre o el apellido.
Si el coeficiente de parecido entre el cuadro de consideración y todos los cuadros en el archivo de datos de la subasta es sero, entonces osbert no comprará esa obra
4.9 Continuación del Workflow
Leyenda que describe una imagen o un gráfico.
La salida de orden debe ser la siguiente:
Fecha de compra
Apellido del artista
Titulo
Precio de compra
Precio de compra real
