Sistemas de Información para la competitividad

Caso de negocio:

• Lo primero ante todo es identificar para quién lo patrocina, después de ello se realiza una identificación de la solucione alternativas y cual presenta una mejor opción de acuerdo con los costos y beneficios que se hayan identificado, así como la factibilidad de estos. No hay que olvidar, que también debemos identificar los riesgos y restricciones que estas alternativas puedan presentar. Ya al final, se realiza el enfoque del proyecto, es decir, convencer a los patrocinadores, describiendo todo lo anterior.

Plan de proyecto:

• Un plan de proyecto inicia con identificar los objetivos del proyecto, además del alcance de este, el valor que tiene y los resultados que vaya a dar. Luego crear una relación entre los requisitos u objetivos y las tareas que necesitarán realizar para estos, después de esto, realizar un diagrama de Grantt marcando fechas de las tareas a realizar, también es necesario describir las funciones y responsabilidades de cada tarea. Y por último y no menos importante, escribir los riesgos y problemas que podrían tomar las tareas del proyecto, así como los riesgos del proyecto.

Matriz de responsabilidades:

• También conocida como Matriz RACI, se empieza por identificar los roles que hay, los cuales se pondrán en la parte superior. Después identificar cuales son las tareas que se van a realizar y posteriormente asignar las tareas a los roles a los que pertenecen. Es recomendable verificar que esta matriz sirva a lo largo de la vida del proyecto, acordarlo con el equipo y con los patrocinadores, es decir, las partes interesadas.

Ejemplo:

[pic 2]

Documento de requerimientos funcionales:

• Primero que todo, debimos haber identificado los requerimientos funcionales del sistema. Para iniciar con el documento debemos describir cual es el objetivo de este o con que finalidad fue hecho, después de esto generalmente se maneja una tabla donde nombrarás los requerimientos funcionales y describirás a cada uno de manera de tallada y para finalizar sería como un breve resumen de todo lo que se necesitará, aunque también podemos agregar que se puede decir las características y requisitos de los requerimientos funcionales.

Documento de requerimientos no funcionales:

• Para no escribir tanto, diré que se tiene que hacer lo mismo que la sección de “documento de requerimientos funcionales”, solo que obviamente aplicado a requerimientos no funcionales.

Matriz de rastreo (traceabilidad):

• Primero es asignar un código a cada requerimiento y a su vez mantenerlos con un orden jerárquico (1, 1.1., 1.2, 2.5, 3.1.6, etc.). Generar una pequeña explicación de cada requerimiento y mostrar la categoría a la que pertenece cada requerimiento basándose en la guía PMBOK, la versión que lleva el requerimiento, su estado (activo, cancelado, diferido, etc.) así como la fecha de este, la personas que se encarga y su prioridad, entre otras. Al final y lo más importante y la razón del porque hacemos la matriz de rastreo es alinear y asignar el objetivo que se busca alcanzar con cada requerimiento, así como la necesidad de negocio.

Diagramas de casos de uso:

• Primero identificar los roles y los objetivos de ellos, poner de por medio los escenarios necesarios para que los roles cumplan el objetivo y generar un diagrama en base a ello. Cabe destacar que los diagramas de casos de uso muestran el qué van a hacer y no el cómo lo van a hacer.

Modelo de base de datos:

[pic 3][pic 4]

• Si bien no encontré una manera general de explicar el modelo de la base de datos, reside primer en identificar los elementos que habrá, luego los grupos en los cuales se verán divididos los elementos, así como las coincidencias o formas en que se relacionan los diferentes grupos en base a atributo o característica similar. Esto es lo más entendible que puedo hacerlo porque te enseñan mas bien a como hacer una base de datos en un programa más que qué cosas lleva y como se relacionarán e identificarán.

Diagrama de arquitectura:

• El diagrama de arquitectura podría parecerse al diagrama de caso de uso, pero no son lo mismo. Debes identificar los elementos que conforman a un sistema de información, así como de sus objetivos y funciones, para diseñar un diagrama mostrando que va a hacer cada cosa dentro de un sistema. También en este tendrás que tomar en cuenta entradas, salidas, procesos y conexiones.

Diseño de aplicación:

• Para realizar el diseño de una aplicación debes identificar los requerimientos necesarios, así como el gusto de los clientes en consideración a una interfaz agradable para él. Lo recomendable es identificar los requerimientos, realizar el diseño de la aplicación en torno a eso, ver si esto le gusta al cliente probando con un grupo de gente, para que den sus opiniones con respecto a la interfaz y así hasta que sea aceptable el diseño.

Diseño de integración de sistema

• Para diseñar un sistema integrado de gestión, debemos partir de la gestión por procesos. Con el fin de alcanzar un nivel de integración maduro, en el que todos los aspectos se relacionen a lo largo de cada proceso de la organización existen varios estándares para la integración de los sistemas, como, por ejemplo, la norma UNE 66177 de Sistemas de gestión: una guía para la integración de los sistemas de gestión que incluye tres métodos denominados respectivamente método básico, método avanzado y método experto, aplicándose uno u otro en función de la madurez o experiencia que tenga la empresa en la gestión por procesos

Plan de capacitación/entrenamiento a usuarios

• Después de instalar un programa para ser usado por una organización, corresponde capacitar a los usuarios para que sepan utilizar de manera adecuada el nuevo recurso.
• Esta fase correspondiente al proceso de implantación de software se realiza habitualmente de manera presencial, aunque no se descarta que también se pueda desarrollar en línea o con ayuda de programas e-learning y el respaldo de manuales específicos.
• El nivel de preparación y los conocimientos previos que tengan los usuarios y las funciones que desarrollan al interior de la organización determina el número de horas necesarias para desarrollar la capacitación.

Manual de usuarios

• Los manuales de usuarios suelen estar escritos en diversos idiomas y contar tanto con textos como con imágenes. De esta forma se facilita la comprensión de los conceptos. Los diagramas y esquemas también son habituales.
• Una estructura frecuente de los manuales de usuario incluye una introducción al producto en cuestión, un índice con los contenidos del manual, la guía en sí misma, una sección de problemas frecuentes y su forma de solucionarlos, los datos de contacto y un glosario.

Documentación de código

...