1.1.1.

PROBLEMA GENERAL

¿Cómo determinar la influencia de la metodología de prototipos en la calidad

de un software desarrollado, empleando los principios, lineamientos de esta

metodología?

1.2. OBJETIVOS DE LA INVESTIGACION

1.2.1. Objetivo general

- Conocer los principios y teorías de la metodología de prototipos y los

casos de aplicación con éxito en los proyectos de desarrollo de software

en el Perú.

1.2.2. Objetivos específicos

- Determinar la influencia del uso de la metodología de prototipos en la

eficiencia del desarrollo de un software.

- Determinar las ventajas y desventajas de usar la metodología de

prototipos, en los proyectos de desarrollo de software.

- Conocer los casos donde se aplicó exitosamente la metodología de

prototipos en el Perú.

1.3. HIPOTESIS DE LA INVESTIGACION

1.3.1. HIPOTESIS GENERAL

Es posible conocer los principios y teorías de la metodología de prototipos

mediante el análisis de un caso de aplicación, que utiliza esta metodología.

1.3.2. HIPOTESIS ESPECIFICAS

- El uso de la metodología de prototipos determina la eficiencia de un

software terminado.
 - En el Perú la metodología de prototipos es bastante usada por que

permite realizar cambios antes del entregable final.

CAPITULO II

MARCO TEORICO

2.1. BASES TEORICAS

2.1.1. EL SOFTWARE

El software de computadora es el producto que construyen los

programadores profesionales y al que después le dan mantenimiento

durante un largo tiempo. Incluye programas que se ejecutan en una

computadora de cualquier tamaño y arquitectura, contenido que se

presenta a medida de que se ejecutan los programas de cómputo e

información descriptiva tanto en una copia dura como en formatos

virtuales que engloban virtualmente a cualesquiera medios

electrónicos. La Ingeniería de Software esta formada por un proceso,

1
un conjunto de métodos (practicas) y un arreglo de herramientas que

permite a los profesionales elaborar software de computo de alta

calidad. (Pressman, 2010)

Por lo general, un sistema de software consiste en diversos

programas independientes, archivos de configuración que se utilizan

para ejecutar estos programas, un sistema de documentación que

describe la estructura del sistema, la documentación para el usuario

que explica como utilizar el sistema y sitios web que permitan a los

usuarios descargar la información de productos recientes.

(Sommerville, 2005)

El desarrollo de Software, es posiblemente una de las áreas que van

avanzando a pasos agigantados con el paso del tiempo, pero también

con mayor discreción, si bien es cierto que hoy la sociedad puede

disfrutar de una gran cantidad de software con muchísimas

funciones, esta nunca se percata de la existencia del desarrollo del

software como tal, para la sociedad el software hoy en dia es

importante para poder subsistir, sin importar de donde provenga.

Incluso las personas están tan acostumbrados a hacer uso de

diversos tipos de software, que sin ellos el cambio seria sumamente

radical en sus vidas.

2.1.1.1. LA IMPORTANCIA DEL SOFTWARE EN LA

SOCIEDAD

El software es importante porque afecta a casi todos

aspectos de nuestras vidas y ha invadido nuestro

2
comercio, cultura y actividades cotidianas. La ingeniería

de software es importante porque nos permite construir

sistemas complejos en un tiempo razonable y con alta

calidad. (Pressman, 2010)

Está claro lo que es el software, hablando en lenguaje que

las personas entiendan, son los programas que se

ejecutan dentro de una computadora, empezando por el

sistema operativo, acompañado de cualquier de los

programas que tengas en tu computadora, sin el software,

solamente estaríamos frente a un grupo de chips, cables

y aparatos sin funcionamiento.

Sin embargo, la sociedad actual ya no podría vivir sin el

software, aunque esta no se percate de ello lo podemos

ver simplemente en la cantidad de personas que utilizan

una computadora hoy en dia, lo podemos apreciar

claramente en el uso domestico de compitadoresm

aunque este se ha reducido considerablemente.

Incrementando la presencia de tablets o teléfonos

inteligentes.

Esta década quedara marcada como la época en la que

los dispositivos moviles tomaron el mando de la

tecnología, el software se sigue modernizando

llevandonos a limites que tal bez hace 10 años jamás

imaginamos, sin embargo hoy podemos disfrutar de

3
 software de altísima calidad, con lo cual podemos

destacar el desarrollo del software a un nivel que nos

permite diferencia entre una época y la otra.

2.1.1.2. BENEFICIOS DEL SOFTWARE PARA LA SOCIEDAD

Hablemos de beneficios, hoy en día un teléfono celular

puede realizar funciones que jamás imaginaste, puedes

automatizar tu vida, programar alertas para saber que

hacer a cada hora y que no olvidar nada, poder

comunicarte con personas en cualquier parte del mundo

gracias al desarrollo del software móvil que se viene

generando desde principios de la década.

2.1.1.3. CARACTERISTICAS DEL SOFTWARE

Según Pressman el software es elemento de un sistema

lógico y no de uno físico. Por tanto, tiene características

que difieren considerablemente de las del hardware.

 El software se desarrolla o modifica con intelecto;

no se manufactura en el sentido clásico.

 El software no se “desgasta”

 Aunque la industria se mueve hacia la

construcción basada en componentes, la mayor

parte del software se construye para un uso

individualizado. (Pressman, 2010)

4
 Según Sommerville las características esenciales de un

sistema de software bien diseñado son:

 Mantenibilidad

 Confiabilidad

 Eficiencia

 Usabilidad (Sommerville, 2005)

Podemos decir que el software es un elemento del

sistema que es lógico. Una forma mas sencilla de

interpretar las características del software seria de la

siguiente manera:

 El software se desarrolla, no se fabrica.

 El software no se estropea.

 Los softwares se construyen a medida, en vez de

ensamblar componentes existentes.

2.1.1.4. ELEMENTOS DEL SOFTWARE

5
 Documentacion: Programas:
Describe el Cuando se ejecutan
funcionamiento, la realizan una o varias
estructura, operacion funciones con el
y uso de los rendimiento
programas. esperado.

Estructuras de Datos: Permiten

que los programas manipulen
adecuadamente la informacion.

2.1.2. PROBLEMAS EN LA PLANIFICACION DE UN PROYECTO DE

SOFTWARE

A. ESTABLECER EL AMBITO DEL SOFTWARE

Describe la función, el rendimiento, las restricciones, las

interfaces y la fiabilidad.

 Se evalúan las funciones descritas en el enunciado del

ámbito o se refinan.

 Las consideraciones de rendimiento abarcan los requisitos

de tiempos de respuesta y de procesamiento.

 Las restricciones marcan los límites del software debidos al

hardware externo, la memoria disponible y otros sistemas

existentes.

6
Para la obtención de la información necesaria para el ámbito, o

sea para acercar al cliente y al desarrollador (ingeniero del

software, analista), y para hacer que comience el proceso de

comunicación es establecer una reunión o entrevista preliminar.

Se sugiere que el analista comience haciendo preguntas de que

lleven a un entendimiento básico del problema.

• El primer conjunto de cuestiones se centra en el cliente, en

los objetivos globales y en los beneficios.

• El siguiente conjunto de cuestiones permiten que el analista

comprenda mejor el problema y que el cliente exprese sus

percepciones sobre una solución.

• La última serie de preguntas se centra en la efectividad de

la reunión, son conocidas como Meta-Cuestiones:

 ¿es usted la persona apropiada para responder a

estas preguntas?

 ¿son oficiales sus respuestas?

 ¿son relevantes mis preguntas para su problema?

 ¿hago muchas preguntas?

 ¿existe alguien más que pueda proporcionar más

información?

 ¿hay algo más que deba preguntarle?

Esta sesión de preguntas-y-respuestas solo se debería utilizar en

el primer encuentro, reemplazándose posteriormente por un tipo

7
 de reunión que combine elementos de resolución de problemas,

negociación y especificación.

B. ESTIMACIÓN DE LOS RECURSOS REQUERIDOS

La segunda tarea en la planificación, es la estimación de los

recursos requeridos para acometer el esfuerzo de desarrollo

software. - Personas, recursos humanos - Componentes de

software reutilizables (componentes ya desarrollados o

experimentados), que reducen el coste de desarrollo y aceleran

la entrega. - Componentes nuevos - Recursos de ingeniería de

software y de hardware. Cada recurso se especifica con 4

características:

 Descripción del recurso,

 Informe de disponibilidad,

 Fecha en la que se requiere,

 Tiempo durante el que será utilizado.

C. ESTIMACION DEL PROYECTO DE SOFTWARE

En el principio el costo del software constituía un pequeño

porcentaje del costo total de los sistemas basados en

computadoras. Hoy en día el software es el elemento más caro

de la mayoría de los sistemas informáticos. Es una pequeña

planeación sobre qué es lo que va a ser mi proyecto. Una de las

actividades cruciales del proceso de gestión del proyecto del

software es la planificación.
8
Cuando se planifica un proyecto de software ese tiene que

obtener estimaciones de esfuerzo humano requerido, de la

duración cronológica del proyecto y del costo. Pero en muchos

de los casos las estimaciones se hacen valiéndose de la

experiencia pasada como única guía. Si un proyecto es bastante

similar en tamaño y funciona un proyecto pasado es probable que

el nuevo requiera aproximadamente la misma cantidad de

esfuerzo, que dure aproximadamente lo mismo que el trabajo

anterior. Si el proyecto es distinto entonces puede que las

experiencias obtenidas no sean suficientes.

La planeación efectiva de un proyecto de software depende de la

planeación detallada de su avance, anticipando problemas que

puedan surgir y preparando con anticipación soluciones

tentativas a ellos. Se supondrá que el administrador del proyecto

es responsable de la Planeación desde la definición de requisitos

hasta la entrega del sistema terminado.

Los puntos analizados posteriormente generalmente son

requeridos por grandes sistemas de programación, sin embargo,

estos puntos son validos también para sistemas pequeños.

 Panorama. Hace una descripción general del proyecto

detalle de la organización del plan y resume el resto del

documento.

9
 Plan de fases. Se analiza el ciclo de desarrollo del proyecto

como es: análisis de requisitos, fase de diseño de alto nivel,

fase de diseño de bajo nivel, etc. Asociada con cada fase

debe de haber una fecha que especifique cuando se debe

terminar estas fases y una indicación de cómo se pueden

solapar las distintas fases del proyecto.

 Plan de organización. Se defínelas responsabilidades

específicas de los grupos que intervienen en el proyecto.

 Plan de pruebas. Se hace un esbozo general de las

pruebas y de las herramientas, procedimientos y

responsabilidades para realizar las pruebas del sistema.

 Plan de control de modificaciones. Se establece un

mecanismo para aplicar las modificaciones que se

requieran a medida que se desarrolle el sistema.

 Plan de documentación. Sus funciones definir y controlar

la documentación asociada con el proyecto.

 Plan de capacitación. Se describe la preparación de los

programadores que participan en el proyecto y las

instrucciones a los usuarios para la utilización del sistema

que se les entregue.

 Plan de revisión e informes. Se analiza cómo se informa

del estado del proyecto y se definen las revisiones formales

asociadas con el avance de proyecto.

10
  Plan de instalación y operación. Se describe el

procedimiento para instalar el sistema en la localidad del

usuario.

 Plan de recursos y entregas. Se resume los detalles

críticos del proyecto como fechas programadas, marcas de

logros y todos los artículos que deben entrar bajo contrato.

 Índice. Se muestra en donde encontrar las cosas dentro del

plan.

 Plan de mantenimiento. Se establece un bosquejo de los

posibles tipos de mantenimiento que se tienen que dar para

futuras versiones del sistema.

Errores

 Errores clásicos en un proyecto de software

 Mal análisis en los requerimientos.

 Una mala planeación.

 No tener una negociación (documento, contrato) con el

cliente.

 No hacer un análisis costo beneficio.

 Desconocer el ambiente de trabajo de los usuarios.

 Desconocer los usuarios que trabajan con el sistema.

 Mala elección de recursos (hardware, software, humanos).

 Herramientas para la planificación y Gestión de productos

Software.

11
 Para poder completar con éxito un proyecto de software, se necesita

tener un control riguroso sobre el tiempo, las personas o los

imprevistos que puedan surgir, como por ejemplo cambios en el

software. Para ayudarnos en la planificación y gestión de proyectos,

Microsoft nos proporciona dos herramientas básicas: Microsoft

Project y Microsoft Solutions Framework.

2.1.3. PROBLEMAS DEL EQUIPO DE UN PROYECTO DE SOFTWARE

Un error frecuente en empresas de programación es tener a todo el

mundo haciendo de todo. Aunque eso en algún que otro escenario

puede funcionar bien, causa que esas personas no puedan

emitir estimados de calidad, ya que les resulta imposible poder

determinar cuánto tiempo van a dedicar a cada tarea.

Es por ello que los roles dentro de un equipo de programación deben

ser lo más dedicados posible. Obviamente, dependiendo del tamaño

de la aplicación, del tiempo y de los recursos disponibles, el equipo

podrá ser de un tamaño u otro. Pero hay una serie de puestos que

son imprescindibles para que todo funcione adecuadamente.

Estos puestos tienen unas responsabilidades bien definidas. Los

puestos que mínimamente se deben cumplir son los siguientes:

JEFE DE PROYECTO

Es el encargado de realizar el análisis de los requerimientos del

cliente. De hacer el seguimiento diario de las tareas y de resolver

12
cualquier problema de comunicación con otros equipos si los hubiera.

En el caso de que este equipo se convierta en cliente de otro equipo,

esta persona es la que se encarga de realizar la comunicación con

ellos. Obligatoriamente tiene que tener un background de

programador, necesita entender a los programadores y la

problemática a la que se enfrentan diariamente para poder asegurar

que los requerimientos recogen toda la información necesaria para

poder realizar la tarea. Es el responsable de que la implementación

de esos requerimientos se haga correctamente.

LÍDER DE EQUIPO

Es el programador líder, debe ser alguien senior, con capacidad

organizativa. Se encarga de redactar y mantener actualizados los

requerimientos. También se encarga de escribir las especificaciones

técnicas y crear las tareas, asignándolas a los desarrolladores de su

equipo. Sus tareas de programación deben limitarse única y

exclusivamente a la arquitectura, marcando la línea a seguir por el

resto de programadores. Aparte de esto, tiene que revisar el trabajo

de los programadores a su cargo para asegurar la calidad del código

escrito.

DESARROLLADOR

Es un programador, que se encarga de ejecutar el trabajo asignado

por el líder del equipo. En un proyecto de software, normalmente el

13
20% del código constituye arquitectura y el 80% restante consiste en

utilizar esa arquitectura para completar los requerimientos. Los

desarrolladores son los encargados de completar ese 80%.

DISEÑADOR GRÁFICO Y UX

Este rol consiste en, a nivel de UX, realizar los flujos de

trabajo dentro de una aplicación a nivel de mockups, para determinar

posteriormente, los diseños que habrá que realizar y como se va a

comportar la aplicación. Posteriormente, es el encargado de realizar

el diseño gráfico de las pantallas que compone la aplicación,

atendiendo a las reglas de UX que determinen la posición de los

elementos, los esquemas de colores, tipografías, etc.

LÍDER DE CALIDAD

Debe ser alguien con conocimientos de programación y análisis, que

sea capaz, utilizando los requerimientos, de desarrollar una suite de

tests que verifiquen que el software cumple con los requerimientos.

El líder de calidad es el último responsable de que las características

funcionan tal y como se han especificado en los requerimientos.

INGENIERO EN CALIDAD

Es un programador o alguien con conocimientos de programación,

encargado de escribir la suite de tests para automatizar el testeo del

programa.

14
 Si se desarrollan productos de software, por lo general, estos deben

venir acompañados de algún tipo de documentación, para ello, se

necesitarían dos roles más:

LÍDER DE DOCUMENTACIÓN

Alguien con conocimientos técnicos, capaz de entender los

requerimientos y, a partir de ellos, generar la documentación

necesaria, se encarga de organizar el contenido a escribir y marcar

la línea a seguir en cuanto a documentación.

DOCUMENTADOR TÉCNICO

También debe tener un trasfondo técnico, para poder escribir

contenido que tenga significado y se utilice el vocabulario adecuado.

Su objetivo es completar la documentación sobre todas las

características del producto.

2.1.4. PROBLEMAS DE LA TECNOLOGÍA UN PROYECTO DE

SOFTWARE

La tecnología cambia rápidamente:

Las nuevas versiones de los sistemas operativos salen cada pocos

años, por ejemplo, hace unos veinte años estábamos trabajando con

MS-DOS, y ahora prácticamente nadie lo recuerda.

Hoy en día, cualquier software nuevo, es casi seguro que será

construido con una estructura de aplicaciones empresariales o

15
frameworks como Java de Sun Microsystems 2 Enterprise Edition

(J2EE) o Microsoft NET. Estos frameworks en los que se basan gran

número de aplicaciones, van evolucionando, proporcionando nuevas

características o modificando las existentes.

Resumiendo, las tecnologías de desarrollo de software cambian más

rápido que otras tecnologías, como pueden ser las de la

construcción.

La tecnología es un dominio muy vasto:

En el desarrollo de software se utilizan muchas tecnologías,

normalmente estas cambian en cada proyecto, y se utilizan varias a

la vez, por lo que la complejidad aumenta y los programadores no

llegan a tener nunca una experiencia amplia en un juego de

tecnologías concreto.

Cómo factor agravante, cada año aparecen nuevas tecnologías en el

mercado, que, aunque pueden tener funcionalidades interesantes,

requieren aprendizaje.

La experiencia en tecnología es incompleta:

Las tecnologías de desarrollo de software se quedan obsoletas en

muy poco tiempo, apareciendo nuevas tecnologías.

Esto implica que parte de los conocimientos y la experiencia

adquirida con una tecnología particular pierda valor, y que los

16
 desarrolladores estén aprendiendo nuevas tecnologías a la vez que

está desarrollando con ellas.

2.1.5. Metodologías tradicionales

Las metodologías tradicionales se caracterizan por exponer procesos

basados en planeación exhaustiva.

Esta planeación se realiza esperando que el resultado de cada

proceso sea determinístico y predecible.

La experiencia ha mostrado que, como consecuencia de las

características del software, los resultados de los procesos no son

siempre predecibles y sobre todo, es difícil predecir desde el

comienzo del proyecto cada resultado. Sin embargo, es posible por

medio de la recolección y estudio de métricas de desarrollo lograr

realizar estimaciones acertadas en contextos de desarrollo

repetibles.

Remontándose a la historia, el modelo de cascada fue uno de los

primeros modelos de ciclo de vida (MCV) que formalizó un conjunto

de procesos de desarrollo de software. Este MCV describe un orden

secuencial en la ejecución de los procesos asociados. El modelo

espiral se postuló como una alternativa al modelo de cascada. La

ventaja de este modelo radica en el perfeccionamiento de las

soluciones encontradas con cada ciclo de desarrollo, en términos de

dar respuesta a los requerimientos inicialmente analizados. El

17
 modelo de cascada y el modelo espiral suponen, de manera general,

que los requerimientos del cliente no cambian radicalmente en el

transcurso del desarrollo del sistema.

Por otro lado, la realización de prototipos es una herramienta en la

que se apoyan diferentes MCV. Un prototipo debe tener el objetivo

de mostrar al cliente o a la gerencia del proyecto el resultado que se

obtendrá de la implementación de cada uno de los requerimientos

del cliente una vez terminado el desarrollo. Con los prototipos se

tiene la posibilidad de obtener retroalimentación de manera

temprana.

La solución a algunos de los problemas presentados por las

metodologías tradicionales se logra con una gran evolución del

modelo espiral. El proceso unificado propone la elaboración de varios

ciclos de desarrollo, donde cada uno finaliza con la entrega al cliente

de un producto terminado. Este se enmarca entre los conocidos

modelos iterativo-incremental.

2.1.6. Metodologías ágiles

Grupos de desarrollo han experimentado soluciones que basan su

fundamento en la adaptabilidad de los procesos de desarrollo, en

lugar de seguir esperando lograr resultados predecibles de un

proceso que no evoluciona. Esta comunidad de desarrolladores e

investigadores han nombrado su trabajo bajo lo que conocemos

18
como metodologías ágiles. Las metodologías ágiles como puede

entenderse mal, no están en

contra de administrar procesos de desarrollo. Por el contrario,

promueve la formalización de procesos adaptables. La compilación

de los principios y valores que resaltan las metodologías ágiles fue

formalizada en el manifiesto para el desarrollo de software ágil. Este

documento desarrollado por los representantes de cada una de las

metodologías que en el momento se presentaban como ágiles, logra

resumir en un conjunto de ideas las prácticas que una metodología

de este estilo debe llevar a cabo. Como característica fundamental,

la habilidad de responder al cambio es la principal característica de

las metodologías ágiles.

XP, una de las más difundidas, es una metodología de desarrollo de

software ágil que define pocas reglas y pocas prácticas. XP

promueve la adaptabilidad de los procesos de desarrollo basándose

en los principios y prácticas que presenta. Quienes trabajan usando

XP deben seguir procesos disciplinados, pero más que eso, deben

combinar la disciplina con la adaptabilidad necesaria del proceso.

Las metodologías de Cristal se basan en el principio de que tipos

diferentes de proyectos requieren tipos diferentes de metodologías.

La metodología escogida debe depender de dos factores: el número

de personas en el proyecto, y las consecuencias de los errores.

Conforme al principio de las metodologías ágiles, Scrum recalca la

19
 imposibilidad de encontrar procesos definidos y repetibles cuando no

existen problemas, personas, ni ambientes definidos y repetibles.

2.1.7. Ciclo de Vida del Software

2.1.7.1. Análisis y definición de requerimientos

 Se obtiene todos los requerimientos del servicio,

restricciones y metas del sistema.

 Se definen a partir de las consultas a los usuarios.

 Se recoge todas las especificaciones del sistema

 Se recoge todas las especificaciones del software

2.1.7.2. Diseño del sistema y del software

 Se establece la arquitectura del sistema

 Divide los requerimientos en hardware y software y

sus relaciones

2.1.7.3. Implementación y Pruebas

 El diseño de software se hace como un conjunto de

unidades de programas (“módulos”) sistema.

 Las pruebas de esta etapa se llaman pruebas de

unidad y tienen como objetivo velar que cada parte

cumpla su especificación

2.1.7.4. Integración y Pruebas

 Las unidades de programa (módulos) se integran

20
  Las pruebas de esta etapa se llaman pruebas de

integración y asegura que se cumplan los

requerimientos de software.

 Después de estas pruebas exitosas se entrega el

producto al cliente

2.1.7.5. Funcionamiento y Mantenimiento

 Por lo general es la etapa más larga del ciclo de vida

del software.

 Luego de instalado el software, la etapa de

mantenimiento incluye la corrección de errores no

descubiertos en las etapas anteriores, mejorar las

implementaciones y ajustar nuevos requerimientos.

 A partir de esta fase la cascada se devuelve a

cualquiera de las etapas anteriores

2.1.8. MODELO DE PROTOTIPADOS

2.1.8.1. ¿Qué es un prototipo?

Un prototipo en sentido genérico es una implementación parcial pero

concreta de un sistema o una parte de este que principalmente se

crean para explorar cuestiones sobre aspectos muy diversos del

sistema durante el desarrollo de este.

2.1.8.1.1. Características de un prototipo

 Son formidables herramientas de:

21
  Comunicación entre todos los componentes del

equipo de desarrollo y los usuarios.

 Participación, para integrar activamente a los

usuarios en el desarrollo.

 Dan soporte a los diseñadores a la hora de escoger

entre varias alternativas. Permiten a los diseñadores

explorar diversos conceptos del diseño antes de

establecer los definitivos.

 Permiten evaluar el sistema desde las primeras fases

del desarrollo (facilitan la exploración de ideas sobre

nuevos conceptos tecnológicos).

 Son esenciales para la documentación, tanto de

conceptos funcionales del sistema como de tareas

concretas del mismo.

 Son el primer paso para que ideas abstractas sean

concretas, visibles y testeables.

 Fomentan la iteratividad.

 Mejoran la calidad y la completitud de las

especificaciones funcionales del sistema.

 Son herramientas de propósito general, pues sirven

para comprobar la fiabilidad técnica de una idea,

clarificar requisitos que quedaron “indeterminados” o

ver cómo responde con el resto de la aplicación.

22
2.1.8.2. Modelo de prototipos

El Modelo de prototipos, en Ingeniería de software, pertenece a los

modelos de desarrollo evolutivo. El prototipo debe ser construido en

poco tiempo, usando los programas adecuados y no se debe utilizar

muchos recursos.

El diseño rápido se centra en una representación de aquellos aspectos

del software que serán visibles para el cliente o el usuario final. Este

diseño conduce a la construcción de un prototipo, el cual es evaluado

por el cliente para una retroalimentación; gracias a ésta se refinan los

requisitos del software que se desarrollará. La interacción ocurre

cuando el prototipo se ajusta para satisfacer las necesidades del

cliente. Esto permite que al mismo tiempo el desarrollador entienda

mejor lo que se debe hacer y el cliente vea resultados a corto plazo.

El software, como todos los sistemas complejos, evoluciona en el

tiempo. Es frecuente que los requerimientos del negocio y del

producto cambien conforme avanza el desarrollo, lo que hace que no

sea realista trazar una trayectoria rectilínea hacia el producto final;

los plazos apretados del mercado hacen que sea imposible la

terminación de un software perfecto, pero debe lanzarse una versión

limitada a fin de aliviar la presión de la competencia o del negocio;

se comprende bien el conjunto de requerimientos o el producto

básico, pero los detalles del producto o extensiones del sistema aún

están por definirse. En estas situaciones y otras parecidas se necesita

23
 un modelo de proceso diseñado explícitamente para adaptarse a un

producto que evoluciona con el tiempo. (Pressman, Ingenieria del

Software, 2010)

2.1.8.3. Modelo Evolutivo

Los modelos evolutivos son modelos iterativos, permiten desarrollar

versiones cada vez más completas y complejas, hasta llegar al

objetivo final deseado; incluso evolucionar más allá, durante la fase

de operación. (Pressman, Ingenieria del Software, 2010)

La idea detrás de este modelo es el desarrollo de una implantación

del sistema inicial, exponerla a los comentarios del usuario, refinarla

en N versiones hasta que se desarrolle el sistema adecuado. Una

ventaja de este modelo es que se obtiene una rápida realimentación

del usuario, ya que las actividades de especificación, desarrollo y

pruebas se ejecutan en cada iteración.

2.1.8.4. Hacer prototipos

Es frecuente que un cliente defina un conjunto de objetivos generales

para el software, pero que no identifique los requerimientos

detallados para las funciones y características. En otros casos, el

desarrollador tal vez no esté seguro de la eficiencia de un algoritmo,

de la adaptabilidad de un sistema operativo o de la forma que debe

adoptar la interacción entre el humano y la máquina. En estas

24
situaciones, y muchas otras, el paradigma de hacer prototipos tal vez

ofrezca el mejor enfoque.

Aunque es posible hacer prototipos como un modelo de proceso

aislado, es más común usarlo como una técnica que puede

implementarse en el contexto de cualquiera de los modelos de

proceso descritos en este capítulo. Sin importar la manera en la que

se aplique, el paradigma de hacer prototipos le ayudará a usted y a

otros participantes a mejorar la comprensión de lo que hay que

elaborar cuando los requerimientos no están claros. El paradigma de

hacer prototipos (véase la figura 2.6) comienza con comunicación.

Usted se reúne con otros participantes para definir los objetivos

generales del software, identifica cualesquiera requerimientos que

conozca y detecta las áreas en las que es imprescindible una mayor

definición. Se planea rápidamente una iteración para hacer el

prototipo, y se lleva a cabo el modelado (en forma de un “diseño

rápido”). Éste se centra en la representación de aquellos aspectos del

software que serán visibles para los usuarios finales (por ejemplo,

disposición de la interfaz humana o formatos de la pantalla de

salida). El diseño rápido lleva a la construcción de un prototipo. Éste

se entrega y es evaluado por los participantes, que dan

retroalimentación para mejorar los requerimientos. La iteración

ocurre a medida que el prototipo es afinado para satisfacer las

necesidades de distintos participantes, y al mismo tiempo le permite

a usted entender mejor lo que se necesita hacer. El ideal es que el

25
 prototipo sirva como mecanismo para identificar los requerimientos

del software. Si va a construirse un prototipo, pueden utilizarse

fragmentos de programas existentes o aplicar herramientas (por

ejemplo, generadores de reportes y administradores de ventanas) que

permitan generar rápidamente programas que funcionen.

En la mayoría de los proyectos es raro que el primer sistema

elaborado sea utilizable. Tal vez sea muy lento, muy grande, difícil

de usar o todo a la vez. No hay más alternativa que comenzar de

nuevo, con más inteligencia, y construir una versión rediseñada en la

que se resuelvan los problemas. (Brooks, 1995)

2.1.8.4.1. Inconvenientes de hacer prototipos

El prototipo sirve como “el primer sistema”. Lo que Brooks

recomienda es desecharlo. Pero esto quizá sea un punto de vista

idealizado. Aunque algunos prototipos se construyen para ser

“desechables”, otros son evolutivos; es decir, poco a poco se

transforman en el sistema real. Tanto a los participantes como a

los ingenieros de software les gusta el paradigma de hacer

prototipos. Los usuarios adquieren la sensación del sistema real,

y los desarrolladores logran construir algo de inmediato. No

obstante, hacer prototipos llega a ser problemático por las

siguientes razones:

1. Los participantes ven lo que parece ser una versión funcional

del software, sin darse cuenta de que el prototipo se obtuvo

de manera caprichosa; no perciben que en la prisa por hacer

26
 que funcionara, usted no consideró la calidad general del

software o la facilidad de darle mantenimiento a largo plazo.

Cuando se les informa que el producto debe rehacerse a fin

de obtener altos niveles de calidad, los participantes gritan

que es usted un tonto y piden “unos cuantos arreglos” para

hacer del prototipo un producto funcional. Con demasiada

frecuencia, el gerente de desarrollo del software cede.

2. Como ingeniero de software, es frecuente que llegue a

compromisos respecto de la implementación a fin de hacer

que el prototipo funcione rápido. Quizá utilice un sistema

operativo inapropiado, o un lenguaje de programación tan

sólo porque cuenta con él y lo conoce; tal vez implementó

un algoritmo ineficiente sólo para demostrar capacidad.

Después de un tiempo, quizá se sienta cómodo con esas

elecciones y olvide todas las razones por las que eran

inadecuadas. La elección de algo menos que lo ideal ahora

ha pasado a formar parte del sistema.

Aunque puede haber problemas, hacer prototipos es un

paradigma eficaz para la ingeniería de software. La clave es

definir desde el principio las reglas del juego; es decir, todos los

participantes deben estar de acuerdo en que el prototipo sirva

como el mecanismo para definir los requerimientos. Después se

descartará (al menos en parte) y se hará la ingeniería del software

27
 real con la mirada puesta en la calidad. (Pressman, Ingenieria del

Software, 2010)

2.2.12.4. Tipos de desarrollo evolutivo

Desarrollo Exploratorio

El objetivo de este enfoque es explorar con el usuario los requisitos hasta

llegar a un sistema final. El desarrollo comienza con las partes que se

tiene más claras. El sistema evoluciona conforme se añaden nuevas

características propuestas por el usuario.

Enfoque utilizando prototipos

El objetivo es entender los requisitos del usuario y trabajar para mejorar

la calidad de los requisitos. A diferencia del desarrollo exploratorio, se

comienza por definir los requisitos que no están claros para el usuario y

se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a

terminar de definir estos requisitos.

2.2.12.5. Etapas

 Recolección y refinamiento de requisitos.

 Modelado, diseño rápido.

 Construcción del Prototipo.

 Desarrollo, evaluación del prototipo por el cliente.

 Refinamiento del prototipo.

 Producto de Ingeniería.

28
 Se comienza elaborando un prototipo del producto final: que aspecto

tendrá, como funcionará. Para muchas interfaces de usuario, este modelo

puede resultar tana simple como unos dibujos en lápiz y papel o tan

complejo como el propio código operativo final. Para interfaces

de hardware o estaciones de trabajo, el modelo puede consistir en maquetas

de espuma, caucho, cartón o cartulina. Cuanto más próximo se encuentre

el prototipo al producto real, mejor será la evaluación, si bien se pueden

obtener magníficos resultados con prototipos de baja fidelidad.

2.2.12.6. Ventajas

 No modifica el flujo del ciclo de vida.

 Reduce el riesgo de construir productos que no satisfagan las necesidades

de los usuarios.

 Reduce costo y aumenta la probabilidad de éxito.

 Exige disponer de las herramientas adecuadas.

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

Para que sea efectivo

 Debe ser un sistema con el que se pueda experimentar.

29
  Debe ser comparativamente barato (menor que el 10%).

 Debe desarrollarse rápidamente.

 Énfasis en la interfaz de usuario.

 Equipo de desarrollo reducido.

 Herramientas y lenguajes adecuadas.

2.2.12.7. Desventajas

 Debido a que el usuario ve que el prototipo funciona piensa que este es el

producto terminado y no entienden que recién se va a desarrollar

el software.

 El desarrollador puede caer en la tentación de ampliar el prototipo para

construir el sistema final sin tener en cuenta los compromisos de calidad

y mantenimiento que tiene con el cliente.

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

 En aras de desarrollar rápidamente el prototipo, el desarrollador suele

tomar algunas decisiones de implementación poco convenientes (por

30
ejemplo, elegir un lenguaje de programación incorrecto porque

proporcione un desarrollo más rápido). Con el paso del tiempo, el

desarrollador puede olvidarse de la razón que le llevó a tomar tales

decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a

formar parte del sistema final.

CAPITULO III

INTERVENCION METODOLOGICA

31
CAPITULO IV

RESULTADOS

32
CONCLUSIONES

33
 BIBLIOGRAFIA

1. Brooks. (1995).
2. Pressman, R. S. (2010). Ingeniería de Software - Un enfoque práctico. McGRAW-HILL
INTERAMERICANA EDITORES.

3. Pressman, R. S. (2010). Ingenieria del Software.

4. Sommerville, I. (2005). Ingeniería de Software (7ma ed.). (M. M. Romo, Ed.) Madrid:
PEARSON EDUCACION. Obtenido de
http://zeus.inf.ucv.cl/~bcrawford/EnfoquesDeDesarrolloDeSwYLenguajesDeModelado/Ing
enieria%20del%20Software%207ma.%20Ed.%20-%20Ian%20Sommerville.pdf

34