• Author / Uploaded
• Karlita Nohely Montoya Rojas

• Categories
• Bases de datos
• Software
• Base de datos relacional
• Ingeniería de software
• Proceso de desarrollo de software

Citation preview

MODELO DE PROTOTIPOS El modelo de prototipos permite que todo el sistema, o algunos de sus partes, se construyan rápidamente para comprender con facilidad y aclarar ciertos aspectos 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 minimizar el riesgo y la incertidumbre en el desarrollo, este modelo se encarga 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.( Shari Lawrence, 2002) Este modelo principalmente se aplica cuando un cliente define un conjunto de objetivos generales para el software 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 mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos 1. 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.

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

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 rendimiento: evalúan el rendimiento de una aplicación crítica (no sirven al análisis de requisitos). 3.4.

   

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.

3.5.

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.

3.6.

Vertical



Desarrolla completamente alguna de las funciones.

3.7.



Horizontal

Desarrolla parcialmente todas las funciones.

4. Fases del desarrollo del modelo

Las fases que comprende el método de desarrollo orientado a prototipos serían: 4.1. Investigación preliminar. Las metas principales de esta fase son:  Determinar el problema y su ámbito,  Determinar la importancia y sus efectos potenciales sobre la organización  Identificar una idea general de la solución para realizar un estudio de factibilidad que determine la factibilidad de una solución software. 4.2. 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.

4.3. Análisis de los requerimientos: Esta etapa es un proceso que busca aproximar las visiones del usuario y del desarrollador mediante sucesivas iteraciones. Para la definición de los requerimientos tenemos cinco etapas entre dos de las cuales se establece un ciclo interactivo



Análisis grueso y especificación: En esta fase se busca desarrollar un diseño básico



para el prototipo inicial. Diseño y construcción: Lo que se consigue en esta fase en obtener un prototipo inicial, aquí el desarrollador debe concentrarse en construir un sistema con la



máxima funcionalidad, poniendo énfasis en la interfaz del usuario. Evaluación: Los objetivos 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. Se 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: -

Preparación. Demostración. Uso del prototipo. Discusión de comentarios.

Esta es la fase en donde se decide si el prototipo es aceptado o modificado. 

Modificación: Se 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é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.

4.4. 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: 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 La producción de todo lo requerido para promover cualquier mantención futura del software.

4.5. 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. Las pruebas serán de realizarse tantas veces sea necesarias para verificar cualquier tipo de anomalía en el sistema. 4.6. 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. 5. Ventajas de la aplicación del modelo de prototipos

Las ventajas de un enfoque de desarrollo orientado a prototipos están dadas por: 

Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o



salida. También ofrece un mejor enfoque cuando el responsable del desarrollo del software 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 humano-máquina. No modifica el flujo del ciclo de vida. Reduce el riesgo de construir productos que no satisfagan las necesidades de los

   

usuarios. Reduce costos y aumenta la probabilidad de éxito. Exige disponer de las herramientas adecuadas. No presenta calidad ni robustez. Una vez identificados todos los requisitos mediante el prototipo, se construye el producto de ingeniería

6. Desventajas de la aplicación del modelo de prototipos

Si bien, el desarrollo orientado a prototipos tiene considerables ventajas, también presenta desventajas como: 

El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A 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 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.

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

PASO 2. Dado un proyecto candidato aceptable, el analista desarrolla una representación abreviada de los requerimientos. Antes de que pueda comenzar la

construcción de un prototipo, el analista debe representar los dominios funcionales y de información del programa y desarrollar un método razonable de partición. La aplicación de estos principios de análisis fundamentales, pueden realizarse mediante los métodos de análisis de requerimientos. 

PASO 3. Después de que se haya revisado la representación de los requerimientos, se crea un conjunto de especificaciones de diseño abreviadas para el prototipo. El diseño debe ocurrir antes de que comience la construcción del prototipo. Sin embargo, el diseño de un prototipo se enfoca normalmente hacia la arquitectura a nivel superior y a los aspectos de diseño de datos, en vez de hacia el diseño procedimental detallado.



PASO 4. El software del prototipo se crea, prueba y refina Idealmente, los bloques de construcción de software preexisten se utilizan para crear el prototipo de una forma rápida. Desafortunadamente, tales bloques construidos raramente existen. Incluso si la implementación de un prototipo que funcione es impracticable, es escenario de construcción de prototipos puede aún aplicarse. Para las aplicaciones interactivas con el hombre, es posible frecuentemente crear un prototipo en papel que describa la interacción hombre-máquina 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.

8. EJEMPLO:

Prototipo informático para la evaluación de la calidad de la educación superior

8.1.

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 

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:

•

Entrada: estaría constituida por las inversiones, tanto en recursos materiales como

humanos. En otras palabras: salas, talleres, bibliotecas, laboratorios con todos sus implementos; además de estudiantes, profesores y personal administrativo. •

Procesos: estarían compuestos justamente por todas las interacciones que tienen

lugar en la institución y que permiten que ésta pueda cumplir los compromisos adquiridos con la sociedad, en cuanto a conocimiento creados, profesionales formados y servicios entregados a la comunidad. Esto incluye todos los procedimientos de administración universitaria y gestión financiera de la organización. •

Salida o productos: corresponde a los logros organizacionales en docencia,

investigación y extensión. Serían aspectos del resultado, la cantidad de graduados por cohorte, los proyectos de investigación realizados, las publicaciones de los mismos y el número de académicos perfeccionados en un periodo determinado. En síntesis, el modelo sistémico presenta para estos propósitos una gran ventaja, pues ayuda a agrupar de manera ordenada los componentes institucionales y facilita la comprensión de la relación que existe entre los mismos. Propuesta para sistematizar la información en el prototipo de evaluación de la calidad de las instituciones de educación superior Para sistematizar la información se utilizarán las seis dimensiones del modelo de CINDA que, como se ha dicho, permite hacer una revisión bastante completa y coherente en los siguientes aspectos: académicos en general, en la función docente, de investigación y creación, de extensión y servicios, y de gestión administrativa. 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.

Matriz modelo CINDA 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

•

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 relacional. 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”. 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. 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: 1.

Crear y mantener la base de datos: esto es agregar, eliminar y modificar tablas.

2.

Extraer y presentar información que cumpla ciertas condiciones.

3.

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

4.

Ordenar los registros (tablas), según el campo clave.

5.

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