Unidad III Sistemas de Informacion

1. UNIDAD IV ALTERNATIVAS
DE ADQUISICIÓN DE
SISTEMAS DE
INFORMACION
Elizabeth Farias

2. EL CICLO DE VIDA DEL
DESARROLLO DE SISTEMAS.
Elizabeth Farías

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

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

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

9. 4.2 PROTOTIPOS :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”

10. El desarrollo orientado a
prototipos
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.

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

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

13. Tipos de prototipos.
Prototipito de interfaz de usuario: modelos de
pantallas.
Prototipito 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).

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

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

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

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

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

19. Elizabeth Farías

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

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

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

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

24. FASES

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:

25. FASES
 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 súbase es
desarrollar un diseño básico para el prototipo inicial.
 Diseño y construcción. El objetivo de esta súbase 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.
•

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

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

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

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

30. Un escenario para la
construcción de prototipos
 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.

31. Un escenario para la construcción de
prototipos
 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:

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

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

34. Comunicación
Plan
rápido
Modelado
Desarrollo,
entrega
retroalimentación
Construcción
del prototipo
Elizabeth Farías

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

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

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

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

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

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

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

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

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

44. 4.3 Adquisición 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.
 Como Unidad de Verificación de Tecnologías de Información (UVTI) acreditada desde
noviembre de 2005 por la Entidad 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.

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

46. Elizabeth Farías

47. GRACIAS
POR SU
ATENCION