ACTIVIDAD 3

Prototipo de Sofware 1

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.

 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.

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.

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

 
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.

 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.

 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?

  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.

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.
 
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.
 FASES
Las fases que comprende el método de desarrollo orientado a prototipos serían:

 Investigación preliminar. Las metas principales de esta fase son: determinar el problema

y su ámbito, la importancia y sus efectos potenciales sobre la organización por una parte y,
por otro lado, identificar una idea general de la solución para realizar un estudio de
factibilidad que determine la factibilidad de una solución software.

 Definición de los requerimientos del sistema. El objetivo de esta etapa es registrar

todos los requerimientos y deseos que los usuarios tienen en relación al proyecto bajo
desarrollo. Esta etapa es la más importante de todo el ciclo de vida, es aquí donde el
desarrollador determina los requisitos mediante la construcción, demostración y
retroalimentaciones del prototipo. Por lo mismo esta etapa será revisada con más detalle
luego de esta descripción.

 Diseño técnico. Durante la construcción del prototipo, el desarrollador ha obviado el

diseño detallado. El sistema debe ser entonces rediseñado y documentado según los
estándares de la organización y para ayudar a las mantenciones futuras. Esta fase de
diseño técnico tiene dos etapas: por un lado, la producción de una documentación de
diseño que especifica y describe la estructura del software, el control de flujo, las interfaces
de usuario y las funciones y, como segunda etapa, la producción de todo lo requerido para
promover cualquier mantención futura del software.

 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:

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

Modelo de desarrollo Orientado a 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 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:
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

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

CODIFICACION DE LOS REQUERIMIENTOS:

 RO: Requerimientos por parte de la organización, RI: Requerimiento por parte del equipo
de ingenieros.
 RO-01: El clasificado debe tener un identificador de ciudad: Pereira PR/, Cartago CG/ y
Manizales MZ/.
  RO-02: El clasificado debe tener un código que lo identifique y este a su vez está
compuesto por el índice del clasificado y un número que identifica la ciudad.
 RO-03: El clasificado debe estar relacionado con un número telefónico.
 RO-04: El clasificado debe pertenecer a una edición.
 RO-05: Mostrar mensaje de alerta al ingresar 10 clasificados con el mismo número
telefónico: después de 10 clasificados se considera lista.
 RO-06: Renovar clasificados de ediciones anteriores si se solicita.
 RO-07: Inicio de sesión (Roles de usuarios).
 RO-08: Generación de archivo .xls (Excel) por edición.
 RI-01: Listado de la información necesaria para la elaboración de la aplicación.
 RI-02: Listado de logos y esquemas para que el sistema cumpla con la imagen empresarial.
 RI-03: Hardware adecuado para la instalación y funcionamiento de la aplicación

 EJECRCICIO:

De acuerdo al ejercicio Cliente facturas artículos desarrollado se denota lo siguiente:

 Entre mayor sea la cantidad de unidades producidas en el momento de la medición

será mayor el resultado del cálculo de medición, es decir serán variables
directamente proporcionales.
 Si el numero de vueltas ejecutados es 0 el cálculo de medición va ser 0 ya que no
va a a tener oportunidad de medición.
 Entre mayor sea el numero de vueltas ejecutadas el cálculo de la medición será
mucho mayor

CUPMM NVEMM NTVEPC TUEC OCM

 
Unidad
3
1 12 2 1 15
Unidad
4
2 14 2 1 15
Unidad
11 2 1 15 3
3
Unidad
8 2 2 15 4
4
Unidad
4 3 1 15 2
5
 CUPMM NVEMM NTVEPC TUEC OCM

 
Unidad
11
1 5 4 2 15
Unidad
9
2 16 2 2 15
Unidad
7 5 3 15 35
3
Unidad
4 3 2 15 5
4
Unidad
2 2 1 15 1
5

CUPMM NVEMM NTVEPC TUEC OCM

 
Unidad
3
1 3 4 1 15
Unidad
2
2 12 1 2 15
Unidad
12 1 1 15 1
3
Unidad
11 2 2 15 6
4
Unidad
9 3 4 15 22
5

CUPMM NVEMM NTVEPC TUEC OCM

 
Unidad
37
1 11 5 2 15
Unidad
3
2 13 2 1 15
Unidad
5 3 2 15 6
3
Unidad
7 3 2 15 8
4
Unidad
8 2 1 15 2
5
 CUPMM NVEMM NTVEPC TUEC OCM

 
Unidad
18
1 11 5 1 15
Unidad
1
2 5 1 2 15
Unidad
6 2 3 15 5
3
Unidad
7 2 2 15 4
4
Unidad
15 4 4 15 64
5

BIBLIOGRAFIAS

https://sistemas2009unl.files.wordpress.com/2009/
https://sistemas2009unl.files.wordpress.com/2009/
http://www.usabilitynet.org/tools/r_international.htm#9126-1
http://gestionrrhhusm.blogspot.com.co/2011/05/modelo-de-prototipo.html
http://www.solucionesaplicativas.com/servicios/prototipos.php