Sistemas de Información Unidad IV

1. Jesus Garcia Maldonado

2. Jesús García

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

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

19. Jesús García

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

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

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

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

34.  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:

35. Jesús García

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

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

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

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

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

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

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

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

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

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

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

47. Jesús García

48. GRACIAS POR
SU ATENCION