UNIDAD IV ALTERNATIVAS DE ADQUISICIÓN EN SISTEMAS DE INFORMACIÓN

Identificación de problemas, oportunidades y objetivos.

En la primera fase del ciclo de vida del desarrollo de sistemas el analista tiene que ver con la identificación de problemas, oportunidades y objetivos. Esta etapa es crítica para el éxito del resto de proyecto, debido a que nadie quiere desperdiciar el tiempo subsecuente resolviendo el problema equivocado. La primera fase requiere que el analista observe honestamente lo que está sucediendo en un negocio. Luego, junto con los demás miembros de la organización, el analista hace resaltar los problemas. Frecuentemente estos ya han sido vistos por los demás, y son la razón por la cual el analista fue llamado inicialmente. Las personas involucradas en la primera fase son los usuarios, analistas y administradores de sistemas que coordinan el proyecto. Las actividades de esta fase consisten en entrevistas a los administradores de los usuarios, sumarización del conocimiento obtenido, estimación del alcance del proyecto y documentación de los resultados. La salida de esta fase es un estudio de factibilidad que contiene una definición del problema y la sumarización de los objetivos. Luego los administradores deben tomar una decisión para ver si continúan con el proyecto propuesto.

Determinación de los requerimientos de información.

Entre las herramientas utilizadas para definir los requerimientos de información en el negocio se encuentran: muestreo e investigación de los datos relevantes, entrevistas, cuestionarios, el comportamiento de los tomadores de decisiones y su ambiente de oficina y hasta la elaboración de prototipos. En esta fase el analista está esforzándose por comprender qué información necesitan los usuarios para realizar su trabajo. Las personas involucradas en esta fase son los analistas y los usuarios, típicamente los administradores de las operaciones y los trabajadores de las operaciones.

Análisis de las necesidades del sistema.

La siguiente fase que realiza el analista de sistemas involucro el análisis de las necesidades del sistema. Nuevamente, herramientas y técnicas especiales ayudan para que el analista haga las determinaciones de los requerimientos. Una herramienta de éstas es el uso de diagramas de flujo de datos para diagramar la entrada, proceso y salida de las funciones del negocio en forma gráfica estructurado. A partir de los diagramas de flujo de datos se desarrolla un diccionario de datos, que lista todos los conceptos de datos usados en el sistema, así como sus especificaciones, si son alfanuméricos y qué tanto espacio ocupan cuando se imprimen. Durante esta fase el analista de sistemas también analiza las decisiones estructuradas que se hacen. Las decisiones estructuradas son aquellas para las que pueden ser determinadas las condiciones como alternativas de condición, acciones y reglas de acción. Hay tres métodos principales para el análisis de decisiones estructurales: lenguaje estructurado, tablas de decisión y árboles de decisión.

Diseño del sistema recomendado.

En esta fase del ciclo de vida del desarrollo de sistemas, el analista usa la información recolectada anteriormente para realizar el diseño lógico del sistema de información. El analista diseña procedimientos precisos para la captura de datos, a fin de que los datos que van a entrar al sistema de información sean correctos. Además, el analista también proporciona entrada efectiva para el sistema de información mediante el uso de técnicas para el buen diseño de formas y pantallas.

Desarrollo y documentación del software.

En la quinta fase del ciclo de vida del desarrollo de sistemas el analista trabaja con los programadores para desarrollar cualquier software original que se necesite. Durante esta fase, el analista también trabaja con los usuarios para desarrollar documentación efectiva para el software, incluyendo manuales de procedimientos. La documentación le dice al usuario la manera de usar el software y también qué hacer si se suceden problemas con el software.

Pruebas y mantenimiento del sistema.

Antes de que pueda ser usado, el sistema de información debe ser probado. Es mucho menos costoso encontrar problemas antes de que el sistema sea entregado a los usuarios. Algunas de las pruebas son realizadas por los programadores solos, y otras por los analistas de sistemas junto con los programadores. Primero se ejecuta una serie de pruebas para que destaquen los problemas con datos de ejemplo y eventualmente con datos reales del sistema actual. El mantenimiento del sistema y de su documentación comienza en esta fase y es efectuado rutinariamente a lo largo de la vida del sistema de información.

Implementación y evaluación del sistema.

En esta fase del desarrollo del sistema el analista ayuda a implementar el sistema de información. Esto incluye el entrenamiento de los usuarios para que manejen el sistema. Algún entrenamiento es hecho por los proveedores, pero la supervisión del entrenamiento es responsabilidad del analista de sistemas. Adicionalmente, el analista necesita un plan para una conversión suave del sistema antiguo al nuevo. La evaluación se muestra como parte de esta fase final de ciclo de vida del desarrollo del sistema, principalmente para efectos de discusión. De hecho, la evaluación se realiza durante cada fase. Un criterio principal que debe ser satisfecho es si los usuarios pretendidos ya están usando el sistema.

4.2 PROTOTIPOS

PROTOTIPOS INFORMATICOS

 El desarrollo orientado a prototipos

 Definición de un prototipo en software: “…es un modelo del comportamiento del sistema que puede ser usado para entenderlo completamente o ciertos aspectos de él y así clarificar los requerimientos… Un prototipo es una representación de un sistema, aunque no es un sistema completo, posee las características del sistema final o parte de ellas”

Modelo o maqueta del sistema que se construye para comprender mejor el problema y sus posibles soluciones:

• Evaluar mejor los requisitos.
• Probar opciones de diseño.

Características de los prototipos

• Funcionalidad limitada.
• Poca fiabilidad.
• Características de funcionalidad pobres.
• Alto grado de participación del usuario el cual evalúa los prototipos, propone mejoras y detalla requisitos.
• Alto grado de participación del analista de sistemas, ya que en muchos casos los usuarios no pueden indicar los requisitos sin tener experiencia con el sistema.
• El prototipo da mayor conocimiento al usuario y analistas ayudando a que el usuario aprenda a utilizar el sistema.

Uso de prototipo

Se presenta al cliente un prototipo para su experimentación.

• Ayuda al cliente a establecer claramente los requisitos.

Ayuda a los desarrolladores a:

• Validar corrección de la especificación.
• Aprender sobre problemas que se presentarán durante el diseño e implementación del sistema.
• Mejorar el producto.
• Examinar viabilidad y utilidad de la aplicación.

Tipos de prototipos.

Prototipado de interfaz de usuario: modelos de pantallas.

Prototipado funcional (operacional): implementa algunas funciones, y a medida que se comprueba que son las apropiadas, se corrigen, refinan, y se añaden otras.

Modelos de rendimiento: evalúan el rendimiento de una aplicación crítica (no sirven al análisis de requisitos).

Rápido o desechable:

• Sirve al análisis y validación de los requisitos.
• Después se redacta la especificación del sistema y se desecha el prototipo.
• La aplicación se desarrolla siguiendo un paradigma diferente.
• Problema: cuando el prototipo no se desecha, y termina convirtiéndose en el sistema final.

Evolutivos:

• Comienza con un sistema relativamente simple que implementa los requisitos más importantes o mejor conocidos.
• El prototipo se aumenta o cambia en cuanto se descubren nuevos requisitos.
• Finalmente, se convierte en el sistema requerido.
• Actualmente se usa en el desarrollo de sitios Webs y en aplicaciones de comercio electrónico.

Vertical

• Desarrolla completamente alguna de las funciones.

Horizontal

• Desarrolla parcialmente todas las funciones.

Herramientas de prototipado.

• Lenguajes dinámicos de alto nivel.
• Lenguajes de cuarta generación (4GLs) (programación de BBDD).
• Ensamblaje de componentes y aplicaciones.

Lenguajes Dinámicos de alto nivel.

Muy usados:

• Smalltalk (basado en objetos, sistemas interactivos)
• Java (basado en objetos, sistemas interactivos)
• Prolog (lógico, procesamiento simbólico)
• LISP (basado en listas, procesamiento simbólico)

Elección del lenguaje:

• ¿Cuál es el dominio de aplicación?
• ¿Cuál es la interacción de usuario requerida?
• (Java, Smalltalk se integran bien con las interfaces Web.)
• ¿Cuál es el entorno proporcionado para el lenguaje?

Lenguajes de 4ª Generación.

• La mayoría de aplicaciones de gestión son interactivas e implican la manipulación de una BD y la producción de salidas que involucran organizar y dar formato a esos datos.
• 4GL: lenguaje de programación de BBDD (y su entorno de desarrollo), que contiene conocimiento de la BD y operaciones para manipulación de la misma.
• 4GL: lenguaje no Procedimental.
• Reducen claramente los costos del desarrollo.
• Muy usados en prototipado evolutivo.
• Muchos 4GLs permiten el desarrollo de interfaces de
• BBDD basadas en navegadores Web.
• Generan SQL.
• Menos eficientes que los lenguajes de programación convencionales.
• Reducen claramente los costos del desarrollo.

 El desarrollo de prototipos con reutilización comprende dos niveles:

1. El nivel de aplicación, en el que una aplicación completa se integra con el prototipo

• P.ej., si el prototipo requiere procesamiento de textos, se puede integrar un sistema estándar de procesamiento de textos (MS Office).

B. El nivel de componente, en el que los componentes se integran en un marco de trabajo estándar.

• Visual Basic, TCL/TK, Python, Perl…

-       Lenguajes de alto nivel sin tipos, con kits de herramientas gráficas.

-       Desarrollo rápido de aplicaciones pequeñas y relativamente sencillas, construidas por una persona o conjunto de personas.

-       No existe una arquitectura explícita del sistema.

• CORBA, DCOM, JavaBeans

-       Junto con un marco arquitectónico, es más apropiado para sistemas grandes.

Prototipos de Interface de Usuario.

 Las descripciones textuales y los diagramas no son suficientemente buenos para expresar los requisitos de la interfaz.

La construcción de prototipos evolutivos con la participación del usuario final es la forma más sensata de desarrollar una interfaz.

Los usuarios deben estar implicados en la evaluación y evolución del prototipo.

Herramientas:

• Generadores de interfaz (4GLs, Visual Basic, etc.).
• Editores de páginas Web.
• Herramientas CASE.

-       Formularios, pantallas, generación de código…

• Bocetos en papel.
• Aplicaciones de dibujo

-       Harward Graphics, etc.

• MS PowerPoint.
• Etc.

 FASES

Las fases que comprende el método de desarrollo orientado a prototipos serían:

• Investigación preliminar. Las metas principales de esta fase son: determinar el problema y su ámbito, la importancia y sus efectos potenciales sobre la organización por una parte y, por otro lado, identificar una idea general de la solución para realizar un estudio de factibilidad que determine la factibilidad de una solución software.

• Definición de los requerimientos del sistema. El objetivo de esta etapa es registrar todos los requerimientos y deseos que los usuarios tienen en relación al proyecto bajo desarrollo. Esta etapa es la más importante de todo el ciclo de vida, es aquí donde el desarrollador determina los requisitos mediante la construcción, demostración y retroalimentaciones del prototipo. Por lo mismo esta etapa será revisada con más detalle luego de esta descripción.

• Diseño técnico. Durante la construcción del prototipo, el desarrollador ha obviado el diseño detallado. El sistema debe ser entonces rediseñado y documentado según los estándares de la organización y para ayudar a las mantenciones futuras. Esta fase de diseño técnico tiene dos etapas: por un lado, la producción de una documentación de diseño que especifica y describe la estructura del software, el control de flujo, las interfaces de usuario y las funciones y, como segunda etapa, la producción de todo lo requerido para promover cualquier mantención futura del software.

• Programación y prueba. Es donde los cambios identificados en el diseño técnico son implementados y probados para asegurar la corrección y completitud de los mismos con respecto a los requerimientos.

• Operación y mantención. La instalación del sistema en ambiente de explotación, en este caso, resulta de menor complejidad, ya que se supone que los usuarios han trabajado con el sistema al hacer las pruebas de prototipos. Además, la mantención también debería ser una fase menos importante, ya que se supone que el refinamiento del prototipo permitiría una mejor claridad en los requerimientos, por lo cual las mantenciones perfectivas se reducirían. Si eventualmente se requiriese una mantención entonces el proceso de prototipado es repetido y se definirá un nuevo conjunto de requerimientos.

La fase más importante corresponde a la definición de requerimientos, la cual correspondería a un proceso que busca aproximar las visiones del usuario y del desarrollador mediante sucesivas iteraciones. La definición de requerimientos consiste de cinco etapas entre dos de las cuales se establece un ciclo iterativo:

• Análisis grueso y especificación. El propósito de esta subfase es desarrollar un diseño básico para el prototipo inicial.

• Diseño y construcción. El objetivo de esta subfase es obtener un prototipo inicial. El desarrollador debe concentrarse en construir un sistema con la máxima funcionalidad, poniendo énfasis en la interface del usuario.

• Evaluación. Esta etapa tiene dos propósitos: extraer a los usuarios la especificación de los requerimientos adicionales del sistema y verificar que el prototipo desarrollado lo haya sido en concordancia con la definición de requerimientos del sistema. Si los usuarios identifican fallas en el prototipo, entonces el desarrollador simplemente corrige el prototipo antes de la siguiente evaluación. El prototipo es repetidamente modificado y evaluado hasta que todos los requerimientos del sistema han sido satisfechos. El proceso de evaluación puede ser dividido en cuatro pasos separados: preparación, demostración, uso del prototipo y discusión de comentarios. En esta fase se decide si el prototipo es aceptado o modificado.

• Modificación. Esto ocurre cuando la definición de requerimientos del sistema es alterada en la sub−fase de evaluación. El desarrollador entonces debe modificar el prototipo de acuerdo a los comentarios hechos por los usuarios.

• Término. Una vez que se ha desarrollado un prototipo estable y completo, es necesario ponerse de acuerdo en relación a aspectos de calidad y de representación del sistema.

 En la siguiente figura se puede ver un esquema en que estas etapas se realizan, note que la especificación de requerimientos está claramente diferenciada de las demás. Es en ella donde se utiliza el prototipado, ya que permite entregar al usuario lo que sería una visión la solución final en etapas tempranas del desarrollo, reduciendo tempranamente los costos de especificaciones erróneas.

Modelo de desarrollo Orientado a Prototipos

Las ventajas de un enfoque de desarrollo orientado a prototipos están dadas por:

• Reducción de la incertidumbre y del riesgo
• Reducción de tiempo y de costos, incrementos en la aceptación del nuevo sistema,
• Mejoras en la administración de proyectos
• Mejoras en la comunicación entre desarrolladores y clientes, etc.

Si bien, el desarrollo orientado a prototipos tiene considerables ventajas, también presenta desventajas como:

• La dependencia de las herramientas de software para el éxito ya que la necesidad de disminución de incertidumbre depende de las iteraciones del prototipo, entre más iteraciones exista mejor y esto último se logra mediante el uso de mejores herramientas lo que hace a este proceso dependiente de las mismas.
• También, no es posible aplicar la metodología a todos los proyectos de software y, finalmente, la mala interpretación que pueden hacer los usuarios del prototipo, al cual pueden confundir con el sistema terminado.
• No se puede desconocer que la fase de definición de requerimientos se ha perfeccionado en dos aspectos importantes: primero se ha aproximado las visiones del usuario y el desarrollador, lo cual representa el beneficio de establecer una base común de comunicación; también, el hacer explícita la posibilidad de iterar sobre estos dominios permitiría que la convergencia de los mismos sea una posibilidad cierta.

Un escenario para la construcción de prototipos

Todos los proyectos de ingeniería de software comienzan con una petición del cliente. La petición puede estar en la forma de una memoria que describe un problema, un informe que define un conjunto de objetivos comerciales o del producto, una petición de propuesta formal de una agencia o compañía exterior, o una especificación del sistema que ha asignado una función y comportamiento al software, como un elemento de un sistema mayor basado en computadora. Suponiendo que existe una petición para un programa de una de las formas dichas anteriormente, para construir un prototipo del software se aplican los siguientes pasos:

PASO 1. Evaluar la petición del software y determinar si el programa a desarrollar es un buen candidato para construir un prototipo. Debido a que el cliente debe interaccionar con el prototipo en los últimos pasos, es esencial que:

1)      el cliente participe en la evaluación y refinamiento del prototipo, y

2)      el cliente sea capaz de tomar decisiones de requerimientos de una forma oportuna. Finalmente, la naturaleza del proyecto de desarrollo tendrá una fuerte influencia en la eficacia del prototipo.

PASO 2. Dado un proyecto candidato aceptable, el analista desarrolla una representación abreviada de los requerimientos. Antes de que pueda comenzar la construcción de un prototipo, el analista debe representar los dominios funcionales y de información del programa y desarrollar un método razonable de partición. La aplicación de estos principios de análisis fundamentales, pueden realizarse mediante los métodos de análisis de requerimientos.
PASO 3. Después de que se haya revisado la representación de los requerimientos, se crea un conjunto de especificaciones de diseño abreviadas para el prototipo. El diseño debe ocurrir antes de que comience la construcción del prototipo. Sin embargo, el diseño de un prototipo se enfoca normalmente hacia la arquitectura a nivel superior y a los aspectos de diseño de datos, en vez de hacia el diseño procedimental detallado.

PASO 4. El software del prototipo se crea, prueba y refina Idealmente, los bloques de construcción de software preexisten se utilizan para crear el prototipo de una forma rápida. Desafortunadamente, tales bloques construidos raramente existen. Incluso si la implementación de un prototipo que funcione es impracticable, es escenario de construcción de prototipos puede aun aplicarse. Para las aplicaciones interactivas con el hombre, es posible frecuentemente crear un prototipo en papel que describa la interacción hombre-maquina usando una serie de hojas de historia.
PASO 5. Una vez que el prototipo ha sido probado, se presenta al cliente, el cual “conduce la prueba” de la aplicación y sugiere modificaciones. Este paso es el núcleo del método de construcción de prototipo. Es aquí donde el cliente puede examinar una representación implementada de los requerimientos del programa, sugerir modificaciones que harán al programa cumplir mejor las necesidades reales.

PASO 6. Los pasos 4 y 5 se repiten iterativamente hasta que todos los requerimientos estén formalizados o hasta que el prototipo haya evolucionado hacia un sistema de producción. El paradigma de construcción del prototipo puede ser conducido con uno o dos objetivos en mente:

1)      El propósito del prototipado es establecer un conjunto de requerimientos formales que pueden luego ser traducidos en la producción de programas mediante el uso de métodos y técnicas de ingeniería de programación, o

2)      El propósito de la construcción del prototipo es suministrar un continuo que pueda conducir al desarrollo evolutivo de la producción del software. Ambos métodos tienen sus meritos y amos crean problemas.

Para poder realizar el prototipado debemos aplicar una técnica de captura de requerimientos que es una herramienta que ayuda al proceso de abstracción de las características de un sistema. La captura de requerimientos se hace a través de un proceso específicamente mental, el cual es el analista quien tiene la capacidad para discernir sobre los detalles que interesan en realidad al sistema, valiéndose generalmente de experiencias pasadas.

La identificación de actores y use case en un sistema se hace para:

• Delimitar el sistema de su ambiente externo.

• De qué y quién actuará con el sistema y que funcionalidad es la que se espera de él.
• Capturar y definir un glosario de términos.
• Además es necesario que nosotros como analistas utilicemos una herramienta propia para realizar cada uno de los pasos antes mencionados.

EJEMPLO:

Prototipo informático para la evaluación de la calidad de la educación superior

Definición del Problema:

Las universidades necesitan desarrollar procesos de evaluación institucional de desempeño, que conllevan a la revisión de sus estructuras funcionales y al conocimiento diagnóstico de la situación actual con el fin de incrementar los niveles de eficacia, eficiencia y efectividad de la gestión universitaria.

Es necesario fomentar procesos de evaluación en función de optimizar el uso de los recursos humanos, tecnológicos y financieros disponibles en la institución a objeto de lograr un desarrollo más armónico y planificado, en atención a una estricta observación de su misión. Bajo esta perspectiva se ofrece una propuesta de Prototipo Informático para la Evaluación de la Calidad de la Educación Superior, cuyos objetivos, entre otros, son: fomentar e incentivar la cultura de evaluación de la calidad universitaria; diseñar indicadores de gestión universitaria para dicho sistema de información, para cada uno de los ámbitos: académico, investigación, extensión y administrativo. Para el desarrollo, se aplicarán las herramientas y técnicas para levantar los requerimientos de usuario, y producir las salidas que satisfagan las necesidades de información y el acceso en forma integrada a la misma; respecto a los diferentes niveles de la pirámide organizacional, accesibilidad a indicadores de gestión de calidad universitaria a través de módulos interdependientes; esto es, cada nivel con su vista de usuario en la base de datos. Se aplica la metodología modular de sistemas, el enfoque de arriba hacia abajo y el diseño de base de datos relacional.

El prototipo está diseñado bajo una interfaz gráfica para interactuar con el usuario a través de botones programables y la navegación del sistema se realizará a través de pantallas tipo ventanas

• Modelo sistémico para la elaboración del prototipo informático de evaluación de la calidad en educación superior

El modelo sistémico, se basa en las fórmulas más convencionales de la teoría de sistemas, considerando entradas, transferencias y salidas.

Será el utilizado para el prototipo informático propuesto, ya que ofrece todas las bondades de la metodología de sistemas.

En el modelo de evaluación propuesto para el prototipo de evaluación de la calidad universitaria, se perfilan tres bloques, como lo muestra la gráfica siguiente:

• Entrada: estaría constituida por las inversiones, tanto en recursos materiales como humanos. En otras palabras: salas, talleres, bibliotecas, laboratorios con todos sus implementos; además de estudiantes, profesores y personal administrativo.
• Procesos: estarían compuestos justamente por todas las interacciones que tienen lugar en la institución y que permiten que ésta pueda cumplir los compromisos adquiridos con la sociedad, en cuanto a conocimiento creados, profesionales formados y servicios entregados a la comunidad. Esto incluye todos los procedimientos de administración universitaria y gestión financiera de la organización.
• Salida o productos: corresponde a los logros organizacionales en docencia, investigación y extensión. Serían aspectos del resultado, la cantidad de graduados por cohorte, los proyectos de investigación realizados, las publicaciones de los mismos y el número de académicos perfeccionados en un periodo determinado.

En síntesis, el modelo sistémico presenta para estos propósitos una gran ventaja, pues ayuda a agrupar de manera ordenada los componentes institucionales y facilita la comprensión de la relación que existe entre los mismos.

Propuesta para sistematizar la información en el prototipo de evaluación de la calidad de las instituciones de educación superior

Para sistematizar la información se utilizarán las seis dimensiones del modelo de CINDA que, como se ha dicho, permite hacer una revisión bastante completa y coherente en los siguientes aspectos: académicos en general, en la función docente, de investigación y creación, de extensión y servicios, y de gestión administrativa.

De acuerdo con ello, se ha planteado la matriz modelo CINDA de información para cada uno de los tres aspectos, que incluye los problemas de calidad a resolver, las propuestas de solución y las sugerencias estratégicas.

Matriz modelo CINDA

Dicha matriz se aplicará para cada uno de los aspectos a evaluar respecto a la calidad universitaria, entre los que tenemos:

• Función Docente
• Aspectos Generales Académicos
• Función Investigación
• Función Extensión
• Gestión Administrativo-académica

• Metodología para el desarrollo del prototipo de evaluación de la calidad universitaria

Para el desarrollo del prototipo informático para la evaluación de la calidad de la educación superior, se aplicarán los instrumentos y técnicas para levantar los requerimientos de usuario, y producir las salidas que satisfagan las necesidades de información y el acceso en forma integrada a la misma, respecto a los diferentes niveles de la pirámide organizacional; esto es, nivel estratégico, nivel táctico y nivel operativo, accesibilidad a indicadores de gestión de calidad universitaria a través de módulos interdependientes, es decir, cada nivel con su vista de usuario en la base de datos.

Se aplica la metodología modular de sistemas, el enfoque de arriba hacia abajo y el diseño de base de datos relacional.

Diseño de arriba hacia abajo (top-down)

Se selecciona el diseño de arriba hacia abajo, “por la facilidad de visualizar una gran imagen del sistema y luego explotarla en partes o subsistemas más pequeños. El diseño de arriba hacia abajo permite que el analista de sistemas piense acerca de las interrelaciones e interdependencias de los subsistemas. Este enfoque también proporciona el énfasis deseado sobre la sinergia o las interfaces que requieren los sistemas y subsistemas. Las ventajas de usar este enfoque para el diseño de sistemas incluyen el evitar el caos de diseñar un sistema todo a la vez. El tratar de tener todos los subsistemas en su lugar y funcionando a la vez es aceptar que se va a fallar”.

Enfoque modular para el desarrollo de sistemas

Una vez que ha sido tomado el enfoque de diseño de arriba hacia abajo, el enfoque modular es útil en la programación. Este enfoque involucra la división de la programación en partes o módulos lógicos y manejables. Este enfoque de programación se ajusta bien con el diseño de arriba hacia abajo, debido a que enfatiza las interfaces entre módulos. En el prototipo se aplica la metodología modular de sistemas para desarrollar los módulos: Función Docente, Función Investigación, Aspectos Generales Académicos, Función Extensión, Gestión Administrativo-académica.

Diseño de base de datos relacional

Se selecciona el modelo relacional de base de datos, por ser el óptimo en comparación con los modelos de base de datos jerárquicos y el de redes. Otra ventaja de este modelo es la portabilidad, ya que la mayoría de los paquetes de manejo de base de datos para computadores personales usan el enfoque “relacional”. En este modelo los datos se organizan en “tablas” en las cuales una fila equivale a un registro. Conceptualmente la tabla de la base de datos es lo mismo que un archivo. Una o más tablas constituyen una base de datos relacional. La base de datos relacional se refiere a una serie de tablas y a las relaciones entre ellas. El sistema tendrá capacidad, entre otras cosas, para:

1. Crear y mantener la base de datos: esto es agregar, eliminar y modificar tablas.
2. Extraer y presentar información que cumpla ciertas condiciones.
3. Hacer consultas (por ejemplo: “¿Cuál es el promedio de notas de los alumnos por carrera y por universidad? ¿Cuál es la matricula por área de conocimiento? ¿Cuál es la rotación matricular?”, etc.).
4. Ordenar los registros (tablas), según el campo clave.
5. Generar informes adecuados para el usuario. (Por ejemplo: una universidad generará el reporte de gestión periódicamente, según sea el caso o el “Reporte financiero” puede ser semestral o anual, etc.).

Modelo entidad relación

Se generarán una serie de entidades y relaciones “uno a muchos”, a las cuales se le aplicará la técnica de normalización de tablas, incluso la tercera forma normal 3FN y 4FN, de ser necesario. Entre las entidades tenemos: Universidad, Alumnos, Profesor, Organismos reguladores, Proveedores, Productos, Oferta académica laboral, Egresados, etc.

Diseño de la interfaz gráfica del prototipo

Para el desarrollo del prototipo informático para la evaluación de la calidad de la educación superior, se deben aplicar instrumentos y técnicas para levantar los requerimientos de usuario, y producir las salidas que satisfagan las necesidades de información y el acceso en forma integrada a la misma, respecto a los diferentes niveles de la pirámide organizacional; esto es nivel estratégico, nivel táctico y nivel operativo, accesibilidad a indicadores de gestión de calidad universitaria a través de módulos interdependientes; esto es, cada nivel con su vista de usuario en la base de datos.

El prototipo está diseñado bajo una interfaz gráfica para interactuar con el usuario a través de botones programables y la navegación del sistema se realizará a través de pantallas tipo ventanas.

4.3 adquisicion de sistemas de informacion

      

l el origen del estándar MoProSoft es la necesidad de cumplir con la estrategia número 6 del Programa de Software (ProSoft) de la Secretaría de Economía (establecida desde el sexenio 2000-2006), relativa a "alcanzar niveles internacionales de capacidad de procesos" por parte de las pequeñas y medianas empresas mexicanas desarrolladoras de software. El esquema MoProSoft permite a las PyMES que desarrollan software, demostrar la capacidad de sus procesos y con esto hacerlas más competitivas, a fin de que tengan mayores probabilidades de permanecer en el mercado.

En el ámbito de TI, NYCE contribuyó a la elaboración y posterior evaluación del estándar o norma NMX-I-059/02-NYCE-2011 "Tecnología de la información - Ingeniería de Software - Calidad de producto"(MoProSoft). La creación de este estándar no fue casual, ya que con esto se logró dar legitimidad y certeza jurídica al modelo de evaluación de madurez de la capacidad de procesos, para así elevarlo a la categoría de norma, hoy estándar MoProSoft.

Como Unidad de Verificación de Tecnologías de Información (UVTI) acreditada desde noviembre de 2005 por laEntidad Mexicana de Acreditación en los términos de la Ley Federal sobre Metrología y Normalización (LFMN), NYCE evalúa el cumplimiento de la norma NMX-I-059/02-NYCE-2011 (MoProSoft), determinando el nivel de madurez de la capacidad del proceso de las empresas, a las cuales se les otorga el correspondiente Dictamen.

¿Qué es la Verificación de la NMX-I-059/02-NYCE-2011 (MoProSoft)?

La verificación conforme a la norma mexicana NMX-I-059/02-NYCE-2011 consiste en determinar el nivel de madurez de los 9 procesos en las organizaciones que tienen como referencia el modelo MoProSoft.

¿Qué es CMMI?

CMMI es un método de probada eficacia para la gestión del rendimiento con décadas de resultados que muestran su funcionamiento.

Las organizaciones que utilizan CMMI tiene coste previsible, el calendario y los resultados empresariales de calidad que sirven como discriminadores entre sus competidores.

CMMI se construye con las prácticas y los objetivos vistos en miles de organizaciones en todo el mundo real. Utilice estas prácticas y metas para evaluar su propio desempeño y decidir qué se debe mejorar para que sus razones de negocio.

Sabemos que controlar procesos es complejo, por eso, te lo hacemos más fácil… Nos involucramos en tu realidad competitiva. Analizamos y definimos conjuntamente tus áreas de oportunidad para desarrollar e implementar el software. Afrontamos juntos con liderazgo tecnológico el presente y futuro de tu organización. Nuestras ventajas diferenciadoras... 1) Más de 620 proyectos exitosos. 2) Un modelo y procesos únicos, certificados. 3) Nuestros clientes son líderes en sus sectores. 4)  Somos expertos en desarrollo de software. Tu proyecto puede ser nuestro siguiente caso de éxito...

INTRODUCCIÓN En los temas anteriores se analizaron los diferentes tipos de Sistemas de Información y se mostraron características y funciones específicas de cada uno de ellos. Además de conocer los diferentes tipos de sistemas, es necesario analizar el proceso que puede seguirse para su desarrollo, con el fin último de poner a la disposición de las empresas y de los usuarios las ventajas que se derivan de los sistemas. Ahora  trataremos el tema del Desarrollo de Sistemas tomando en cuenta el ambiente actual que demanda calidad y competitividad y que está caracterizado por una creciente globalización. Para cumplir con este objetivo se explican las alternativas para que una organización pueda desarrollar un Sistema de Información. Existen dos tipos de software: software interno y software de aplicación. El primero es un conjunto de programas que nos permiten interactuar con el sistema computacional. Ejemplos de este software son los sistemas operativos como DOS, UNIX, OS/2 y WINNDOWS. El software de aplicación son los programas que resuelven problemas funcionales a los usuarios, como un sistema desarrollado para apoyar el proceso de toma de decisiones o un sistema transaccional. Aquí nos referiremos al software de aplicación y usaremos de manera indistinta las palabras software de aplicación y Sistema de Información, ya que ambas se refieren al mismo concepto. Por otro lado, debido a los avances tecnológicos existe una tendencia a la disminución de los costos de los recursos de hardware, mientras que los productos de software tienen una tendencia a la alza. Un ejemplo de esto es que las computadoras continúan bajando de precio (en dólares) y ofreciendo nuevas y mayores capacidades, mientras que el software continúa especializándose e incrementando sus costos. Lo anterior puede observarse en la figura 10.1. Este fenómeno explica la importancia que tiene el desarrollo de sistemas por los altos costos que origina en una organización. Un estudio realizado en diversas organizaciones respecto al desarrollo de software, reportó que el 25% de los proyectos iniciados fueron cancelados; menos del 1% de los proyectos fueron terminados en el tiempo que se estimó, con los requerimientos especificados por el usuario y dentro del costo presupuestado; los proyectos grandes concluyeron con más de un año de retraso y con el doble de los costos estimados. Estos resultados nos indican que es necesario analizar el proceso de desarrollo que se está siguiendo para determinar si es el adecuado y para mantener un esquema de competitividad en relación al desarrollo de los sistemas. Para llevar a cabo el desarrollo de sistemas es necesario contar con la infraestructura de equipo computacional adecuada para ello. Más adelante se propone una metodología para que el administrador de la función de información pueda elegir el equipo que mejor satisfaga los requerimientos de la empresa. Aquí se presentará la siguiente información: · El Ciclo de vida de los Sistemas de Información. · Impacto de la calidad en el proceso de desarrollo de sistemas. · Métodos alternos para la adquisición de sistemas. · Método tradicional. · Compra de paquetes. · Cómputo del usuario final. · Outsourcing. · Caso de aplicación. · Tendencias futuras. · Conclusiones  CICLO DE VIDA DE LOS SISTEMAS DE INFORMACIÓNAntes de analizar la calidad en el proceso de desarrollo de sistemas es importante explicar el ciclo de vida de los Sistemas de Información. En la figura 10.2 puede observarse este ciclo y las fases que incluye, tales como nacimiento, desarrollo, operación, mantenimiento y muerte. A continuación se explica de manera breve cada una de ellas. Nacimiento. Esta fase da inicio al ciclo de vida con el surgimiento de una necesidad o de un requerimiento por parte del usuario. En este momento debe hacerse un estudio de factibilidad para decidir si en realidad se justifica el desarrollo del sistema. Desarrollo. Una vez realizado un estudio de factibilidad, se procede al desarrollo del sistema en el cual se analizan los requerimientos y se elabora un diseño que servirá de base para el desarrollo. Además, se elaboran los programas necesarios para que el sistema pueda operar. La fase de desarrollo consiste en diseñar, construir y/o adecuar los programas que se requieren para resolver el problema del usuario. Operación. En este momento el sistema ya está terminado y el usuario trabaja introduciendo datos y obteniendo información y reportes que soporten la operación de la empresa. Si el sistema no satisface los requerimientos funcionales del usuario o si se detecta algún error en los programas, es necesario pasar a la fase de mantenimiento. Mantenimiento. Consiste en corregir los errores que se detectan en los programas o en las funciones que realiza el sistema. En esta fase además el usuario puede agregar nuevos requerimientos. Muerte. Un Sistema de información llega a esta fase cuando deja de ser necesario o cuando debe remplazarse por otro mejor. Si al sistema original se le hacen mejoras o cambios se inicia nuevamente el proceso, debido a que el sistema anterior ya ha muerto y se desarrollará uno nuevo.  IMPACTO DE LA CALIDAD EN EL PROCESO DE DESARROLLO DE SISTEMASUna vez que se ha analizado el ciclo de vida, hay que tomar en cuenta las variables que pueden impactar en el proceso de desarrollo. Estas variables, ilustradas en la figura 10.3, son: calidad, especificaciones del usuario, recursos y tiempo. Es importante que el usuario del sistema conozca las variables que afectan el proceso de desarrollo para que coopere lo más posible y evite que el sistema que desarrolle presente problemas durante su operación. Calidad se refiere a que el sistema satisfaga los requerimientos de confiabilidad y eficiencia de la mejor manera posible, y que éste no requiera mantenimiento o modificaciones una vez que se termina. Normalmente un sistema de buena calidad tiene alta duración en su ciclo de vida Por el contrario, si el ciclo de vida de un sistema es corto, puede asumirse que la calidad de este sistema es pobre. Especificaciones  del usuario son todos los requerimientos que define el usuario antes de iniciar el desarrollo del sistema, es decir, las funciones que necesita que realice. El sistema debe cumplir con todas las especificaciones y expectativas que tiene el usuario para que el proceso de se considere exitoso. Recursos son las personas que realizan el proceso de desarrollo, el equipo y el dinero necesario para el desarrollo del sistema. Un desarrollo adecuado y competitivo deberá consumir la cantidad mínima de recursos sin sacrificar calidad ni las especificaciones de los usuarios. Tiempo se refiere a la duración de todo el proceso de desarrollo, desde su inicio hasta que está en operación. El desarrollo de un Sistema de Información debe cumplir con las expectativas de tiempo que fijan de forma conjunta el analista del sistema y el usuario. Ahora, se analizará la relación que existe entre estas variables, ya que si alguna de las variables cambia durante el proceso puede producir un cambio en una o más de las otras variables. Por ejemplo: Si se incrementan las especificaciones del usuario, el tiempo de desarrollo puede aumentar de la misma manera que pueden necesitarse más recursos, esto puede provocar que haya una disminución en la calidad final  del  software. Si el usuario solicita que se agreguen más funciones a las definidas en el inicio se supone que será necesario incrementar los recursos asignados y el tiempo estimado si se desea cumplir con lo planeado. En caso de que no haya una reconsideración de estas variables la calidad  del  sistema puede verse afectada negativamente. Si el tiempo de terminación del software requiere acortarse es necesario incrementar los recursos (contratar más personal) o recortar las especificaciones del usuario, ya que debido a la limitante del tiempo no es posible cumplir con todo lo planeado y esto puede disminuir la calidad final del sistema. Si se desea incrementar la calidad del sistema puede ser necesario incrementar la cantidad de recursos asignados al proyecto y/o incrementar el tiempo asignado al proyecto. Si se quiere tener un producto final que tenga una calidad aceptable para una buena operación, deberá analizarse si los recursos asignados al proyecto y si su tiempo estimado de desarrollo son adecuados para cumplir con las especificaciones del usuario a través de un sistema de alta calidad. Puede observarse que el cambio en cualquiera de las variables impacta en la calidad del proceso de desarrollo de sistemas. Es importante que desde la fase inicial se definan los requerimientos de calidad del sistema, y así también establecer las especificaciones del usuario y estimar correctamente el tiempo y los recursos que se requieren. MÉTODOS ALTERNOS PARA LA ADQUISICIÓN DE SISTEMASUna vez que se analizan las variables que impactan en la calidad del desarrollo de sistemas y de conocer el ciclo de vida, es importante que una empresa u organización considere las tres diferentes fuentes o maneras de proveerse de sistemas. Cada una de éstas se explica a continuación: El método tradicional consiste en desarrollar el sistema internamente en la empresa o contratar servicios externos para ello. Esto se explicará más adelante al hablar de Outsourcing. En este método se desarrolla un sistema específico para las necesidades de una empresa en particular, en la mayoría de los casos se utiliza para desarrollar Sistemas Estratégicos debido a que no existen sistemas similares en el mercado. Por ejemplo, un sistema para determinar la mejor localización geográfica de una planta manufacturera o un sistema que pueda tomar información de competidores y proporcione alternativas de precios para la venta de un producto. La compra de paquetes consiste en adquirir paquetes desarrollados y terminados o desarrollados de manera parcial, por otras compañías que se encuentran en el mercado de desarrollo de software. Por ejemplo, comprar un paquete para el manejo de una caja registradora de una empresa comercial o un paquete que sirva para llevar la contabilidad. El cómputo del usuario final consiste en que el usuario final del sistema sea el que desarrolle sus propias aplicaciones, para esto utiliza las herramientas computacionales disponibles como son los paquetes y lenguajes de cuarta generación. Normalmente no se requieren conocimientos profundos de programación para este tipo de aplicaciones. Ejemplo de esto es un modelo de planeación financiera desarrollado directamente por el Gerente de Finanzas o utilizando Excel. Anteriormente el método tradicional era el más utilizado por las organizaciones, debido a la falta de paquetes disponibles y de herramientas fáciles de usar para el desarrollo de aplicaciones. Ahora es importante decidir si el sistema se desarrollará desde el inicio, se optará por comprar un paquete o por que el usuario final desarrolle su propia aplicación. En la figura 10.4 puede observarse el cambio que se ha dado en la forma de adquirir los sistemas a través del tiempo. MÉTODO TRADICIONALEl método tradicional de desarrollo consiste en una serie de fases consecutivas que inician con un estudio de factibilidad de la realización del proyecto y terminan con la operación  del  sistema. A este método se le conoce  como  cascada o caída de agua debido a que las fases son consecutivas. A pesar de que se sigue un orden en la realización de cada una de las fases, es posible regresar la fase anterior para hacer correcciones en caso de ser necesario. Al estar un sistema en operación el usuario puede darse cuenta si cumple con las funciones que requiere o si es necesario incrementar algunas otras. En este caso es necesario regresar a las fases anteriores y hacer las correcciones. La gráfica de este método es la siguiente: Las fases de que consta el método tradicional son las siguientes: Factibilidad. Consiste en realizar un estudio para determinar qué tan factible es el desarrollo del proyecto, considerando los aspectos técnicos y económicos. Debe analizarse si en realidad un Sistema de Información ayudará a lograr los objetivos que se pretenden o si no es conveniente realizarlo, ya que hay maneras mejores de cumplir con los objetivos. La factibilidad corresponde a la fase de nacimiento del ciclo de vida de desarrollo de sistemas, en la cual se parte de una necesidad o requerimiento del usuario y se decide realizar o no el sistema. Las fases de análisis, diseño, programación, pruebas e implantación del método tradicional corresponden a la fase de desarrollo que se presentó antes en el modelo del ciclo de vida de sistemas de la sección 10.2. Análisis. Consiste en determinar las especificaciones del usuario del sistema, pronosticar los recursos que serán necesarios y estimar el tiempo de desarrollo. En esta fase se definen los datos que se van a introducir al sistema y la información procesada que se generará vía reportes o pantallas de consulta. Es importante que el usuario responsable autorice por escrito el análisis antes de iniciar con el diseño. Diseño. Una vez realizado el análisis se prosigue con la fase de diseño, en la cual se traduce el análisis en forma de pasos o algoritmos que constituirán la base para la programación. En esta etapa se diseñan los procedimientos que servirán para cumplir con el objetivo del sistema y la forma de cómo entrarán los datos al sistema' Además, se especifica el proceso para producir los resultados deseados y la forma en que se van a transmitir esos resultados al usuario. Por último, se define la forma en que los datos se almacenarán en la computadora. Programación. Consiste en elaborar los programas considerados en el diseño para cumplir con lo especificado por el usuario. Si la fase anterior se realizó adecuadamente, los encargados de desarrollar los programas sólo deberán seguir la secuencia que se especifica en el diseño. En esta fase se inicia la elaboración de la documentaci6n del sistema, la cual servirá para que el usuario sepa cómo operar el sistema y qué hacer cuando se presente algún problema. Pruebas. Consiste en verificar si el sistema cumple con las especificaciones del usuario y su correcto funcionamiento; es decir, probar que haga lo que el usuario desea y que lo haga bien. Antes de implantar un sistema debe probarse utilizando datos ficticios y reales con el fin de cerciorarse de que está libre de errores, ya que si un error no se detecta, impactará de manera negativa durante la operación del sistema. Implantación. Consiste en instalar el sistema en el ambiente en que operará y en realizar los procesos necesarios para que opere correctamente. Al terminar esta fase el usuario puede iniciar con la operación real del sistema, para lo cual requerirá capacitación sobre el uso adecuado de cada una de las funciones que se realizan. En esta fase es muy importante que el usuario participe activamente para que la capacitación sea exitosa y después pueda operar el sistema en forma correcta. Operación. Consiste en que el usuario utilice el sistema desarrollado en el ambiente real de trabajo, es decir, que trabaje con él para cumplir con los objetivos deseados al momento de definirlo. Esta fase del método tradicional corresponde a la fase de operación presentada en el modelo del ciclo de vida de sistemas. Como ya se mencionó, las fases anteriores son consecutivas, el resultado de una es el inicio de la otra, pero es posible regresar a la fase anterior y, si es necesario, hacer correcciones o agregar nuevas funciones. Existen dos conceptos relacionados con el proceso de aseguramiento de la calidad durante el desarrollo del sistema al utilizar la alternativa del método tradicional: El usuario del producto desarrollado es el factor más importante en el establecimiento y evaluación de la calidad, es decir, el usuario es quién determina si el sistema satisface con sus requerimientos. Es mucho menos costoso corregir un problema de calidad en sus primeras etapas antes de que el problema se envuelva en quejas del usuario y resulte en crisis. Este concepto está ilustrado en la figura 10.6. En la gráfica se relaciona la naturaleza o tipo  del  error, es decir, la fase en que se generó el error versus la etapa en la cual se detectó el error. Así, si un error es detectado con mayor prontitud, será menos costoso corregirlo. En la gráfica el costo menor está indicado con la raya  del  "Modelo óptimo", luego con el número 1 y el mayor con 5. Lo óptimo o deseable es que los errores se detecten oportunamente, es decir, en la fase en que se generaron. Por ejemplo, un error de factibilidad debe detectarse en la fase de factibilidad, uno de diseño en la de diseño y así de forma sucesiva. Si un error de factibilidad se detecta en la fase de pruebas, resulta muy costoso corregirlo, si se observa en la gráfica, aparece un 5, en cambio si ese error se detecta en la fase de diseño es menos costoso (2 en la gráfica). Para poder lograr un modelo de desarrollo óptimo es necesario considerar en el proceso los siguientes aspectos: Aseguramiento de Calidad total?(T.Q.A: Total Quality Assurance) El proceso de desarrollo de sistemas involucra muchos riesgos, sobre todo en sus fases iniciales, en las cuales debe quedar bien definido, es por eso que las empresas que inicien el desarrollo del sistema deben asegurar desde las fases iniciales la calidad total del sistema terminado. El aseguramiento de calidad total consiste en controlar el sistema durante todo el proceso de desarrollo, estableciendo una responsabilidad activa a los usuarios. Deben estar involucrados desde el inicio el analista del sistema y el usuario responsable para lograr asegurar la calidad del producto terminado. Una de las acciones más fuertes que se derivan del concepto de Calidad Total es llevar a cabo en forma rutinaria revisiones estructuradas, con el fin de monitorear todo el proceso, detectar problemas y considerar las soluciones propuestas para la corrección de los problemas detectados durante el proceso de desarrollo. El objetivo de estas revisiones es evaluar el sistema conforme se va desarrollando y no esperar a que se concluya para determinar la calidad del mismo. Técnicas de Diseño y DocumentaciónEs necesario contar con técnicas adecuadas para realizar la fase de diseño y para tener documentado todo el proceso. El diseño de un sistema puede ser ascendente (bottom-up) o descendente (top-down). Cuando se realiza un diseño ascendente se inicia por los niveles operativos de la organización y, posteriormente, se definen los requerimientos de los niveles más altos, dependiendo de las necesidades de sistemas que se tengan. En el caso del diseño descendente, el diseñador parte de la estructura global de la empresa y de sus objetivos y busca la mejor manera de satisfacerlos al desarrollar el sistema. El diseño más recomendado es el descendente, debido a que integra a la organización en el sistema desde su inicio. Por otro lado, la documentación constituye un problema porque en ocasiones los estándares para realizarla se implantan después de que se llevó a cabo el proceso de desarrollo, además, documentar requiere de tiempo y de recursos, lo cual provoca que se realice mantenimiento al sistema sin contar con la documentación adecuada. Generalmente la documentación se realiza hasta que se concluye el desarrollo  del  sistema y en ocasiones con premura para cumplir con el tiempo estimado. Esto puede tener como consecuencia una calidad pobre en la documentación, y afecta después la operación y el mantenimiento del sistema. La documentación de un sistema debe proporcionar un panorama del mismo, especificar los procedimientos que se llevan a cabo y la forma de operarlo. Además de esta documentación, la cual con mayor frecuencia se dirige al usuario, debe documentarse y detallarse la estructura de archivos y programas con el objetivo de que pueda realizarse un mantenimiento adecuado. Pruebas del SistemaEste proceso se realiza con el fin de asegurar que el sistema esté libre de errores y debe de realizarse durante todo el proceso y no sólo en la fase final. La evaluación de un sistema involucra diferentes niveles y tiempos antes de que el sistema inicie su operación. Para realizar las pruebas puede utilizarse el modelo de Kendall & Kendall, el cual consta de cuatro tipos de pruebas. El primer tipo de pruebas se realiza a nivel de los programadores para comprobar los programas utilizando datos de prueba o ficticios. El segundo deben realizarlo los analistas para probar el funcionamiento entre los programas, utilizando para ello datos de prueba, para verificar que el sistema trabaje como una unidad. En el tercero participan los operadores, probando todo el sistema con datos de prueba y, por último, en el cuarto nivel participan los usuarios, probando todo el sistema con datos reales. Este modelo está ilustrado en la figura 10.7. Aquí se muestran las personas involucradas durante las pruebas del sistema y en cada una de ellas indica el nivel de la prueba que se realiza y el tipo de datos que se usa. Sólo en el caso de los usuarios el sistema se prueba con los datos reales, en los otros casos se usan datos ficticios. MantenimientoEs el proceso mediante el cual se realizan mejoras a un sistema para que tenga una vida útil mayor. También se le llama mantenimiento a las modificaciones que deben hacerse cuando el usuario cambia los requerimientos iniciales o cuando se detectan fallas durante la operación. En esta fase es necesario cuidar la calidad del sistema, de manera que se evite que se introduzcan errores e ineficiencias. Muchas organizaciones invierten recursos económicos cuantiosos para dar un buen mantenimiento a sus sistemas. Estos costos pueden llegar a elevarse a niveles alarmantes, por lo que se sugiere controlar estrictamente este renglón del presupuesto de Informática.  PrototipeoLa otra técnica en la estructuración de los sistemas es el prototipo o prototipeo.  El problema fundamental de este método es que en muchas aplicaciones, el determinar de antemano las necesidades es muy difícil la mayoría de las veces.  La técnica del prototipeo se basa en el siguiente principio fundamental: Los usuarios pueden indicar con mayor facilidad los dispositivos que más les gusten o les desagraden en un sistema ya existente que describirlos en un sistema imaginario o propuesto. El prototipo se estructura como un sistema de trabajo para permitir que los usuarios identifiquen los dispositivos esenciales en un sistema de información.  En esencia, es una versión experimental del nuevo sistema.  Cuando se utiliza en la evolución de los sistemas de información, el establecimiento de un prototipo no puede ser un proceso largo, ni tampoco el costo del modelo debe ser considerablemente diferente del costo del sistema eventual. Existen cinco pasos básicos para la creación de un prototipo: Identificar las necesidades conocidas de información del usuario. Elaborar un modelo de trabajo Utilizar el modelo o prototipo mencionando las mejoras y los cambios necesarios. Revisar el prototipo. Repetir los pasos anteriores según sea necesario. Durante el primer paso, tanto los analistas como el usuario determinan cuál es la información que debe producir el sistema e identificar los datos que deben ser procesados.  Este paso toma menos de una semana y, normalmente, se termina en una o dos sesiones de trabajo. La creación del prototipo de trabajo es responsabilidad de los analistas de sistemas. El prototipo del sistema consta de tres partes: interfase del usuario, rutinas de procesamiento y salida. Todos los diálogos con el usuario deben permitir entender fácilmente como alimentar los datos o las preguntas del sistema y cómo obtener resultados. Sin embargo, no necesita contener todos los mensaje o exhibir toda la información que normalmente se requieren en un sistema totalmente terminado y bien pulido.  COMPRA DE PAQUETESHay ocasiones en que una empresa necesita un sistema que ya se encuentra disponible en el mercado, en este caso resulta más costeable comprarlo que desarrollarlo utilizando el método tradicional. La compra de paquetes consiste en adquirir los sistemas que la empresa necesita, y ésta elige entre los que están disponibles en el mercado, es decir, ver y analizar los diferentes sistemas que ofrecen las empresas que se dedican sólo al desarrollo de paquetes y determinar cuál o cuáles son útiles para la empresa. Un error en la compra de paquetes puede impactar mucho en las operaciones diarias de una empresa, provocar un incremento en costos y, por consecuencia, una disminución de las utilidades y del nivel de servicio a clientes y usuarios. Debido a lo anterior, el comprador debe asegurarse de la calidad del sistema que está adquiriendo. Para ello debe tomar en cuenta lo siguiente: Que el paquete satisfaga todos los requerimientos del usuario, es decir, que cumpla con los objetivos. Que opere con alta confiabilidad, que no ocurran errores con frecuencia. Que sea entregado a tiempo para poder iniciar con su operación. Que cumpla con los requerimientos de presupuesto, que no sea muy costoso o que el costo se justifique. Este método difiere en varios aspectos del método tradicional: El desarrollo de un sistema utilizando el método tradicional involucra todos los costos asociados a él, es decir, el costo por el pago de las personas que participan en el proceso y el uso del equipo para el desarrollo. Cuando se opta por comprar un paquete debe cubrirse el costo del paquete y el de las modificaciones necesarias para adecuarlo a las necesidades de la empresa. Por otro lado, el tiempo que transcurre desde el estudio de factibilidad hasta la implantación y operación del sistema, utilizando el método tradicional, es mayor que al comprar un paquete en el mercado, ya que en el primer caso los programas deben ser desarrollados. En el caso de compra de paquetes los programas ya existen y solamente se requiere hacer las adecuaciones. Esto último debe ser menos tardado que desarrollar los programas partiendo de cero. En lo referente al mantenimiento del sistema, cuando se utiliza el método tradicional éste se hace internamente. Sin embargo, existe el riesgo de la rotación del personal, por lo que es necesario que exista buena documentación para facilitar dicho proceso. Cuando se compra un paquete el mantenimiento se realiza en forma externa a la empresa, lo cual generalmente resulta muy costoso. La empresa que compra el paquete debe tratar de negociar con el proveedor para que acepte que el mantenimiento lo haga ella misma. El método tradicional generalmente se utiliza cuando se desea un sistema hecho a la medida de las necesidades de la empresa, en este caso se llama sistema «ad?hoc» o específico a los requerimientos. Cuando se adquiere un paquete se trata de una aplicación general, en la cual será necesario modificar algunos aspectos para que funcione de acuerdo a las necesidades de la empresa, ya que el objetivo de un paquete es que sirva a la mayoría de los usuarios y no sólo a uno en particular. Al desarrollar un sistema utilizando el método tradicional debe tenerse cuidado con el tiempo estimado para realizar este proceso, no deben prometerse fechas demasiado optimistas, pues lo más probable será que no se cumplan. También debe tomarse en cuenta que puede existir rotación de personal durante el proceso de desarrollo y ello involucra que se retrase el avance del proyecto, pues será necesario capacitar a la persona nueva sobre lo que se está haciendo. En el otro enfoque (compra de paquetes) el usuario debe ser cuidadoso para no ser el «conejillo de indias» en el desarrollo y uso del paquete.  También, la empresa debe considerar al usuario antes de adquirir el paquete, ya que finalmente el usuario será quien lo opere y no debe asumir que van a necesitarse pocas modificaciones. La empresa debe estar consciente de que el costo de un paquete representa sólo una parte de los costos totales de la operación y mantenimiento. Al implantar un sistema se incurre en costos similares, tanto si se utilizó el método tradicional para desarrollarlo, como si se adquirió en alguna empresa. Esto se debe a que el proceso de implantanción debe realizarse independientemente del método utilizado para el desarrollo. La siguiente tabla muestra un resumen de lo anterior: Concepto Método Tradicional Compra de paquetes Costo Costo del desarrollo. Costo del paquete más el costo de las modificaciones necesarias. Tiempo Mayor. Menor. Mantenimiento Se realiza internamente. Se realiza en forma externa a la empresa. Tipo de aplicación «Ad?hoc» hecho a la medida. Aplicación general. Cuidado con: Fechas optimistas. Rotación durante el proceso No ser «conejillos de indias». Asumir que las modificaciones son menores. Tener el visto bueno del usuario antes de comprar. El costo del paquete puede ser mínimo con respecto al costo total. Implantación Costos similares. Costos similares CÓMPUTO DEL USUARIO FINALEl cómputo de usuario final se refiere al sistema que se desarrolla directamente por el usuario final, utilizando herramientas de desarrollo de alto nivel sin la participación operativa de analistas o programadores del área de Informática. Un ejemplo de esta alternativa es el desarrollo de un modelo de pronósticos en Excel, que se realice por un Gerente de Finanzas de una empresa, que es quien lo utilizará. Este método difiere en varios aspectos del método tradicional, algunos de los cuales se comentan a lo largo de esta sección. Cuando se desarrolla un sistema utilizando el método tradicional es necesario definir todos los requerimientos en la fase inicial de desarrollo, cuando el usuario desarrolla su propia aplicación los requerimientos se pueden ir integrando conforme se va realizando este proceso, ya que el mismo usuario es quien los define y desarrolla. El papel del analista de sistemas varía, en el caso del método tradicional es completamente responsable del análisis y del desarrollo, y en el caso del cómputo del usuario final únicamente asesora y aconseja a quien lo usará. Las herramientas que se utilizan para desarrollar sistemas siguiendo el enfoque del método tradicional son lenguajes de III y IV generación, tales como Pascal y Visual Basic; en cambio en el cómputo del usuario final se utilizan lenguajes de IV generación, debido a la facilidad que tienen para desarrollar aplicaciones sin necesidad de tener conocimientos muy profundos de programación. Además estos lenguajes tienen la característica de que son amigables, lo cual facilita su uso. Ejemplos de herramientas para que el usuario desarrolle sus propias aplicaciones son: Excel, Power Point y Word, entre otros. Las aplicaciones que el usuario final desarrolla para su uso generalmente son Sistemas de Soporte a la Toma de Decisiones, los cuales apoyan sus funciones y le permiten realizar análisis de sensibilidad para ver qué pasa si se presenta alguna situación en particular. Un ejemplo de lo anterior puede ser el tratar de analizar efecto que tiene sobre la utilidad del negocio el incremento en el precio de venta de algún producto. En el caso del método tradicional, con mayor frecuencia se desarrollan aplicaciones, que apoyan las operaciones transaccionales de una empresa o que recolectan información para apoyar el proceso de toma de decisiones. Tal puede ser el caso de un sistema de facturación o de nómina. La siguiente tabla muestra un resumen de lo antes explicado: Concepto Método Tradicional Cómputo de usuario final Identificación de necesidades 100% antes de iniciar el desarrollo. Se pueden detectar e integrar las necesidades durante toda la vida de la aplicación en forma directa por parte del usuario. Analista del sistema Es responsable 100% del análisis y desarrollo. El usuario participa en forma limitada. El usuario es el responsable. El analista sólo aconseja y asesora Herramienta de desarrollo Lenguajes de III y IV generación. Lenguajes de IV generación. Paquetes. Tipo de aplicación Nivel transaccional. Recolectores de información. Sistemas de Soporte a la Decisión (D.S.S.). Análisis de sensibilidad “What if”. Explotadores de información. Por otro lado. el desarrollo de sistemas por parte del usuario final puede presentar una serie de riesgos inherentes a la calidad del producto final, entre los cuales se pueden mencionar: Información incorrecta que se genera por una aplicación y que es consecuencia de fórmulas o modelos incorrectos, utilización de información obsoleta o no actualizada y falta de prueba de modelos. Esto se debe a que el usuario no es experto en el área de desarrollo de sistemas, por lo cual puede estar utilizando procedimientos incorrectos para generar su aplicación, sin tener cuidado de hacer pruebas y validar resultados. Por ejemplo, un ejecutivo que haga su propio modelo para proyecciones financieras, tal vez obtenga información incorrecta si no utilizó los modelos adecuados o si no hizo las pruebas suficientes. Desaparición de la fase de análisis, la cual constituye la base para el desarrollo de las demás fases. Generalmente el usuario final se enfoca al desarrollo de la aplicación sin considerar un análisis previo, esto puede ocasionar errores en el sistema, los cuales requerirán ser ajustados durante su operación. Proliferación de sistemas aislados debido a que cada quien desarrolla lo que necesita y es probable que se esté duplicando el trabajo dentro de la organización. Es muy importante tener un control sobre las aplicaciones que desarrolla un usuario, debido a que es probable que una misma aplicación sirva a diferentes usuarios y que cada uno de ellos la esté desarrollando. Debe minimizarse el esfuerzo, y esto se logra permitiendo que se comparta una aplicación con todos los usuarios que la necesitan. Reducción de la calidad y estabilidad de los sistemas desarrollados debido a que cada quien sigue sus propios estándares de desarrollo. La empresa debe tener establecidos los estándares de calidad para el desarrollo de sistemas y darlos a conocer a los usuarios interesados en desarrollar sus propias aplicaciones, para que sean cumplidos y se estandarice el desarrollo individualizado de sistemas. Especificaciones incompletas de los requerimientos del sistema debido a que se va realizando conforme se necesita. Esto se debe a que no se hace un planteamiento formal de cuáles son los requerimientos del sistema y éstos se van incorporando conforme el usuario se da cuenta de que los necesita. Los métodos de adquisición explicados antes (método tradicional, compra de paquetes y cómputo del usuario final) están relacionados con la evolución que han tenido los Sistemas de Información y con las etapas de Nolan que se mencionaron en el capítulo 1. En la figura 10.8 puede observarse esta relación. En cuanto a la evolución de los Sistemas de Información se tienen los Sistemas Transaccionales, los Sistema de Apoyo a las Decisiones y los Sistemas Estratégicos, cada uno de ellos está relacionado con un método de adquisición: compra de paquetes, cómputo del usuario final y método tradicional, respectivamente. Cuando una empresa se inicia en el uso de los Sistemas de Información, con frecuencia adquiere paquetes para automatizar las operaciones transaccionales, conforme va avanzando en las etapas de contagio y control busca automatizar actividades que apoyen el proceso de toma de decisiones, para lo cual es el propio usuario el que desarrolla sus aplicaciones. Al final. y mediante el método tradicional de desarrollo de sistemas. desarrolla Sistemas Estratégicos con el objetivo de obtener ventaja competitiva. En la parte inferior de la figura 10.8 pueden observarse las etapas mencionadas por Nolan en la evolución de sistemas: inicio, contagio, control, integración, administración de datos y madurez. Estas etapas, fueron explicadas en el capítulo 1. OUTSOURCINGEl desarrollo de sistemas en una empresa es un proceso que requiere una gran inversión en recursos, tanto económicos como humanos. Hay empresas en las cuales se justifica tener un departamento de sistemas interno, que sea el encargado de realizar todas las funciones de sistemas; sin embargo, en otras empresas no es rentable contar con un departamento de sistemas interno, debido a que están muy enfocadas a su actividad básica  y no tienen la experiencia necesaria en el área de sistemas. Para estas empresas que desean concentrarse más en su actividad principal y tener buenos sistemas existe una opción apropiada: Outsourcing. Outsourcing consiste en contratar en forma externa algunos o todos los servicios que proporciona un departamento de Sistemas de Información. Este concepto se basa en dos aspectos: primero, una empresa debe concentrar sus esfuerzos en aquellas actividades que sabe hacer y, segundo, una empresa debe utilizar las ventajas de las economías de escala y de las economías de expertise o experiencia que tienen las empresas que se dedican exclusivamente a proporcionar servicios de Sistemas de Información. Por ejemplo, una empresa manufacturera debe dedicarse a producir los bienes que fabrica, un banco debe dedicarse a manejar el dinero y una empresa de sistemas debe dedicarse a sistemas. Outsourcing es un concepto relativamente nuevo, en 1989 Kodak hizo un trato con IBM para subcontratar sus servicios de Informática. Este hecho marcó el inicio y el éxito que tiene este servicio en la actualidad. Ventajas del OutsourcingUtilizar outsourcing tiene numerosas ventajas,  las principales son ahorro en costos mediante economías de escala y consolidaciones (ya que la empresa que ofrece el outsourcing se especializa en ello), una mayor liquidez al:  deshacerse de equipo computacional que ya no es necesario para el desarrollo de sistemas (solo para la operación) y un decremento de los gastos por depreciación de equipo. como consecuencia de la disminución en el equipo computacional. Por otro lado, el outsourcing proporciona acceso a los avances tecnológicos sin inversión de capital, debido a que la empresa que realiza el outsourcing es quien debe invertir en ello para después recomendarlo a sus clientes. También permite la descentralización de actividades en la empresa, ya que generalmente el área de sistemas está centralizada, además de tener  acceso a utilerías para recuperas y respaldar sistemas, mismas que son proporcionadas por la empresa que realiza el outsourcing. De manera paralela. es posible convertir al departamento de sistemas de la empresa en un centro de utilidades, ya que se dedicará a ofrecer servicios de outsourcing a otras empresas. Desventajas  del  OutsourcingEl outsourcing tiene numerosas ventajas, esto puede verse en lo antes mencionado; sin embargo, también tiene algunas desventajas. Una de las principales desventajas de este servicio es la pérdida de control sobre el proceso desarrollo, ya que el usuario no está cien por ciento involucrado en ello. También el outsourcing puede ocasionar costos por cambio o conversión a nuevas tecnologías que son recomendadas por la empresa que brinda el servicio y cambios organizacionales que pueden causar problemas, ya que lo más probable es que el área de sistemas disminuya su número de empleados. Cuando se contrata un servicio externo de sistemas es importante que se negocien los siguientes aspectos, entre otros: Características del servicio, qué incluye y determina la manera en que se proporcionará Tiempos de entrega y fechas estimadas. Estándares de desempeño. Las condiciones en caso de cancelar el contrato. Condiciones sobre personal transferido temporalmente a la empresa que realiza el outsourcing. Los derechos de propiedad sobre el servicio prestado.  La confidencialidad del trabajo realizado. El ajuste de los precios dependiendo de la inflación.  El soporte que brinda una vez terminado el servicio. Los beneficios por avances tecnológicos. La flexibilidad del contrato en cuestiones no consideradas al principio. El outsourcing puede proporcionar innumerables ventajas si se utiliza adecuadamente y si la empresa está preparada para llevar de esta manera los Sistemas de Información. Antes de contratar este servicio debe hacerse un análisis de la empresa para ver que posibles cambios generará y cómo canalizar de la mejor manera los problemas que pudieran presentarse. TENDENCIAS FUTURASEl alto costo del método de desarrollo tradicional y el crecimiento de la cantidad de diferentes aplicaciones, ha hecho muy atractivo el uso de paquetes para los usuarios. La tendencia actual es ver el software como cualquier otro producto terminado, el cual puede ser desarrollado y vendido en diferentes países. Esto introduce un concepto que impactará el mercado de software en los próximos años: la globalización del software o como algunos autores la llaman: la internacionalización del software. Se han realizado proyectos conjuntos en donde interactúan países desarrollados con países en desarrollo contando con personal especialista en Sistemas de Información, Sistemas Computacionales y Bases de Datos. Es necesario estar preparados para ello. La realización de proyectos conjuntos generan ventajas tanto para los países desarrollados como para los países que están en vías de desarrollo. Las ventajas para los países desarrollados son: Disminución de los costos de desarrollo de software principalmente en lo referente a la mano de obra (disminuyen entre un 10 y 40%). Esto se debe a que para un país desarrollado es menos costoso contratar mano de obra especializada de un país en vías de desarrollo. Penetración en nuevos mercados que son atractivos. Esto permite estrechar lazos comerciales con países en desarrollo abriendo un mercado potencial de nuevos compradores para sus productos. Los países en desarrollo constituyen un mercado muy fuerte para la introducción de productos por parte de los países desarrollados, si se realizan proyectos conjuntos habrá más oportunidad de ampliar los mercados para sus productos en los países en vías de desarrollo. Por otra parte, las ventajas para los países en desarrollo son: Son receptores en la transferencia de la tecnología. Esto se logra al realizar proyectos conjuntos que absorban con rapidez la tecnología de punta, permitiendo administrar los proyectos de software, utilizar conceptos de ingeniería de software y herramientas productivas para el desarrollo. Obtienen beneficios relacionados con ingresos económicos que reciben los profesionistas que se involucran en proyectos conjuntos. Otra tendencia que es importante considerar es el incremento en el uso de tecnologías de integración para el desarrollo de sistemas, específicamente de CASE (Computer Aided Software Engineering), que es una herramienta que permite mejorar las tareas rutinarias automatizándolas e integrando el desarrollo de un sistema desde su fase inicial hasta la final. Utilizar herramientas CASE incrementa la productividad, permite una mejor comunicación entre los usuarios e integra todo el ciclo de desarrollo. Casi a la par con el uso de las herramientas CASE se está incrementando la utilizaci6n de tecnologías orientadas a objetos, las cuales cambian radicalmente el enfoque tradicional y estructurado de realizar el desarrollo de sistemas con base en funciones. La tecnología orientada a objetos se basa más que en funciones en los objetos sobre los cuales se realiza la función, o sobre los que son responsables de realizarla. Por ejemplo, un objeto puede ser un botón de aceptar o cancelar en una sección de un sistema. Una ventaja importante de la tecnología orientada a objetos es que promueve la reutilizaci6n de partes de un sistema por otros sistemas diferentes, con lo cual se ahorra tiempo de desarrollo. Para ilustrar la reutílizaci6n veamos el siguiente ejemplo: la primera vez que se ensambla un carro es necesario hacer cada una de sus partes y tenerlas disponibles en cierto orden, cuando se desea ensamblar otro carro pueden reutilizarse piezas del primer vehículo.  CONCLUSIONESPara lograr la calidad integral en el software de aplicación que utilice una empresa es necesario lograr la calidad en cualquier método que se elija, ya sea el método tradicional, la compra de paquetes o el cómputo del usuario final. El concepto de calidad en el software pasará de ser una variable en el mercado a una constante en todos los productos; es decir, para que un producto permanezca en el mercado deberá cumplir con ciertos estándares de calidad. La globalización del software será muy pronto una realidad debido a razones de índole económico Los productos a desarrollar en forma conjunta deberán ser seleccionados con mucho cuidado para asegurar su éxito. El reto de las empresas será cómo disminuir el costo de desarrollo de software, sin sacrificar la calidad del mismo.

Alquilar o comprar?Arrendamiento vs Compra - más que una decisión númerosPreocupada por el alto costo de la adquisición de tecnología de la información (IT), y si incluso se lo puede permitir?En comparación con la compra y la propiedad absoluta de los equipos informáticos, arrendamiento ofrece una serie de atractivos beneficios, incluyendo la asequibilidad, que abarcan todo el ciclo de vida de su solución de TI.Arrendamientos y otras soluciones de financiación de IBM Global Financing puede acelerar la adquisición de equipos informáticos y soluciones, incluyendo hardware, software y servicios.Es un modelo asequible para todas las empresas y organizaciones de tamaño y ayuda a reducir el coste total de propiedad y proteger su empresa contra obsolescencia de la tecnología y el riesgo financiero.Además de conservar el capital, el arrendamiento a través de IBM Global Financing ofrece una incomparable flexibilidad tecnológica y agilidad del mercado por lo que le permite actualizar a la última tecnología en el medio de su período de arrendamiento con poco o ningún aumento en sus pagos mensuales. Esto permite a su empresa para estar siempre a la vanguardia en esta era de rápido cambio tecnológico.Al arrendar a través de IBM Global Financing, básicamente estás usando nuestro dinero para pagar por su tecnología y la celebración en su propio capital para apoyar a todos sus otros gastos importantes de negocios e inversiones esenciales. Además, se enciende costes iniciales en pagos mensuales asequibles que se pueden controlar cómodamente.Vamos a IBM Global Financing trabajo con usted para crear una solución de leasing que apoya su estrategia de negocio y las necesidades financieras. Nuestras ofertas ayudan a maximizar el flujo de caja para la vida útil de su adquisición, así como ayudar en la eliminación de su equipo en la final de su contrato de arrendamiento de una manera segura y ambientalmente seguro.

KC Rentas es una empresa líder en el ramo de  renta de equipo de cómputo y audiovisual a corto, mediano y largo plazo. Buscamos ofrecer a nuestros clientes, equipo de alta calidad a precios accesibles. En KC Rentas enfrentamos los nuevos retos sobre bases sólidas, con una clara conciencia de lo que somos y lo que aspiramos ser en el futuro, orientando nuestras estrategias y acciones hacia un objetivo común. En suma, nuestro compromiso es que Ud., estimado cliente, se sienta satisfecho con la calidad de nuestros servicios y así lograr desarrollar relaciones comerciales de largo plazo. KC Rentas una empresa del Grupo Kapali con más de 8 años de experiencia La renta a largo plazo o Arrendamiento puro, es una de las opciones que están surgiendo con fuerza en México para conseguir recursos económicos y así financiar los activos que se necesitan para que un negocio pueda ser más competitivo en el sector en el que se desenvuelve. Este producto permite al  usuario el uso y goce del bien por un periodo determinado mediante el pago de rentas periódicas. Es por eso que en KC Rentas le ofrecemos atractivos planes de renta de equipo a largo plazo. Beneficios de la renta a largo plazo (Arrendamiento puro): Importantes ventajas fiscales, financieras y operativas. Rentas fijas mensuales. Periodos que van desde 6, 12, 18, 24 y hasta 36 meses. Diferentes opciones al finalizar la renta. Promociones en renta HP Compaq 8200 Elite Corei5   >> HP Compaq 8100 Elite CMT Core i3 3.2  >> HP Designjet serie T1100  >> PC RENT Es una marca comercial operada bajo la razón social de Recycle Tech S.A. de C.V. con más de 15 años de antiguedad en el mercado de arrendamiento de equipo de cómputo y audiovisuales, así como en la venta de equipo usado y administración de "End of Leases". Somos una compañia lider en el segmento de empresas dedicadas al arrendamiento y venta del equipo de cómputo. División Rentas • Arrendamiento Puro de Soluciones de TI (Cómputo, Computo Portátil, Impresión, Redes, Servicios Administrados de TI, y mucho más). División Ventas • Venta de Soluciones de Soluciones de TI (Cómputo, Computo Portátil, Impresión, Redes, Servicios Administrados de TI, Equipo Nuevo y Usado). División Servicios y Soporte Técnico • Implementación de Servicios y Soluciones relacionadas con sus Operaciones de Tecnología de Información para su óptimo funcionamiento.                Intranet Casos de exito Atencion al cliente Bolsa de trabajo Saiti Timeline Aviso de privacidad SUSCRIBIRSE NEWSLETTER    PC RENT Todos los Derechos Reservados. México 2013 Calle Pirul No.34-B, Col. Bellavista, Tlalnepantla Edo de Mé xico C.P. 54080, Tel: 53.19.40.63 Queda prohibida la reproducción total o parcial de esta pagina y s

Gran cantidad de inventario. Todo tipo de equipo. Las mejores marcas. Precios muy atractivos.       Entregas puntuales. Equipo listo para usarse. Servicio nacional con envíos a toda la República Mexicana. Servicio de entrega y recolección a domicilio. Servicios opcionales de configuración e instalación de redes y puesta a punto.

Esto