Este documento presenta información sobre el desarrollo de sistemas de información y el uso de prototipos. Explica las fases del ciclo de vida del desarrollo de sistemas, incluida la identificación de problemas, determinación de requisitos, análisis de necesidades del sistema y diseño del sistema recomendado. También describe los tipos de prototipos, como los prototipos de interfaz de usuario y evolutivos, y las herramientas de prototipado como lenguajes de programación y ensamblaje de componentes. Finalmente, resume las

1. Unidad IV Alternativas
de Adquisicion de
Sistemas de
Informacion
Garcia Cassandra

2. El Ciclo de de vida del desarrollo
de Sistemas
Garcia Cassandra

3. 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.

4. 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ípica mente los
administradores de las operaciones y los trabajadores de las operaciones.

5. 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.

6. Diseño del sistema
recomendadoEn 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.

7. 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.

8. PROTOTIPOS
INFORMÁTICOS
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.

9. 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.

10. 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.

11. 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.

12. 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?

13. 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.

14. Ensamblaje de componentes y
aplicaciones
El desarrollo de prototipos con reutilización comprende dos niveles:
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.

15. 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.

16. 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.

17. 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.

18. 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.

19. 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.
Garcia Cassandra

20. 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.

21. 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.

22. 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.

23. 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.

24. Garcia Cassandra

25. 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
Garcia Cassandra

26. 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.

27. 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:
Garcia Cassandra
Garcia Cassandra

28. 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.

29. 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
Garcia Cassandra

30. 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 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”.

31. 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.

32. 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:
Crear y mantener la base de datos: esto es agregar, eliminar y modificar tablas.
Extraer y presentar información que cumpla ciertas condiciones.
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.).
Ordenar los registros (tablas), según el campo clave.
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.).

33. 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.

34. 4.3 Adquisicion de sistemas de informacion.
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.

35. 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.
Estos 9 procesos están contenidos en tres categorías: Alta Dirección (DIR), Gerencia (GER)
y Operación (OPE), lo que asegura una cobertura total en la organización. Se determina el
nivel de madurez de capacidades para cada proceso verificado, y con base en ello, el nivel
de madurez de capacidades de la organización que es el máximo nivel de capacidad
alcanzado por todos los procesos de MoProSoft.

36. Garcia Cassandra

37. GRACIAS POR
SU ATENCION
Garcia Cassandra