MODELO DE PROTOTIPOS
El modelo de prototipos permite que todo el sistema, o algunos de sus partes, se construyan rápida rápidamen mente te para para compre comprender nder con facili facilidad dad y aclara aclararr cierto ciertoss aspecto aspectoss en los que se aseguren que el desarrollador, el usuario, el cliente estén de acuerdo en lo que se necesita así como también la solución que se propone para dicha necesidad y de esta forma minimi minimizar zar el riesg riesgo o y la incert incertidu idumbr mbree en el desarr desarroll ollo, o, este este modelo modelo se encarg encargaa del desarrollo de diseños para que estos sean analizados y prescindir de ellos a medida que se adhieran nuevas especificaciones, es ideal para medir el alcance del producto, pero no se asegura su uso real. !hari "a#rence, $%%$& Este modelo modelo principalmente principalmente se aplica cuando cuando un cliente cliente define un con'unto de ob'etivos ob'etivos generales para el soft#are a desarrollarse sin delimitar detalladamente los requisitos de entrada procesamiento y salida, es decir cuando el responsable no está seguro de la eficacia de un algoritmo, de la adaptabilidad del sistema o de la forma en que interact(a el hombre y la máquina. Este modelo se encarga principalmente de ayudar al ingeniero y al cliente a entender de me'o me'orr maner maneraa cuál cuál será será el resu result ltad ado o de la cons constr trucc ucció ión n cuand cuando o los los requ requis isit itos os esté estén n satisfechos
1. Característ Características icas de los prototip prototipos os
)uncionalidad limitada. *oca fiabilidad. +aracterísticas de funcionalidad pobres. lto lto grado grado de parti participa cipació ción n del usuari usuario o el cual eval(a los protot prototipo ipos, s, propone propone
me'oras y detalla requisitos. lto grado de participación del analista de sistemas, ya que en muchos casos los
usuarios no pueden indicar los requisitos sin tener e-periencia c on el sistema. El prototipo da mayor conocimiento al usuario y analistas ayudando a que el usuario
aprenda a utilizar el sistema.
2. Uso de prot protot otip ipo o
!e presenta al cliente un prototipo para su e-perimentación. yuda al cliente a establecer claramente los requisitos.
yuda a los desarrolladores a
/alidar corrección de la especificación. prender sobre problemas que se presentarán durante el diseño e implementación del sistema. 0e'orar el producto. E-aminar viabilidad y utilidad de la aplicación.
3. Tipos de prototipos. 3.1. Prototipado de interfaz de usuario: modelos de pantallas. 3.2. Prototipado funcional operacional!: implementa algunas funciones, y a medida
que se comprueba que son las apropiadas, se corrigen, refinan, y se añaden otras. 3.3. Modelos de rendi"iento: eval(an el rendimiento de una aplicación crítica no sirven al análisis de requisitos&. 3.4.
Rápido o desechable:
!irve al análisis y validación de los requisitos. 1espués se redacta la especificación del sistema y se desecha el prototipo. "a aplicación se desarrolla siguiendo un paradigma diferente. *roblema cuando el prototipo no se desecha, y termina convirtiéndose en el sistema final.
3.5.
Evolutivos:
+omienza con un sistema relativamente simple que implementa los requisitos más importantes o me'or conocidos. El prototipo se aumenta o cambia en cuanto se descubren nuevos requisitos. )inalmente, se convierte en el sistema requerido. ctualmente se usa en el desarrollo de sitios 2ebs y en aplicaciones de comercio electrónico.
3.6.
Vertical
1esarrolla completamente alguna de las funciones.
3.7.
Horizotal
1esarrolla parcialmente todas las funciones.
!. "ases del desarrollo del #odelo "as fases que comprende el método de desarrollo orientado a prototipos serían #.1. In$esti%aci&n preli"inar. "as metas principales de esta fase son 1eterminar el problema y su ámbito, 1eterminar la importancia y sus efectos potenciales sobre la organización 3dentificar una idea general de la solución para realizar un estudio de factibilidad
que determine la factibilidad de una solución soft#are. #.2. Definici&n de los re'ueri"ientos del siste"a. El ob'etivo de esta etapa es
registrar todos los requerimientos y deseos que los usuarios tienen en relación al proyecto ba'o 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.
$álisis de los re%ueri#ietos: Esta etapa es u proceso %ue busca apro&i#ar las visioes del usuario ' del desarrollador #ediate sucesivas iteracioes. (ara la de)ici* de los re%ueri#ietos tee#os cico etapas etre dos de las cuales se establece u ciclo iteractivo
4.3.
(n)lisis %rueso * especificaci&n: En esta fase se busca desarrollar un diseño básico
para el prototipo inicial. Dise+o * construcci&n: "o que se consigue en esta fase en obtener un prototipo inicial, aquí el desarrollador debe concentrarse en construir un sistema con la má-ima funcionalidad, poniendo énfasis en la interfaz del usuario. E$aluaci&n: "os ob'etivos de esta etapa son obtener por parte de 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. !e modifica y se eval(a cuantas veces sea necesario hasta que los requerimientos del sistemas sean satisfechos.
En el proceso de evaluación se efect(an cuatro pasos separados 4 4 4 4
*reparación. 1emostración. 5so del prototipo. 1iscusión de comentarios.
Esta es la fase en donde se decide si el prototipo es aceptado o modificado. Modificaci&n: !e da cuando la definición de requerimientos del sistema es alterada
en la etapa de evaluación. El desarrollador entonces debe modificar el prototipo de
acuerdo a los comentarios hechos por los usuarios. T,r"ino: 5na 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.
#.#. Dise+o t,cnico. 1urante 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 4
fase de diseño técnico tiene dos etapas "a producción de una documentación de diseño que especifica y describe la
4
estructura del soft#are, el control de flu'o, las interfaces de usuario y las funciones "a producción de todo lo requerido para promover cualquier mantención futura del soft#are.
#.-. Pro%ra"aci&n * pruea. 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. "as pruebas serán de realizarse tantas veces sea necesarias para verificar cualquier tipo de anomalía en el sistema. #./. Operaci&n * "antenci&n. "a instalación del sistema en ambiente de e-plotación,
en este caso, resulta de menor comple'idad, ya que se supone que los usuarios han traba'ado con el sistema al hacer las pruebas de prototipos. demá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 me'or claridad en los requerimientos, por lo cual las mantenciones perfectivas se reducirían. !i eventualmente se requiriese
una mantención entonces el proceso de prototipado es repetido y se definirá un nuevo con'unto de requerimientos.
+. Veta,as de la aplicaci* del #odelo de prototipos "as venta'as de un enfoque de desarrollo orientado a prototipos están dadas por
Este modelo es (til cuando el cliente conoce los ob'etivos generales para el soft#are, pero no identifica los requisitos detallados de entrada, procesamiento o
salida. 6ambién ofrece un me'or enfoque cuando el responsable del desarrollo del soft#are está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema
operativo o de la forma que debería tomar la interacción humano4máquina. 7o modifica el flu'o del ciclo de vida. 8educe el riesgo de construir productos que no satisfagan las necesidades de los usuarios. 8educe costos y aumenta la probabilidad de é-ito. E-ige disponer de las herramientas adecuadas. 7o presenta calidad ni robustez. 5na vez identificados todos los requisitos mediante el prototipo, se construye el producto de ingeniería
-. esveta,as de la aplicaci* del #odelo de prototipos !i bien, el desarrollo orientado a prototipos tiene considerables venta'as, también presenta desventa'as como
El usuario tiende a crearse unas e-pectativas cuando ve el prototipo de cara al sistema final. causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su función. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco
recomendado "a dependencia de las herramientas de soft#are para el é-ito ya que la necesidad de disminución de incertidumbre depende de las iteraciones del prototipo, entre
más iteraciones e-ista me'or y esto (ltimo se logra mediante el uso de me'ores
herramientas lo que hace a este proceso dependiente de las mismas. 6ambién, no es posible aplicar la metodología a todos los proyectos de soft#are y, finalmente, la mala interpretación que pueden hacer los usuarios del prototipo, al
cual pueden confundir con el sistema terminado. 7o se puede desconocer que la fase de definición de requerimientos se ha perfeccionado en dos aspectos importantes primero se ha apro-imado las visiones del usuario y el desarrollador, lo cual representa el beneficio de establecer una base com(n de comunicación9 también, el hacer e-plícita la posibilidad de iterar sobre estos dominios permitiría que la convergencia de los mismos sea una posibilidad cierta.
/. Esceario para la costrucci* de prototipos 6odos los proyectos de ingeniería de soft#are comienzan con una petición del cliente. "a petición puede estar en la forma de una memoria que describe un problema, un informe que define un con'unto de ob'etivos comerciales o del producto, una petición de propuesta formal de una agencia o compañía e-terior, o una especificación del sistema que ha asignado una función y comportamiento al soft#are, como un elemento de un sistema mayor basado en computadora. !uponiendo que e-iste una petición para un programa de una de las formas dichas anteriormente, para construir un prototipo del soft#are se aplican los siguientes pasos
P(SO 1. Evaluar la petición del soft#are y determinar si el programa a desarrollar
es un buen candidato para construir un prototipo. 1ebido a que el cliente debe interaccionar con el prototipo en los (ltimos pasos, es e sencial que :& el cliente participe en la evaluación y refinamiento del prototipo, y $& el cliente sea capaz de tomar decisiones de requerimientos de una forma oportuna. )inalmente, la naturaleza del proyecto de desarrollo tendrá una fuerte influencia en la eficacia del prototipo.
P(SO 2. 1ado un proyecto candidato aceptable, el analista desarrolla una
representación abreviada de los requerimientos. ntes 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. "a aplicación de estos principios de análisis fundamentales, pueden realizarse mediante los métodos de análisis de requerimientos.
P(SO 3. 1espués de que se haya revisado la representación de los requerimientos,
se crea un con'unto de especificaciones de diseño abreviadas para el prototipo. El diseño debe ocurrir antes de que comience la construcción del prototipo. !in 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.
P(SO #. El soft#are del prototipo se crea, prueba y refina 3dealmente, los bloques
de construcción de soft#are pree-isten se utilizan para crear el prototipo de una forma rápida. 1esafortunadamente, tales bloques construidos raramente e-isten. 3ncluso si la implementación de un prototipo que funcione es impracticable, es escenario de construcción de prototipos puede a(n aplicarse. *ara las aplicaciones interactivas con el hombre, es posible frecuentemente crear un prototipo en papel que describa la interacción hombre4máquina usando una serie de ho'as de historia.
P(SO -. 5na 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 e-aminar una representación implementada de los requerimientos del programa, sugerir modificaciones que harán al programa cumplir me'or las necesidades reales.
P(SO /. "os pasos = y > se repiten iterativamente hasta que todos los
requerimientos estén formalizados o hasta que el prototipo haya evolucionado hacia un sistema de producción.
0. EE(4: *rototipo informático para la evaluación de la calidad de la educación superior
8.1.
e)ici* del (roble#a:
"as 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 ob'eto de lograr un desarrollo más armónico y planificado, en atención a una estricta observación de su misión. ?a'o esta perspectiva se ofrece una propuesta de *rototipo 3nformático para la Evaluación de la +alidad de la Educación !uperior, cuyos ob'etivos, entre otros, son fomentar e incentivar la cultura de evaluación de la calidad universitaria9 diseñar indicadores de gestión universitaria para dicho sistema de información, para cada uno de los ámbitos académico, investigación, e-tensión y administrativo. *ara 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 misma9 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 interdependientes9 esto es, cada nivel con su vista de usuario en la base de datos. !e aplica la metodología modular de sistemas, el enfoque de arriba hacia aba'o y el diseño de base de datos relacional. El prototipo está diseñado ba'o 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
0odelo 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. !erá el utilizado para el prototipo informático propuesto, ya que ofrece todas las bondades de la metodología de sistemas.
En el modelo de evaluación propuesto para el prototipo de evaluación de la calidad universitaria, se perfilan tres bloques, como lo muestra la gráfica siguiente
@
Entrada estaría constituida por las inversiones, tanto en recursos materiales como
humanos. En otras palabras salas, talleres, bibliotecas, laboratorios con todos sus implementos9 además de estudiantes, profesores y personal administrativo. @
*rocesos estarían compuestos 'ustamente 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. @
!alida o productos corresponde a los logros organizacionales en docencia,
investigación y e-tensión. !erían aspectos del resultado, la cantidad de graduados por cohorte, los proyectos de investigación realizados, las publicaciones de los mismos y el n(mero de académicos perfeccionados en un periodo determinado. En síntesis, el modelo sistémico presenta para estos propósitos una gran venta'a, pues ayuda a agrupar de manera ordenada los componentes institucionales y facilita la comprensión de la relación que e-iste entre los mismos. *ropuesta para sistematizar la información en el prototipo de evaluación de la calidad de las instituciones de educación superior *ara sistematizar la información se utilizarán las seis dimensiones del modelo de +371 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 e-tensión y servicios, y de gestión administrativa. 1e acuerdo con ello, se ha planteado la matriz modelo +371 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.
0atriz modelo +371 1icha matriz se aplicará para cada uno de los aspectos a evaluar respecto a la calidad universitaria, entre los que tenemos @
)unción 1ocente
@
spectos Aenerales cadémicos
@
)unción 3nvestigación
@
)unción E-tensión
@
Aestión dministrativo4académica
@
0etodología para el desarrollo del prototipo de evaluación de la calidad
universitaria *ara 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 organizacional9 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. !e aplica la metodología modular de sistemas, el enfoque de arriba hacia aba'o y el diseño de base de datos relacional. 1iseño de arriba hacia aba'o top4do#n& !e selecciona el diseño de arriba hacia aba'o, ;por la facilidad de visualizar una gran imagen del sistema y luego e-plotarla en partes o subsistemas más pequeños. El diseño de arriba hacia aba'o 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. "as venta'as de usar este enfoque para el diseño de sistemas incluyen el evitar el caos de diseñar un sistema todo a la vez. El tratar de tener todos los subsistemas en su lugar y funcionando a la vez es aceptar que se va a fallar<. Enfoque modular para el desarrollo de sistemas 5na vez que ha sido tomado el enfoque de diseño de arriba hacia aba'o, 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 mane'ables. Este enfoque de programación se a'usta bien con el diseño de arriba hacia aba'o, 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 )unción 1ocente, )unción 3nvestigación, spectos Aenerales cadémicos, )unción E-tensión, Aestión dministrativo4académica. 1iseño de base de datos relacional !e selecciona el modelo relacional de base de datos, por ser el óptimo en comparación con los modelos de base de datos 'erárquicos y el de redes. Btra venta'a de este modelo es la portabilidad, ya que la mayoría de los paquetes de mane'o 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. +onceptualmente la tabla de la base de datos es lo mismo que un archivo. 5na o más tablas constituyen una base de datos relacional. "a 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 :.
+rear y mantener la base de datos esto es agregar, eliminar y modificar tablas.
$.
E-traer y presentar información que cumpla ciertas condiciones.
C.
Dacer consultas por e'emplo ;+uál es el promedio de notas de los alumnos por
carrera y por universidadF +uál es la matricula por área de conocimientoF +uál es la rotación matricularF<, etc.&.
=.
Brdenar los registros tablas&, seg(n el campo clave.
>.
Aenerar informes adecuados para el usuario. *or e'emplo una universidad generará
el reporte de gestión periódicamente, seg(n sea el caso o el ;8eporte financiero< puede ser semestral o anual, etc.&. 0odelo entidad relación !e 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 C)7 y =)7, de ser necesario. Entre las entidades tenemos 5niversidad, lumnos, *rofesor, Brganismos reguladores, *roveedores, *roductos, Bferta académica laboral, Egresados, etc. 1iseño de la interfaz gráfica del prototipo *ara 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 organizacional9 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 interdependientes9 esto es, cada nivel con su vista de usuario en la base de datos. El prototipo está diseñado ba'o 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.
