Professional Documents
Culture Documents
Semana 2
Tema 2. Definición de MTs
2. Definición de MTs
Introducción
En el tema anterior identificamos los distintos tipos de sistemas que podemos integrar a un modelo
tecnológico y los componentes necesarios para que el modelo se pueda implantar como son: hardware,
software, telecomunicaciones, procesos y usuarios.
En este tema vamos a ver la identificación de distintos objetivos que deberá cumplir el modelo
tecnológico, el tiempo de desarrollo que requerirá y los posibles riesgos que se pueden presentar, todo
acorde a las políticas organizacionales y evaluando la utilidad del MT para cumplir con las necesidades
de información de la organización. Además, un punto importante, se deberán considerar los
requerimientos de capacitación de los diferentes usuarios e interesados.
La definición de objetivos del MT es parte de las primeras etapas del ciclo de vida de los Sistemas de
Información (SI). Si requiere dar un repaso sobre este ciclo y cómo se relaciona con algunos apartados
de este tema y de los temas de las siguientes semanas, puede ser de su interés revisar el “Resumen:
Ciclo de desarrollo de Sistemas de Información” que se encuentra en la carpeta de la SEMANA 2
de la sección Contenidos Semanales.
1. Identificación del problema y descripción de la situación actual
Antes de la identificación de objetivos es necesario tener identificado y analizado el problema a resolver
o las oportunidades de mejora del modelo actual y estudiar el entorno tecnológico actual (hardware,
software, telecomunicaciones) para identificar posibles mejoras o introducción de tecnología más
reciente que permita a la organización ser más competitiva, también será importante comprender los
procesos de negocio actuales ya sean automatizados o manuales. Dicha identificación del problema la
puede realizar a partir de entrevistas, observación, revisión de documentación, etc. y generar algún
documento o por ejemplo un análisis donde incluso se pueden incluir las necesidades de los usuarios
que no están siendo cubiertas por el modelo actual.
En este punto se podría incluir un análisis FODA del departamento o área que se pretende automatizar
o del sistema que se pretende mejorar.
2. Objetivos generales
Los objetivos generales del sistema también se conocen como requisitos generales o características
generales del sistema. Se recomienda incluir mínimo lo siguiente:
La descripción del objetivo en sí: El sistema deberá… (anotar una descripción general de ¿qué
hará el sistema?).
Requisitos hijos: si los hay.
Importancia y prioridad de este objetivo para el modelo
Estado del objetivo según el ciclo de vida
Para fines prácticos, en esta materia se presenta una forma de identificar los objetivos basándonos de
forma muy básica en el documento de Especificación de Requisitos de Software de la norma IEEE 830,
por lo cual, al identificar los objetivos generales del sistema o modelo, nos enfocaremos en identificar
los requisitos generales que deberá cumplir el sistema.
Los objetivos generales responderán a la pregunta ¿Qué hará el sistema?
Ejemplos de objetivos generales:
Objetivo general: ¿Qué hará el sistema?
Ejemplo 1. El sistema deberá llevar control de ventas
Ejemplo 2. El sistema deberá proporcionar y presentar cierta información de ventas
El objetivo general describirá características muy generales, las cuales se detallarán más por medio de
los siguientes objetivos funcionales y no funcionales.
El sistema deberá registrar los accesos al edificio mediante el uso de tarjetas magnéticas
El sistema deberá gestionar los recursos del centro deportivo (objetivo padre)
o Gestionar las reservas de las pistas del centro (objetivo hijo)
o Gestionar los horarios semanales de las actividades deportivas que se realizan en las
salas del centro (objetivo hijo)
o Gestionar los torneos del centro (objetivo hijo)
El sistema deberá registrar las operaciones o transacciones diarias del área de (ventas, recursos
humanos, contabilidad, etc.)
El sistema permitirá la consulta de datos de “x” (horas laboradas por trabajador, nómina mensual,
etc.)
El sistema presentará información de cuentas por cobrar
El sistema generará informes programados y a medida del área de producción
El sistema deberá elaborar el pronóstico de ventas para el siguiente mes
El sistema ofrecerá herramientas para el trabajo colaborativo
El sistema deberá permitir la comunicación externa con socios y proveedores
3. Objetivos funcionales
Los objetivos funcionales detallan las características que debe ofrecer el sistema a los usuarios para
alcanzar objetivos del negocio.
Ejemplos:
Algunos ejemplos de lo que pueden cubrir los objetivos funcionales de un modelo tecnológico
son:
Un Diagrama de Flujo de Datos DFD, es una representación gráfica de los procesos de datos, facilita la
comprensión de las interrelaciones de los subsistemas y sistemas. Se identifican además de los
procesos, las entradas y las salidas, puede ser muy útil para identificar distintas funcionalidades que
debe ofrecer el sistema. A partir del Diagrama de Flujo de Datos se puede generar un Diccionario de
Datos que contiene las características lógicas de los datos y a partir de ellos se generan las estructuras
de almacenamiento de datos como los objetos de una base de datos y sus atributos, por ejemplo, un
catálogo de productos con las características de cada producto (id, nombre, descripción, costo, precio
de venta, stock, etc.). Todo esto ya corresponderá a la etapa de análisis del modelo tecnológico ya
seleccionado.
Si tiene inquietud por conocer un poco más sobre los DFD y los Diccionarios de Datos, puede revisar
los siguientes enlaces:
Objetivos no funcionales:
Hay otros objetivos que se pueden establecer en un modelo o sistema y que se generan a partir de
requisitos no funcionales como pueden ser: la fiabilidad, la usabilidad, la eficiencia, la mantenibilidad, la
portabilidad, la seguridad.
Ejemplos:
Los objetivos de uso de un modelo o sistema son muy importantes ya que se relacionan directamente
con la interacción que tendrá el usuario con el sistema, por lo cual, el estudio de factibilidad deberá
contemplar la llamada factibilidad operacional.
La factibilidad operacional es la disposición y la capacidad de la gerencia, los empleados, los clientes,
los proveedores y otros, para operar, utilizar y respaldar un sistema propuesto. …si el software para un
nuevo sistema es demasiado difícil de utilizar, es posible que los empleados cometan muchos errores y
eviten su uso (O´Brien, 2001, págs. 93-94).
Los objetivos de uso incluirán aspectos también de usabilidad o facilidad de operación, tiempo de
aprendizaje, comprensión del sistema e incluso qué tan atractivo debe ser el sistema para que el usuario
se sienta cómodo al operarlo.
Para esto será necesario retomar el tema de los usuarios como componente del modelo tecnológico
considerando tipos de usuarios y sus características, ya que, dependiendo de cada usuario del sistema,
lo usará de distinta manera y los requerimientos de usabilidad se adaptarán a cada caso. No es lo mismo
un usuario que debe capturar transacciones completas de ventas, por ejemplo, a un usuario que sólo
generará informes seleccionando algunas opciones, o un usuario que requiere generar un pronóstico a
partir de la introducción de ciertos datos; son tres casos diferentes.
Al identificar los actores (usuarios) quienes serán los que generen una entrada o reciban una salda del
sistema, considere lo siguiente:
El sistema permitirá que un nuevo usuario se familiarice con su uso en un máximo de “x” minutos.
El sistema permitirá a un usuario que en un máximo de “x” pasos pueda llegar a la información
deseada.
El sistema deberá presentar formularios de captura fáciles de usar con información precargada
que se pueda seleccionar.
El sistema deberá permitir el acceso al catálogo de productos y el registro de ventas, desde
distintos dispositivos como computadoras de escritorio, portátiles, dispositivos móviles, tanto
para empleados de ventas en sucursal, como para clientes de una tienda en línea.
El sistema deberá permitir a través de un Dashboard de un BI, que el usuario decida con qué
clasificación o con qué filtros desea la información que consulta.
El sistema deberá enviar un mensaje de error explicando al usuario que no puede dar de alta un
nuevo producto con una clave que ya está siendo usada por otro producto.
El sistema permitirá realizar una búsqueda de libros por autor, título o tema.
En el siguiente documento podrá ver ejemplos de objetivos funcionales y no funcionales (dentro de estos
últimos se encuentran algunos objetivos de uso). Revise pág. 38 a 42).
Cruz M.; Granados J,; Lizama, A.; Baudillo, L. (2011). Sistema Informático para la administración
y control de expedientes del centro de rehabilitación integral para la niñez y la adolescencia.
Tesis. http://ri.ues.edu.sv/556/1/10136707.pdf
Almacenar todos los datos de un producto, que se podrá identificar si se podrá contar con un
catálogo completo de productos en formato digital o incluso impreso. Tener un catálogo completo
podrá incluso permitir hacer consultas por medio de distintos filtros o categorías.
Al buscar que el sistema permita registrar identificadores únicos para cada producto diferente,
dará como resultado la integridad de los datos dentro de los almacenes de datos.
Si el sistema simplifica el proceso de captura por medio de formularios con información
precargada como listas, cuadros desplegables, cuadros o botones de verificación, etc., dará por
resultado la integridad de los datos, la disminución de tiempo en la captura (imagine el tiempo
que se ahorrará al registrar ventas o entradas de nuevos productos al almacén), la rapidez de
aprendizaje al operar el sistema, la comodidad del usuario con el sistema, etc.
Si el sistema opera respetando diversas reglas del negocio, se podrán evitar errores de operación
que generen conflictos con clientes o proveedores, pérdidas económicas y hasta problemas
legales. (Piense por ejemplo que el sistema permita la venta de determinado producto que ya no
se tiene en existencia y que se ofrezca un tiempo de entrega inmediato).
La identificación aproximada del tiempo de desarrollo de un MT, dependerá de diversos factores entre
ellos: La metodología a usar (no es lo mismo usar una metodología convencional que una metodología
de desarrollo ágil), por lo tanto, dependiendo de la metodología se definirán distintas fases, la duración
de cada una y el traslape de las fases.
Otro punto a considerar es la cantidad de recursos humanos involucrados durante el desarrollo, las
habilidades, conocimientos y experiencia de cada uno.
Las herramientas con las que se cuenta tanto de hardware, como de software y telecomunicaciones,
para el desarrollo en sí, como para la implantación del modelo.
Si se requiere adquirir nuevos recursos tanto para el desarrollo como para la implantación, el tiempo que
tomará conseguirlos, si se van a usar nuevas plataformas o software que la empresa no manejaba, no
sólo se debe considerar el tiempo de adquisición, sino también de instalación y migración de los sistemas
que así lo requieran. En algunos casos será necesario migrar algún sistema a versiones de software
más actuales, lo que conlleva a la exportación y respaldo de datos, para importarlos al nuevo sistema o
software y realizar las correspondientes configuraciones y adaptaciones.
También se debe considerar el nivel de participación de los usuarios desde el análisis de requisitos, la
validación de los mismos, el análisis, diseño y desarrollo del modelo (como cuando se opta por un
desarrollo por prototipos), el tiempo de capacitación de los usuarios, la implantación del modelo, etc.
Otro aspecto a considerar podría ser la recolección de datos de distintas fuentes para integrarlos en un
solo repositorio, como es el caso de los almacenes de datos (Datawarehouse) por lo cual, se deberá
identificar primero cómo presentarán los datos cada área de la organización, en qué formatos y proseguir
con un proceso de ETL (Extracción, Transformación y Limpieza) de los datos, ya sea de forma manual
o por medio de algún software para tal propósito.
“La factibilidad técnica puede demostrarse si la empresa puede adquirir o desarrollar en el tiempo
requerido el software y hardware confiables capaces de satisfacer las necesidades de un sistema
propuesto” (O´Brien, 2001, pág. 93) .
Una vez que se han considerado los aspectos anteriores, se acostumbra generar una gráfica o
cronograma que muestre las distintas actividades a realizar, los responsables de cada actividad, los
recursos que será necesario asignar a cada actividad y las relaciones entre actividades, es decir, qué
actividades dependen de que se concluyan otras y cuáles se pueden realizar al mismo tiempo.
Fig. 1 Traslape de fases y actividades de desarrollo de sistemas. Fuente: (Witten & Bentley, 2008, pág. 53)
Durante la especificación de requisitos que debe cubrir el MT, conviene hacer una identificación o
estimación de posibles riesgos que pudieran llegar a afectar el desarrollo del modelo en tiempo y forma
desde el análisis, hasta la implantación y operación con la finalidad de emprender las acciones
correspondientes y evitar en la medida de lo posible esos riesgos.
Un riesgo es la probabilidad de que ocurra una circunstancia adversa. La administración de riesgos
implica identificar todos los riesgos, evaluarlos y tratarlos de alguna manera y será necesario documentar
los riesgos y comunicarlos a las personas que requieran saberlo.
Se pueden identificar las siguientes categorías de riesgos:
Rotación del personal asignado Proyecto Personal con experiencia abandona el proyecto antes de
al desarrollo que finalice
Bajo rendimiento de las Producto Las herramientas que ayudan al proyecto no tienen el
herramientas usadas para el desempeño adecuado
desarrollo
Cambio de administración Proyecto Habrá un cambio de administración organizacional con
diferentes prioridades
No disponibilidad de hardware Proyecto El hardware esencial para el proyecto no estará a tiempo
Cambio de tecnología Negocio La tecnología fundamental sobre la que se construirá el
sistema se sustituye por tecnología más actual
Fig. 3 Posibles tipos de riesgos. Fuente: Elaboración propia a partir de (Sommerville, 2005, pág. 98)
Análisis de riesgos: Se examinan los riesgos en detalle para determinar su impacto, su probabilidad y
el periodo de tiempo en el que es posible atenuar el riesgo. La valoración se hace por intervalos.
Fig. 4 Factores de análisis de riesgos. Fuente: Elaboración propia a partir de (Sommerville, 2005, págs. 98-99)
Planeación de riesgos: Considera los riesgos y las estrategias para administrarlo. Las estrategias
pueden ser de anulación, de disminución o planes de contingencia.
Supervisión de riesgos: Valora cada uno de los riesgos identificados para decidir si es más o menos
probable y cuando los efectos del mismo han cambiado.
El enfoque de factibilidad organizacional se centra en qué tan bien respalda un MT los objetivos de la
organización y su plan estratégico de SI, generalmente no se financian proyectos que no contribuyen de
forma directa al logro de objetivos estratégicos organizacionales (O´Brien, 2001, pág. 93).
El enfoque de factibilidad económica determina si los costos de desarrollar y operar un SI disminuirán
los costos e incrementarán los ingresos y utilidades de la organización (O´Brien, 2001, pág. 93).
Por lo cual, será de interés tomar en cuenta los resultados que genere el estudio de factibilidad en los
rubros mencionados, para que se elija la implantación del modelo tecnológico cumpliendo con las
políticas específicas de la organización y de esta manera se considere de verdadera utilidad.
Cabe mencionar, que a veces las políticas muy restrictivas podrán impedir que exista un desarrollo y
evolución considerable de una organización que se resiste a crecer, a cambiar o a mejorar. Un caso muy
clásico es el de la comparación de empresas como Blockbuster y Netflix, ésta última apostó por la
innovación tecnológica y hoy sabemos los resultados; mientras Bluckbuster continuaba con sus
productos en formato VHS, Netflix cambió al formato de CD que en aquel entonces era caro por ser un
formato nuevo, además de que se entregaban en el domicilio del cliente y podía conservarlos por el
tiempo que quisiera sin que eso implicara el cobro de excesivas cuotas de recargos (no sólo fue un
cambio tecnológico, también fue un cambio en sus procesos de entrega y devolución); una empresa
como Blockbuster habrá encontrado en esto una pérdida de ingresos y un incremento en sus costos, por
lo cual un modelo de este tipo no fue su mejor opción. Después Netflix optó por la entrega de sus
productos en streaming, los clientes pueden ver una película o serie cuantas veces quieran y pagan una
cuota fija, parecería gran pérdida de ingresos, pero se compensa con la cantidad de clientes suscritos,
aunque también se debe considerar las implicaciones de no tener un control total sobre cuántos usuarios
utilizan la misma cuenta.
Considere los siguientes objetivos generales de los modelos tecnológicos que se vieron en el tema
anterior:
Para conseguir mantener la intimidad con el cliente o con el proveedor, se pueden implantar sistemas
como CRM (Gestión de Relaciones con el Cliente) o SCM (Gestión de la Cadena de Suministro).
Para la mejora en la toma de decisiones es posible proponer desde un MIS (Sistema de Información
Gerencial), un DSS (Sistema de Soporte a las Decisiones) o todo un conjunto de soluciones de BI
(Inteligencia de Negocios) en los que el sistema genere de forma automática informes programados
periódicos o a petición del usuario que le permitan identificar desde los productos que más se venden,
los que será necesario descontinuar, la contratación de nuevos empleados, el cierre o apertura de una
sucursal, etc.
Identificar a los tipos de usuarios y sus características, así como los objetivos de funcionalidad y uso que
tendrá el MT, será de gran importancia para identificar los requerimientos de capacitación de los distintos
usuarios y stakeholders.
Ejemplos de tipos de usuarios:
En este caso, se requerirá una capacitación básica para conocer la interfaz de usuario y operar el nuevo
sistema contable o CRM que se fuera a integrar para la captura de entradas y salidas de ventas y
devoluciones, así como el registro de cuentas por cobrar si la venta fue a crédito.
Tipo de usuario Gerente contable
Formación Conocimientos sólidos de contabilidad
Habilidades Manejo de equipo de cómputo y software contable.
Actividades Generar y analizar diferentes reportes que genera el sistema y tomar las decisiones
correspondientes.
La capacitación para este tipo de usuario más que de captura sería de consulta, por lo cual deberá recibir
capacitación para acceder a distintos módulos del sistema en modo de sólo lectura, y tener la opción de
indicar de forma directa o a través de la selección de opciones, los diferentes tipos de reportes que
requiere ya sea por fecha, por rubro, de excepción, etc. El sistema quizá incluso le permita generar
gráficas o exportar los datos a otro sistema para generar gráficas, pronósticos, escenarios, tablas
dinámicas, etc., por ejemplo, una hoja de cálculo.
Otra consideración en cuanto a los requerimientos de capacitación, es que, entre más intuitivo, fácil de
usar y cómodo sea un sistema, más rápido y fácil aprenderá a operarlo el usuario y requerirá menos
tiempo y esfuerzo de capacitación.
Por ejemplo, un formulario de captura podría diseñarse para sea fácil de llenar, considerando el flujo
adecuado del formulario; que incluya secciones como encabezado, identificación y acceso,
instrucciones, cuerpo, firma y verificación, totales y comentarios; incluir leyendas de cómo completar el
formulario (ej. Para una fecha incluir DD/MM/AAAA).
Para asegurar el llenado apropiado de formularios o la captura de datos, se puede hacer uso de distintos
modos de captura como los lectores de código de barras, de cinta magnética, etc. Otro punto importante
es el aspecto del formulario, el cual debe motivar al usuario a llenarlo.
Otro aspecto que puede ayudar es diseñar una interfaz gráfica que sea consistente, por ejemplo, que el
usuario identifique claramente en dónde estará el menú en cada pantalla, que los botones estén
rotulados de forma igual o similar si realizan acciones similares. (Guardar, Borrar, Cancelar, etc.).
Aún con todo lo anterior, es relevante tomar en cuenta, que a pesar de lo intuitiva que pueda ser una
interfaz gráfica y la operación de un sistema, siempre será necesario proporcionar al usuario un paquete
de capacitación consistente de diversos elementos como manuales de usuario, guías rápidas, cursos de
práctica, etc.
Referencias
Kendall, K., & Kendall, J. (2011). Análisis y diseño de sistemas. México: Pearson Educación.
O´Brien, J. (2001). Sistemas de Información Gerencial. Colombia: McGraw Hill.
Pressman, R. (2008). Ingeniería de software, un enfoque práctico. Madrid: Mc Graw Hill.
Sommerville, I. (2005). Ingeniería de software. Madrid: Pearson Educación.
Witten, J., & Bentley, L. (2008). Análisis de Sistemas, diseño y métodos. México: McGraw Hill.