El Esquema Metodologico

Proceso de investigación para tesis en ingeniería

César Luza Montero

Lección 1 El esquema metodológico 1.1

¿Qué es el esquema metodológico?

El esquema metodológico está conformado por la descripción de las actividades (conceptuales, (conceptuales, metodológicas, o algorítmicas) que el investigador realizará para resolver el problema en estudio. Puede considerarse, también, como una fase del proceso de investigación para la elaboración de la tesis en ingeniería. Durante esta fase, el investigador determina, describe y aplica, con claridad, la herramienta tecnológica (método, algoritmo, modelo, esquema, diseño, plan, etc.) que usará para construir la solución (software, sistema, infraestructura tecnológica, tecnológica, etc.) al problema de investigación investigación planteado en la tesis. 1.2

¿Cómo elaborar el esquema metodológico?

Para elaborar el esquema metodológico es preciso realizar las siguientes actividades: Selección de la(s) herramienta(s) tecnológica(s), adaptación de la(s) herramienta(s) tecnológica(s), y aplicación de la(s) herramienta(s) tecnológica(s) al problema. a) Selección de la(s) herramienta(s) tecnológica(s) En esta actividad, se evalúa las diversas alternativas de herramientas tecnológicas existentes, las cuales han sido revisadas en la fase del “Revisión de literatura”,

para elegir la más adecuada para la solución del problema planteado. Si el informe del “Revisión de literatura” consigna una evaluación comparativa de las diversas herramientas tecnológicas, entonces, será considerada como entrada para la selección de la herramienta. La evaluación de las herramientas tecnológicas permite justificar la selección de aquella que será utilizada para construir la solución al problema. Dependiendo de las características del problema y de la solución, la herramienta tecnológica será un algoritmo, un modelo, un método, etc. Ejemplos:




César Luza Montero

Tema de Tesis: “Algoritmos GRASP para el problema de Cortes 2D No Guillotinable”. La herramienta para este problema está dada por los algoritmos

que existen para resolverlo. Entre los algoritmos que existen para el problema de cortes se tienen: algoritmos genéticos, algoritmo FFD, algoritmos BFD, algoritmo GRASP, etc. 

Tema de Tesis: “Un Sistema de Información Gerencial para PYMES Textiles”. La

herramienta para este problema será dada por los métodos que existen para el desarrollo de un sistema de información, y en particular si fuera posible para un sistema de información gerencial. 

Tema de Tesis: “Predic ción de lluvias para la provincia de Urubamba usando Redes Neuronales Artificiales”. La herramienta para este problema será dada

por los métodos que existen para la predicción de lluvias, entre ellas se encuentran los métodos estadísticos de predicción, las redes neuronales artificiales (en particular la red Perceptron multicapa), etc. b) Adaptación de la(s) la(s) herramienta(s) herramienta(s) tecnológica(s) En esta actividad se describe la(s) herramienta(s) herramienta(s) tecnológica(s) seleccionada(s). Si la solución a construir requiere adaptar la herramienta tecnológica, entonces, se describe la adaptación de la misma, indicando con claridad los elementos de la herramienta necesarios para la solución. Si la solución no requiere adaptar la herramienta, entonces, la misma se describe en forma directa, pero si ésta fue descrita en el informe del “estado del arte”, ya no es necesaria describirla describirla aquí.

c) Aplicación de la(s) herramienta(s) herramienta(s) tecnológica(s) al problema En esta actividad se realiza la aplicación de la herramienta tecnológica seleccionada y adaptada para resolver el problema en estudio. Si la herramienta seleccionada es un algoritmo, entonces, se realiza el algoritmo adaptado para resolver el problema en estudio. Si la herramienta seleccionada es un método, entonces, se realiza la aplicación del método para resolver el problema. Para el caso de problemas que corresponden al desarrollo de un sistema de información, se realiza el análisis,


César Luza Montero

diseño, modelo de bases de datos, etc., según la secuencia de la metodología seleccionada. 1.3

El informe del esquema metodológico

Los resultados del proceso de elaboración del esquema metodológico deben consignarse en un informe, en la cual el candidato al título profesional de ingeniero de sistemas y cómputo debe describir la propuesta de solución al problema en estudio. La redacción del informe de aporte teórico corresponde, por lo general, a uno o dos capítulos del informe final de la tesis. La estructura del informe depende del aporte teórico realizado, ésta debe incluir en lo posible: a) Nombre de las herramientas que se pueden aplicar para resolver el problema. b) Definición y justificación de los criterios a usar para evaluar las herramientas (en la literatura especializada es usual presentar comparaciones de herramientas). c) Cuadro comparativo donde se presentan las herramientas y los criterios, el mismo que deberá ser comentado de manera clara. d) Definición de elementos de la herramienta seleccionada. Por ejemplo, si el tema de tesis es “Algoritmos GRASP para el problema de Cortes 2D No Guillotinable” y la

herramienta seleccionada es el algoritmo GRASP, entonces, la definición de elementos que requiere el algoritmos GRASP son: rotación (hay o no rotación del cuerpo a cortar), tamaño de la lámina, tamaño de los requerimientos, demandas, etc. Si el tema de Tesis es “Predicción de lluvias para la provincia de Urubamba usando Redes Neuronales Artificiales”, y la herramienta seleccionada es la red Perceptron multicapa, entonces, la definición de elementos que requiere la red Perceptron multicapa: variables de entrada, variables de salida, número de capas, número de nodos por capas, etc. e) Descripción de la adaptación de la herramienta seleccionada. Por ejemplo, si la herramienta es un algoritmo, entonces, se deberá presentar el algoritmo adaptado para resolver el problema en estudio. Si la herramienta seleccionada es un método, entonces, se deberá presentar el método adaptado para resolver el problema.


César Luza Montero

f) Descripción de la aplicación de la herramienta al problema. Por ejemplo, si herramienta seleccionada para resolver el problema en estudio corresponde al desarrollo de un sistema de información se presenta el resultado del análisis, diseño, modelo de bases de datos, etc., según secuencia de la metodología seleccionada. 1.4

Criterios para validar el esquema metodológico

El informe del aporte teórico debe cumplir los siguientes aspectos: 

¿Los nombres de las herramientas tecnológicas están consignadas?



¿Se ha justificado la elección de la herramienta tecnológica?



¿Se ha descrito y definido los elementos básicos de la herramienta tecnológica?







¿Se ha realizado la adaptación de la herramienta tecnológica al problema en estudio ¿Se ha realizado la aplicación de la herramienta tecnológica adaptada para la construcción de la solución al problema en estudio? ¿Se han citado adecuadamente a las referencias bibliográficas utilizadas?


César Luza Montero

Lección 2 Ejemplo de esquema metodológico Consideremos la tesis para obtener el título profesional de ingeniero de sistemas y cómputo titulado: “Software de Gestión de Incidencias en la Atención a Clientes de la Empresa ABC”.

2.1

Selección de la herramienta tecnológica

En la fase de “estado del arte” se han determinado los siguientes métodos para el

desarrollo de software: 







RUP (Rational Unified Process), XP (eXtreme Programming), FDD (Feature Driven Development) y AUP (Agile Unified Process).

Los criterios de comparación establecidos son: a) Experiencia del equipo. Se refiere a la experiencia profesional del personal asignado al proyecto de la empresa ABC en relación a los métodos disponibles. b) Carga de Trabajo. Es la responsabilidad que asignada a los miembros del equipo y que representa el esfuerzo a realizar. c) Documentación. Se refiere a información tangible y persistente que ayude en todo el ciclo de vida del desarrollo del sistema para poder monitorear los procesos ya terminados. d) Manejo de riesgos. Se refiere a la efectividad de control y reacción del equipo ante problemas que se presenta durante el ciclo. e) Relación con el cliente. Es la relación que posee el cliente con el desarrollo del software, quiere decir el monitoreo y revisión propia del cliente con los procesos ya finalizados durante el ciclo de vida del producto.


César Luza Montero

f) Duración. Tiempo estimado del proyecto a realizar. Los valores y puntajes para cada criterio son:

CRITERIO

VALOR

DESCRIPCIÓN

PUNTAJE

Alto

Equipo con gran experiencia en el método

4

Bajo

Poca experiencia del equipo

2

Alto

Máxima carga de trabajo (propenso a errores)

1

Bajo

Mínima carga de trabajo

3

Mucho

Documentación completa

2

Mínima documentación

1

Moderado Documentación parcial

3

Experiencia del equipo

Carga de Trabajo

Documentación

Poco

Mayor

Buen manejo de riesgos

5

Menor

Manejo de riesgos parcial

3

Mayor

Buena relación con el cliente (entregables)

4

Menor

Relación con el cliente es parcial

2

Mayor

Puede extender el plazo

1

Menor

Permite terminar en el plazo

3

Manejo de riesgos

Relación con el cliente

Duración

El cuadro comparativo elaborado es: Criterio /Metodología

RUP

XP

FDD

AUP


César Luza Montero

Experiencia del equipo

Bajo

Alto

Alto

Alto

Carga Trabajo Criteriode/Metodología

Bajo RUP

Alto XP

Alto FDD

Moderado AUP

Documentación Experiencia del equipo

Mucha 2

Poca 4

Poca 4

Moderado 4

Manejo de riesgos Carga de Trabajo

Mayor 3

Moderado 1

Menor 1

Mayor 2

Moderado 2

Mayor 1

Mayor 1

Moderado 3

Relación con el cliente Documentación Duración Manejo de riesgos

Mayor

5

Menor 4

Menor 3

Medio 5

Relación con el cliente

3

4

4

3

Duración

1

3

3

2

Total

16

17

16

19

De acuer do con los cuadr os prese ntado s, se conclu ye

que el método a usar es AUP (Agile Unified Proccess). 2.2

Descripción de la herramienta: AUP

El AUP es una versión simplificada del Rational Unified Process (RUP). Es un método sencillo, fácil de entender para el desarrollo de software de aplicaciones empresariales. Utiliza técnicas ágiles como: Test Driven Development (TDD), Agil Model Driven Development (AMDD), gestión del cambio ágil, y refactorización de base de datos para mejorar su productividad1.

1

http://cgi.una.ac.cr/AUP/index.html Última visita: 28/11/2011


César Luza Montero

El ciclo de vida de AUP es secuencial, en las fases, e iterativo, en las disciplinas, liberando entregables incrementales en el tiempo, como se ve en la figura 2.1.

Figura 2.1 Ciclo de Vida de AUP

2.2.1

Disciplinas de AUP

Las disciplinas definen las actividades que el equipo de desarrollo ejecuta para construir, validar y liberar el software funcional, el cual cumple con las necesidades de los involucrados. Las disciplinas, se ejecutan en forma iterativa, son las siguientes: a) Modelado

La meta de esta disciplina es entender y modelar el negocio (la organización), el dominio del problema que el proyecto aborda e identificar una solución viable para el mismo. b) Implementación

La meta de esta disciplina es transformar los(s) modelo(s) elaborados en un código ejecutable y realizar una prueba de nivel básico en una unidad particular de prueba. c) Pruebas

La meta de esta disciplina es ejecutar una evaluación de los objetivos para asegurar la calidad. Incluye encontrar defectos, validar que el sistema funcione como fue diseñado y verificar si los requerimientos están completos. d) Despliegue


César Luza Montero

La meta de esta disciplina es planificar la entrega del sistema y ejecutar el plan para que el sistema esté disponible para los usuarios finales.

e) Administración de la Configuración

La meta de esta disciplina es administrar el acceso a los entregables o productos del proyecto. Esto incluye, no sólo el rastreo de versiones del producto en el tiempo, sino que también, controlar y administrar los cambios que ocurran. f) Administración de Proyecto

La meta de esta disciplina es dirigir las actividades que se llevan a cabo en el proyecto. Esto incluye administración del riesgo, la dirección de personas (asignar tareas, seguimiento de los procesos, etc.), y coordinar con los sistemas y personas fuera del alcance del proyecto para que éste termine a tiempo y dentro del presupuesto. g) Ambiente

La meta de esta disciplina es apoyar el resto de los esfuerzos para garantizar el proceso adecuado, la orientación (normas y directrices) y herramientas (hardware, software, etc.) necesarias estén disponibles para el equipo. 2.2.2

Fases e Hitos de AUP

Las fases agrupan a un conjunto de actividades definidas en cada disciplina. Son realizadas en forma secuencial. Cada una termina en un hito. El Agile UP tiene cuatro fases. a) Inicio Permite identificar el alcance inicial de proyecto, una arquitectura inicial del sistema y obtener un presupuesto inicial del proyecto y una aceptación de los involucrados. Sus hitos son: 1. Acuerdo del Alcance : Los interesados llegan a un acuerdo sobre el alcance del

proyecto.


César Luza Montero

2. Definición Inicial de Requerimientos . Existe un acuerdo en que el conjunto correcto

de requisitos han sido capturados, en un nivel alto, y hay un entendimiento común de esos requisitos. 3. Acuerdo del Plan . Los involucrados llegan a un acuerdo con el costo inicial y la

estimación del cronograma. 4. Aceptación del Riesgo . El riesgo ha sido identificado, evaluado y se han abordado

estrategias aceptables para controlarlos. 5. Aceptación de Proceso . La Metodología de Proceso Unificado Ágil

ha sido

inicialmente adoptado y aceptado por todas las partes. 6.

Viabilidad .

El proyecto tiene sentido desde la perspectiva técnica, operacional y

del negocio. 7. Plan del Proyecto . Existen adecuados planes para la siguiente fase de Elaboración 8. Cumplimiento del Portafolio . ¿El alcance del proyecto encaja bien en su

organización general del portafolio de proyectos? b) Elaboración

El principal objetivo de esta fase es probar la arquitectura del sistema a desarrollar. El punto es asegurar que el equipo puede desarrollar un sistema que satisfaga los requisitos, y la mejor manera de hacerlo es la construcción de extremo a extremo del esqueleto de trabajo del sistema conocido como "prototipo de la arquitectura". Sus hitos son: 9. Estabilidad de la visión. La visión del proyecto ha sido estabilizada y es realista. 10.Estabilidad de la arquitectura. Se e stá de acuerdo en que la arquitectura es

estable y es suficiente para satisfacer los requerimientos. La arquitectura ha sido prototipada apropiadamente para ser direccionada con los riesgos de la arquitectura principal. 11. Aceptación del riesgo. El riesgo ha sido evaluado para asegurar que se ha

entendido apropiadamente, documentado y que se han desarrollado estrategias para manejarlos como aceptable.


César Luza Montero

12.Viabilidad. El proyecto aun tiene sentido desde la perspectiva técnica, operacional

y del negocio. 13.Plan del Proyecto. Plan de iteración detallado para las próximas iteraciones de la

etapa de Construcción, así como un plan de proyecto de alto nivel ya elaborado. ¿La arquitectura del sistema refleja las realidades de la arquitectura de la empresa?.

14.Cumplimiento de la organización.

c) Construcción

El objetivo de la fase de Construcción es desarrollar el sistema hasta el punto en que está listo para la pre-producción de pruebas. En las etapas anteriores, la mayoría de los requisitos han sido identificados y la arquitectura del sistema se ha establecido. El énfasis es priorizar y comprender los requerimientos, el modelado de la solución y, luego, la codificación y las pruebas del software. Si es necesario, las primeras versiones del sistema se desarrollan, ya sea interna o externamente, para obtener los comentarios de los usuarios. Sus hitos son: El software y la documentación de soporte son aceptables (estable y madura) para implementar el sistema a los usuarios.

15.Estabilidad del Sistema.

Los involucrados (y el negocio) están listos para que el sistema sea implementado (aunque aún necesiten entrenamiento).

16.Involucrados preparados.

17. Aceptación del riesgo. El riesgo ha sido evaluado para asegurar que ha sido

apropiadamente entendido, documentado y que se han desarrollado estrategias para manejarlo como aceptable. Los gastos son aceptables y las estimaciones razonables han sido calculadas y programadas para los costos futuros.

18. Aceptación y estimación del costo.

Plan de iteración detallado para las próximas iteraciones de la etapa de Transición, así como un plan de proyecto de alto nivel ya elaborado.

19.Plan del proyecto.

20.Cumplimiento de la organización. ¿El producto elaborado por el equipo cumplen

con los estándares apropiados de la organización?


César Luza Montero

d) Transición

La fase de Transición se enfoca en liberar el sistema a producción. Deben hacerse pruebas extensivas a lo largo de esta fase, incluyendo las pruebas beta. Una buena afinación del proyecto tiene lugar aquí incluyendo el re trabajo dirigido a los defectos significantes (su usuario puede escoger aceptar a existencia de algunos defectos conocidos en la versión actual). Sus hitos son: 21. Aceptación de los involucrados del negocio. Los involucrados del negocio están

satisfechos con el sistema y lo aceptan. 22.Operaciones de aceptación. Las personas se responsabilizan de operar el sistema

una vez que este está en producción y están satisfechos con los procedimientos y documentación relevantes. 23. Aceptación del soporte. Las personas se responsabilizan del soporte del sistema

una vez que este está en producción y están satisfechos con los procedimientos y documentación relevantes. 24. Aceptación del costo estimado. Los gastos actuales son aceptados, y las

estimaciones razonables han sido hechas parar los costos futuros de producción. 2.2.3

Entregables de AUP

El Agile UP distingue entre: 





Entregable que absolutamente se debe producir como un producto permanente de trabajo del sistema. Otros productos de trabajo del proyecto que probablemente descartará porque no se quiere mantenerlos en el tiempo. Productos de trabajo de la organización que son mantenidos dentro de su departamento de TI y compartida a través de proyectos.

Entregables básicos : El mínimo de entregables para un sistema bajo AUP es

descrito, en orden prioritario, en la tabla siguiente: ENTREGABLE

DESCRIPCI N


César Luza Montero

Sistema

El software de trabajo, el hardware y la documentación para ser liberada a producción.

Código fuente

El código de programa para su sistemas

Una colección de casos de prueba, y el código para correrlas en un orden Suite de pruebas adecuado. La suite de pruebas de regresión incluirá un gran rango de pruebas, de regresión tomando en cuenta pruebas de aceptación, unidad de pruebas, pruebas de sistema y muchas otras. Scripts de Código para instalar el sistema en el ambiente de pre-producción. instalación La documentación liberada como una parte del sistema para ayudar al usuario al Documentación trabajar con él, y a los desarrolladores para mantenerlo actualizado. Integra del sistema potencialmente las operaciones, soporte, usuarios, y una documentación general del sistema. Notas

Sus notas deben resumir "las buenas cosas a saber" acerca de las versiones actuales que se están construyendo.

Describe los requisitos que su sistema debe cumplir. Consta de una variedad de productos de trabajo, incluyendo potencialmente pruebas de aceptación, Modelado de oportunidades de automatización, modelos de procesos del negocio, reglas del requerimientos negocio, modelo del dominio, modelo de la organización, glosario del proyecto, requerimientos técnicos, modelo de casos de uso, y el modelo de interface de usuario.

Modelo de diseño

Describe el diseño de su sistema. Consta de una variedad de productos de trabajo, incluye potencialmente un modelo de despliegue, un modelo de objetos, un modelo de datos físico (PDM), un modelo de seguridad de amenazas, un documento de resumen del sistema, y un modelo de interface de usuario

Otros productos de trabajos , listados en orden alfabético, que se puede elegir para

crear o utilizar: ENTREGABLE Pruebas de Aceptación Oportunidades de Automatización Presupuesto Modelado de Procesos del Negocio Especificaciones de las Reglas del Negocio

DESCRIPCIÓN Pruebas de aceptación que describen los requerimientos de caja-negra, identificados por sus usuarios del proyecto, a los cuales su sistema se debe ajustar. Una indicación de actividades manuales en las que potencialmente podrían ser automatizados. Una indicación del monto del presupuesto, cuando será recibido y el criterio (si fuera el caso) que su equipo debe cumplir para recibir el fondo para soportar el esfuerzo del proyecto. Una descripción de las actividades del negocio, la información de flujo a través de ella, y los orígenes y destinos de la información. Una especificación de reglas del negocio captura la colección de reglas del negocio implementadas por el sistema. Una regla del negocio define o limita un aspecto de su negocio que pretende hacer valer la estructura o influencia del comportamiento del negocio. Las reglas del negocio se concentran frecuentemente los problemas de controles de acceso, cálculos del negocio o políticas de su organización.


César Luza Montero

Esquema de Datos

El esquema de sus almacenes de datos. En el caso de las bases de datos relacionales, es descrito por el lenguaje de definición de datos (DDL), para los almacenes de datos XML se usa un esquema de XML o XML DTDs.

Reporte de Defectos

Un tipo de solicitudes de cambio que definen problemas relacionados al sistema; es decir, el sistema no está funcionando de la forma en que tiene que hacerlo.

Modelado de Despliegue Plan de Despliegue

Describe cómo se va a organizar los aspectos de hardware y software del sistema.

Modelado de Dominio

Describe las principales entidades empresariales, las relaciones entre ellas y, potencialmente, sus responsabilidades.

Estimación Estimaciones Individuales

Los costos de proyecto para completar el proyecto.

Modelado de Objetos Operaciones de Documentación

Describe el acercamiento del despliegue del sistema en producción.

Una estimación hecha por un individuo del tiempo y costo para ejecutar la tarea. Describe su esquema de objetos, el código que comprende su software. Frecuentemente comprendido por varias vistas por una estructura estática y los aspectos dinámicos del esquema Captura la información de apoyo y los procedimientos para operar el sistema una vez que estén en producción.

Evaluación de la Organización

Describe la organización (tal vez una división de su empresa) en el que su sistema se desplegará, con una indicación de la capacidad de la organización a adoptar y utilizar el nuevo sistema.

Modelo de la Organización

Indica a las personas que participan en su proyecto y la estructura de información entre ellos. Debe indicar tanto los miembros del equipo del proyecto, como los principales interesados y sus funciones.

Modelo de Datos Físico (PDM)

Describe el esquema físico de un almacén de datos, tales como una base de datos relacional o archivo XML.

Glosario del Proyecto

Describe los términos críticos y técnicos del negocio en su proyecto.

Descripción General del Proyecto

Resume los objetivos, plan, y la misión del proyecto. Potencialmente compuesta de una declaración de las metas del proyecto, estatutos de la visión del proyecto, y una evaluación de la organización. Comprende el plan de iteraciones, el cronograma del proyecto, lista de riesgo, estimación, y presupuesto. Compuesto de financiación, de hardware / software, y las facilidades (como las habitaciones).

Plan del Proyecto Recursos del Proyecto Cronograma del Proyecto Prueba del Concepto Prototipo Registro de Revisión Lista de Riesgos Modelado de Amenazas de Seguridad Documentación de Soporte Documento de la

Indica las actividades, las dependencias entre ellos, y los hitos del proyecto. Código de trabajo que demuestra un enfoque técnico de trabajo. Los resultados, incluidos los puntos de acción, de una revisión. Una lista de los riesgos identificados, y las estrategias de mitigación Un modelo que analiza las amenazas de la seguridad de su sistema. La documentación requerida por el personal de apoyo, solución de problemas tales como guías, información de contacto para el equipo de desarrollo, que les permite apoyar a los usuarios finales. Documentación técnica de las personas responsables de mantenimiento y evolución


César Luza Montero

Descripción General de Sistema Procesos ajustados (adopción)

del sistema.

Requerimientos Técnicos

No describe los problemas de comportamiento tales como los de usabilidad, seguridad y rendimiento a menudo se define como requerimientos no funcionales.

Plantillas Pruebas Modelado Estrategia de Pruebas Herramientas

Una "forma electrónica" que contiene información común a llenar los campos para un determinado tipo de producto de trabajo Comprende un Suite de Pruebas de Regresión y cualquier Reporte de Defectos. Una descripción de su enfoque general de prueba. Los paquetes de software utilizados para desarrollar el sistema

Materiales de Capacitación

Las notas de cursos, documentación general, tareas y mucho más utilizado para ayudar el entrenamiento de usuarios, personal de soporte y operaciones de soporte que funcionan con el sistema.

Casos de Uso

Casos de uso describe algo de valor a los usuarios y son un requerimiento primario del producto de trabajo del Agile UP.

Modelado de Casos de Uso

Un modelo de caso de uso está compuesto por cero o más diagramas de casos de uso, descripciones de casos d uso y descripciones de actores.

Documentación de Usuario

Los manuales, documentación de ayuda, etc; que los usuarios finales utilizan para ayudarles a entender el sistema.

Modelo de Interface de Usuario

Describe las interfaces de usuario de su sistema.

Comprende AUP, orientación, y plantillas ajustadas a sus necesidades del equipo del proyecto.

Entregables del negocio : los equipos de desarrollo (por ejemplo, los arquitectos,

administradores de base de datos, gestores del portafolio,...) a menudo proporcionan el seguimiento de la labor de productos para ayudar a orientar y facilitar los esfuerzos de su proyecto: ENTREGABLE

DESCRIPCIÓN

Modelo de la Arquitectura del Negocio Orientación del Desarrollo del Negocio Orientación de la Empresa Estado de la Misión de la Organización

Representa el marco de trabajo, la red, la configuración de l a liberación, infraestructura técnica de soporte y la infraestructura de dominio para la organización.

Visión de la Empresa

Una declaración del principal objetivo (s) de una organización.

Guías de Recursos Humanos

Normas y directrices para las actividades de gestión de personas-tales como la contratación, promoción, transferencia, capacitación, educación, etc.

Normas y directrices aplicables a todos los sistemas dentro de su organización, incluida la codificación de las directrices, la red de directrices, normas de datos, y así sucesivamente. Normas y directrices que deben seguirse dentro de su organización, incluyendo guías de desarrollo, guías de recursos humanos, guías de modelo, y guía de usabilidad. Una declaración de las estrategias que deben seguirse para alcanzar los Visión empresarial.


Describe las técnicas, tales como convenciones de nomenclatura, las directrices de estilo de diseño, estilo e incluso la notación de directrices sobre cómo los modelos deben ser organizados y documentados.

Guías de Modelado Arquitectura Referencia

de

Guías de Usabilidad

2.3

César Luza Montero

Un enfoque de la arquitectura diseñado y probado para usarse en un dominio particular, junto con el soporte del producto para habilitar su uso; Esto frecuentemente provee una base por crear una arquitectura de aplicación. Normas y directrices para el desarrollo de la interfaz de usuario de un sistema y para determinar su uso efectivo.

Adaptación de AUP al Problema de la Empresa ABC

Para las 4 fases a elaborar se desarrollará entregables como se detallará a continuación: Iteración I1 (Inicio) y E1 (Elaboración): Se entregará:





Requerimientos del software.



Modelado requisitos a alto nivel

Elaboramos de manera sencilla, clara e informal un borrador del diagrama de casos de uso así como una breve descripción de cada funcionalidad de cada caso de uso. 

Modelado arquitectura a alto nivel

El objetivo es tratar de identificar una arquitectura con posibilidades de funcionar bien desde el punto de vista técnico y conceptual. Haremos un diagrama de despliegue para razonar los nodos y un borrador básico del diagrama de clases. 

Prototipo interfaz de usuario básico

Se razonará sobre la presentación de la aplicación y su interacción con el usuario. En las iteraciones de construcción, de manera iterativa, vamos analizando un conjunto de requisitos, diseñando una solución, construyéndola y probando el resultado. Iteración C1 (Construcción):







En esta iteración nos centramos en el análisis, diseño e implementación de la forma de ingreso al sistema, así como los mantenimientos y los permisos de acceso. Se entregará tanto el diagrama de casos de uso revisado como el diagrama de clases, y el diagrama de secuencia de cada caso de uso. En código, se entregará una versión operativa que informe a través de mensajes en ventana del sistema, de los distintos mantenimientos que se hizo. Iteración C2 (Construcción):




César Luza Montero

En esta iteración nos centramos en el análisis, diseño e implementación de la forma de registrar una incidencia así como su solución. Se entregará tanto el diagrama de casos de uso revisado como el diagrama de clases, y el diagrama de secuencia de cada caso de uso. En código, se entregará una versión operativa que informe a través de mensajes en ventana del sistema. Iteración C3 (Construcción):





En esta iteración nos centramos en el análisis, diseño e implementación de la consulta y registro de preguntas frecuentes (F.A.Q.), así como las consultas y reportes que se pueden generar del sistema en mención. Se entregará tanto el diagrama de casos de uso revisado como el diagrama de clases, y el diagrama de secuencia de cada caso de uso. En código, se entregará una versión operativa que informe a través de mensajes en ventana del sistema. Iteración T1 (Transición):



Se prepara la herramienta para el despliegue, elaborándose:  Documentación  Pruebas a fondo  Preparar distribución e instalación. 2.4

Aplicación de AUP al Problema de la Empresa ABC Iteración I1 (Inicio) y E1 (Elaboración): Se entregará:





Requerimientos del software. 

Requerimientos funcionales El acceso al sistema será controlado con nombres de usuario y contraseñas, solo los usuarios con derechos de administrador podrán accesar las funciones administrativas, los usuarios normales no podrán hacerlo. Los usuarios con servicios de administrador debe ser capaz de administrar los permisos a cada usuario, así como su registro y su modificación. Los usuarios con permisos de administrador deben ser capaz de gestionar los consorcios, empresas, salas, personal, clientes, servicios y sub-servicios y las preguntas frecuentes. o

o

o


o

o

o

o

o



César Luza Montero

Las incidencias y requerimientos a consultar pueden estar organizados según los servicios y sub-servicios que la empresa brinda para una mejor búsqueda. Los usuarios normales pueden registrar su incidencia, así como primero consultar en el módulo de preguntas frecuentes si dicha consulta ya ha sido realizado anteriormente. Las incidencias tendrán un estado de atención clasificado por: NUEVO, EN PROCESO, VENCIDO, VENCIDO PARCIAL, CERRADO. Las incidencias así también tendrán un rango de prioridad clasificándose en: MUY ALTA, ALTA, MEDIUM, NORMAL. Los usuarios con permisos a Consultas pueden consultar la cantidad de requerimientos que se han realizado en rango de fechas por salas, por estado y por personal atendido.

Requerimientos no funcionales El sistema debe tener una disponibilidad de 24 x 7 (disponible en todo el día), ya que algunas salas de casino están en funcionamiento en todo el día y en cualquier momento puede ocurrir alguna incidencia. El sistema tendrá un rango de respuesta de tres a cinco segundos, es decir debe tener el mayor tiempo de respuesta posible. El sistema será instalado en el servidor web de la empresa LINKTEK. El sistema debe poder ser accesado desde cualquier lugar conectado a Internet, y por cualquier navegador posible (de preferencia Internet Explorer, Mozilla Firefox y Google Chrome). El sistema deberá ser fácilmente portable al sistema operativo Microsoft Windows XP o posteriores La tasa de fallos del sistema debe ser la menor posible restringido máximo a 5 fallos por semana. o

o

o

o

o

o

Modelado requisitos a alto nivel 

Diagrama de CUS Inicial


César Luza Montero

Modulo FAQ Modulo Mantenimientos

Modulo Procesos

Registrar Pregunta

Consultar Preguntas Frecuentes

(from Modulo FAQ)

(from M odulo FAQ)

Asignar Correos Asignar sala

(from Modulo Mantenimientos)


Registrar Requerimiento de Cerrar Requerimientos o Incidencia Servicio (from Modulo Procesos)

(from Modulo Procesos)

Gestionar Consorcio (from Modulo Mantenimientos)

Cliente Personal Gestionar Empresa

Registrar Incidencia (from Modulo Procesos)


Registrar Requerimiento (from Modulo Procesos)

Gestionar Sala (from Modulo Mantenimientos)

Registrar Mensaje Modulo consultas

(from Modulo Procesos)

Gestionar Servic io - Subservicio Consultar Reporte de Requerimientos por Sala

consultar Reporte de Requerimientos por Personal

(from Modulo consultas)



Gestionar Noticias


Gestionar Usuario (from Modulo Mantenimientos)

o

Consultar Reporte de Requerimientos por Estado

Gestionar Preguntas Frecuentes



Lista Inicial de casos de uso Funcionalidad

Casos de Uso

Registra y modifica los consorcios

Gestionar Consorcio

Registra y modifica las empresas

Gestionar Empresa

Registra y modifica las salas

Gestionar Sala

Registra y modifica el personal-cliente

Gestionar Cliente

Registra y modifica servicios y sub-servicios

Gestionar servicios y subservicios

Personal

–


César Luza Montero

Registra y modifica las noticias que se mostrarán en el sistema. Gestionar Noticia Registra, modifica y responde preguntas frecuentes realizadas por los usuarios.

Gestionar Frecuentes

Preguntas

Registra y modifica los usuarios en el sistema

Gestionar Usuarios

Asigna correos del personal según los servicios y sub-servicios Asignar Correos que brinda la empresa Asigna el usuario a una sala específica

Asignar Sala

El usuario registra una pregunta que no se encuentra dentro de la lista de preguntas frecuentes.

Registra Pregunta

El usuario consulta algunas preguntas frecuentes según los servicios y sub-servicios.

Consultar Frecuentes

El usuario consulta los requerimientos realizados en una sala según las fechas de rango establecidas y generar un reporte.

Consultar Requerimientos por Sala

El usuario consulta los requerimientos realizados por estado según las fechas de rango establecidas y generar un reporte.

Consultar Requerimientos por Estado

El usuario consulta los requerimientos atendidos por el personal según las fechas de rango establecidas y generar un reporte.

Consultar Requerimientos por Personal

El usuario escoge un sub-servicio específico e inmediatamente escoge la prioridad, el detalle y si desea correos adicionales para que se le envíe lo realizado.

Registrar Requerimiento de servicio

El usuario escoge registrar incidencia escogiendo la prioridad, el detalle y si desea correos adicionales para que se le envíe lo realizado.

Registrar Incidencia

El usuario escoge registrar requerimiento escogiendo la prioridad, el detalle y si desea correos adicionales para que se le envíe lo realizado.

Registrar Requerimiento

El usuario escoge una incidencia almacenada, hace clic en ampliar mostrando la información de la incidencia

Registrar Mensaje

El usuario que realizó la incidencia o requerimiento, podrá ser capaz de cerrar la incidencia si es que está solucionado su incidencia.

Cerrar Requerimiento o Incidencia

Preguntas


Modelo de arquitectura de alto nivel o

o

Diagrama de capas

Diagrama de componentes:

César Luza Montero


Prototipos de interfaz básico

Formulario de Logeo:

Formulario de Inicio:

Formulario de Mantenimiento de Consorcio:

César Luza Montero


Formulario de Mantenimiento de Empresa:

Formulario de Mantenimiento de Sala:

César Luza Montero


Formulario de Mantenimiento de Personal – Cliente:

César Luza Montero


Formulario de Asignar una sala

César Luza Montero


Formulario de Mantenimiento de Usuarios

Formulario de Mantenimiento de Servicios y Subservicios

César Luza Montero


Formulario de Preguntas

César Luza Montero


Formulario de Noticias

César Luza Montero


Formulario

de

Registrar

César Luza Montero

Requerimiento

de

Servicio

El Esquema Metodologico

Recommend Documents