El documento describe las diferentes fases del método de desarrollo orientado a prototipos. En la primera fase, el analista evalúa si el proyecto es un buen candidato para este método y desarrolla una representación preliminar de los requerimientos. Luego, crea especificaciones de diseño para el prototipo. En la siguiente fase, construye el prototipo, lo prueba y refina. Finalmente, presenta el prototipo al cliente para que lo pruebe y sugiera modificaciones.

3. 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, solarizació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 solarización de los objetivos. Luego los administradores deben
tomar una decisión para ver si continúan con el proyecto propuesto.
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.

4. Entre las herramientas utilizadas para definir los
requerimientos de información en el negocio se
encuentran: muestreo e investigación de los datos
relevantes, entrevistas, cuestionarios, el
comportamiento de los tomadores de decisiones y su
ambiente de oficina y hasta la elaboración de
prototipos. En esta fase el analista está esforzándose
por comprender qué información necesitan los
usuarios para realizar su trabajo. Las personas
involucradas en esta fase son los analistas y los
usuarios, típica mente los administradores de las
operaciones y los trabajadores de las operaciones.

5. La siguiente fase que realiza el analista de sistemas involucro el análisis de las
necesidades del sistema. Nuevamente, herramientas y técnicas especiales
ayudan para que el analista haga las determinaciones de los requerimientos.
Una herramienta de éstas es el uso de diagramas de flujo de datos para
diagramar la entrada, proceso y salida de las funciones del negocio en forma
gráfica estructurado. A partir de los diagramas de flujo de datos se desarrolla un
diccionario de datos, que lista todos los conceptos de datos usados en el
sistema, así como sus especificaciones, si son alfanuméricos y qué tanto espacio
ocupan cuando se imprimen..
Durante esta fase el analista de
sistemas también analiza las
decisiones estructuradas que se
hacen. Las decisiones estructuradas
son aquellas para las que pueden ser
determinadas las condiciones como
alternativas de condición, acciones y
reglas de acción. Hay tres métodos
principales para el análisis de
decisiones estructurales: lenguaje
estructurado, tablas de decisión y
árboles de decisión

6. En esta fase del ciclo de vida del desarrollo
de sistemas, el analista usa la información
recolectada anteriormente para realizar el
diseño lógico del sistema de información.
El analista diseña procedimientos precisos
para la captura de datos, a fin de que los
datos que van a entrar al sistema de
información sean correctos. Además, el
analista también proporciona entrada
efectiva para el sistema de información
mediante el uso de técnicas para el buen
diseño de formas y pantallas.

7. En la quinta fase del ciclo de vida del desarrollo de sistemas el
analista trabaja con los programadores para desarrollar cualquier
software original que se necesite. Durante esta fase, el analista
también trabaja con los usuarios para desarrollar documentación
efectiva para el software, incluyendo manuales de procedimientos.
La documentación le dice al usuario la manera de usar el software y
también qué hacer si se suceden problemas con el software.

8. Antes de que pueda ser usado, el
sistema de información debe ser
probado. Es mucho menos costoso
encontrar problemas antes de que el
sistema sea entregado a los usuarios.
Algunas de las pruebas son realizadas
por los programadores solos, y otras
por los analistas de sistemas junto con
los programadores. Primero se ejecuta
una serie de pruebas para que
destaquen los problemas con datos de
ejemplo y eventualmente con datos
reales del sistema actual. El
mantenimiento del sistema y de su
documentación comienza en esta fase
y es efectuado rutinariamente a lo
largo de la vida del sistema de
información.

9. 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”
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.
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.

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

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

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

13. 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?

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

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

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

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

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

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

21. 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.
•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.

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

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

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

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

26. 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:
Salida o
productos
Egresados
Patentes
Asesoría
Servicios
Procesos
Académicos
Investigación
Extensión
Administrativos
Entrada o
insumos
Estudiantes
Profesores
Laboratorio
Biblioteca

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

28. 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.
Dimensiones
Funciones
Docencia Investigación Extensión y
servicios
General
académica
Gestión
Relevancia
Integridad
Efectividad
Disponibilidad
de recursos
Eficiencia
Eficacia
Procesos Daniella C.

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

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

31. La verificación conforme a la norma mexicana NMX-I-059/02-NYCE-
2011 consiste en determinar el nivel de madurez de los 9 procesos en
las organizaciones que tienen como referencia el modelo MoProSoft.
Estos 9 procesos están contenidos en
tres categorías: Alta Dirección (DIR),
Gerencia (GER) y Operación (OPE), lo
que asegura una cobertura total en
la organización. Se determina el nivel
de madurez de capacidades para
cada proceso verificado, y con base
en ello, el nivel de madurez de
capacidades de la organización que
es el máximo nivel de capacidad
alcanzado por todos los procesos de
MoProSoft.