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 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.
10. 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.
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.
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. Rápido o desechable:
Sirve al análisis y validación de los requisitos.
Después se redacta la especificación del sistema y se desecha el prototipo.
La aplicación se desarrolla siguiendo un paradigma diferente.
Problema: cuando el prototipo no se desecha, y termina convirtiéndose en el
sistema final.
Evolutivos:
Comienza con un sistema relativamente simple que implementa los requisitos
más importantes o mejor conocidos.
El prototipo se aumenta o cambia en cuanto se descubren nuevos requisitos.
Finalmente, se convierte en el sistema requerido.
Actualmente se usa en el desarrollo de sitios Webs y en aplicaciones de
comercio electrónico.
15. 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.
16. 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?
17. 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.
19. 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.
20. 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.
21. HERRAMIENTAS:
Generadores de interfaz (4GLs, Visual Basic, etc.).
Editores de páginas Web.
Herramientas CASE.
- Formularios, pantallas, generación de código…
Bocetos en papel.
Aplicaciones de dibujo
- Harward Graphics, etc.
MS PowerPoint.
Etc.
22. 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.
23. Diseño técnico. Durante la construcción del prototipo, el desarrollador ha
obviado el diseño detallado. El sistema debe ser entonces rediseñado y
documentado según los estándares de la organización y para ayudar a
las mantenciones futuras. Esta fase de diseño técnico tiene dos etapas:
por un lado, la producción de una documentación de diseño que
especifica y describe la estructura del software, el control de flujo, las
interfaces de usuario y las funciones y, como segunda etapa, la
producción de todo lo requerido para promover cualquier mantención
futura del software.
Programación y prueba. Es donde los cambios identificados en el diseño
técnico son implementados y probados para asegurar la corrección y
completitud de los mismos con respecto a los requerimientos.
Operación y mantención. La instalación del sistema en ambiente de
explotación, en este caso, resulta de menor complejidad, ya que se
supone que los usuarios han trabajado con el sistema al hacer las
pruebas de prototipos. Además, la mantención también debería ser una
fase menos importante, ya que se supone que el refinamiento del
prototipo permitiría una mejor claridad en los requerimientos, por lo cual
las mantenciones perfectivas se reducirían. Si eventualmente se
requiriese una mantención entonces el proceso de prototipado es
repetido y se definirá un nuevo conjunto de requerimientos.
24. 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.
25. 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.
26. 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.
28. 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.
29. 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.
30. 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:
31. 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.
32. 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.
33. 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.
34. 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.
35. 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.
36. 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.
37. 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.
38. 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:
39. ENTRADA O
INSUMOS
PROCESOS SALIDA DEL
PRODUCTO
-ESTUDIANTES
-PROFESORES
-LABORATORIO
-BIBLIOTECA
-ACADEMICOS
-
INVESTIGACIO
N
-EXTENSION
-
ADMINISTRATIV
OS
-EGRESADOS
-PATENTES
-ASESORIAS
-SERVICIOS
Lopez Natalia
40. 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.
41. 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.
43. 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
44. 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”.
45. 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.
46. 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:
47. 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.).
48. 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.
49. 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.
