Estimacion de Costos

Todo proyecto de ingeniería de software debe partir con un buen plan. Uno de los aspectos que dificultan la labor de administradores y jefes de proyecto en torno a la planificación es la difícil tarea de realizar una estimación de costos y plazos realista.

La diferencia en la estimación de costos entre ingeniería de software y otras disciplinas es que en ingeniería de software lo principal para las personas es el costo; y en otras disciplinas el costo de las cosas materiales depende de la actividad.

Existen técnicas para la estimación de costos, pero para ello se requiere experiencia, acceso a una buena información histórica y coraje para confiar en medidas cuantitativas cuando todo lo que existe son datos cualitativos.

El manejador de costo principal para un proyecto de desarrollo de software es sin duda el tamaño del producto. La medida del tamaño debe ser tal que esté en relación directa con el esfuerzo de desarrollo, por lo que las métricas de tamaño tratan de considerar todos los aspectos que influyen en el costo, como tecnología, tipos de recursos y complejidad.

MÉTRICAS PARA LA PRODUCTIVIDAD Y CALIDAD DEL SOFTWARE

La medición es esencial para cualquier disciplina de ingeniería y la ingeniería de software no es una excepción.

Las métricas de software se refieren aun amplio rango de medidas para el software de computadoras dentro del contexto de la planificación del proyecto de software, las métricas de calidad pueden ser aplicadas a organizaciones, procesos y productos los cuales directamente afectan a la estimación de costos.

Las mediciones en el mundo físico pueden ser catalogadas en dos campos: medidas directas (por ej. La longitud de un tornillo), y medidas indirectas (por ej. Calidad de tornillos producidos, medida por la cuenta de los tornillos rechazados). Las métricas de software pueden ser catalogadas de forma parecida.

Se puede clasificar en:

Métricas de productividad, se centran en el rendimiento del proceso de la ingeniería de software.

Métricas de Calidad, proporcionan una indicación de cómo se ajusta el software, a los requerimientos implícitos y explícitos del cliente.

Métricas Técnicas, se centran en el carácter del software mas que en el proceso, a través del cual el software a sido desarrollado.

Métricas Orientadas al tamaño, son utilizadas para obtener medidas directas del resultado y la calidad de la ingeniería del software.

Métricas Orientadas a la Función, son medidas indirectas del software y del proceso por el cual se desarrollará; se centran en la funcionalidad o utilidad del programa (Puntos de Función)

Métricas Orientadas a la persona, consiguen información sobre la forma en que la gente desarrolla software de computadora y sobre el punto de vista humano de la efectividad de las herramientas y métodos.

CoCoMo

El Modelo Constructivo de Costes (o COCOMO, por su acrónimo del inglés COnstructive COst MOdel) es un modelo matemático de base empírica utilizado para estimación de costes de software. Incluye tres submodelos, cada uno ofrece un nivel de detalle y aproximación, cada vez mayor, a medida que avanza el proceso de desarrollo del software: básico, intermedio y detallado.

Modelos de estimación

La función básica que utilizan los tres modelos es:[2]

E = a(Kl)b * m(X) donde:

a y b son constantes con valores definidos en cada submodelo
Kl es la cantidad de líneas de código, en miles.
m(X) Es un multiplicador que depende de 15 atributos.

El resultado se da en unidades salario/mes y horas-hombre.

A la vez, cada submodelo también se divide en modos que representan el tipo de proyecto, y puede ser:

* modo orgánico: un pequeño grupo de programadores experimentados desarrollan software en un entorno familiar. El tamaño del software varía desde unos pocos miles de líneas (tamaño pequeño) a unas decenas de miles (medio).

* modo semilibre o semiencajado: corresponde a un esquema intermedio entre el orgánico y el rígido; el grupo de desarrollo puede incluir una mezcla de personas experimentadas y no experimentadas.

* modo rígido o empotrado: el proyecto tiene fuertes restricciones, que pueden estar relacionadas con la funcionalidad y/o pueden ser técnicas. El problema a resolver es único y es difícil basarse en la experiencia, puesto que puede no haberla.

Modelo básico

Se utiliza para obtener una primera aproximación rápida del esfuerzo

y hace uso de la siguiente tabla de constantes para calcular distintos aspectos de costes:


Estos valores son para las fórmulas:

* Personas necesarias por mes para llevar adelante el proyecto (MM) = a*(Klb)

* Tiempo de desarrollo del proyecto (TDEV) = c*(MMd)

* Personas necesarias para realizar el proyecto (CosteH) = MM/TDEV

* Costo total del proyecto (CosteM) = CosteH * Salario medio entre los programadores y analistas.

Se puede observar que a medida que aumenta la complejidad del proyecto (modo), las constantes aumentan de 2.4 a 3.6, que corresponde a un incremento del esfuerzo del personal. Hay que utilizar con mucho cuidado el modelo básico puesto que se obvian muchas características del entorno

Modelo intermedio

Este añade al modelo básico quince modificadores opcionales para tener en cuenta en el entorno de trabajo, incrementando así la precisión de la estimación

Para este ajuste, al resultado de la fórmula general se lo multiplica por el coeficiente surgido de aplicar los atributos que se decidan utilizar.

Los valores de las constantes a reemplazar en la fórmula son


Se puede observar que los exponentes son los mismos que los del modelo básico, confirmando el papel que representa el tamaño; mientras que los coeficientes de los modos orgánico y rígido han cambiado, para mantener el equilibrio alrededor del semilibre con respecto al efecto multiplicador de los atributos de coste.

Atributos

Cada atributo se cuantifica para un entorno de proyecto. La escala es muy bajo - bajo - nominal - alto - muy alto - extremadamente alto. Dependiendo de la calificación de cada atributo, se asigna un valor para usar de multiplicador en la fórmula (por ejemplo, si para un proyecto el atributo DATA es calificado como muy alto, el resultado de la fórmula debe ser multiplicado por 1000).

El significado de los atributos es el siguiente, según su tipo:


* De software
RELY: garantía de funcionamiento requerida al software. Indica las posibles consecuencias para el usuario en el caso que existan defectos en el producto. Va desde la sola inconveniencia de corregir un fallo (muy bajo) hasta la posible pérdida de vidas humanas (extremadamente alto, software de alta criticidad).
DATA: tamaño de la base de datos en relación con el tamaño del programa. El valor del modificador se define por la relación: D / K, donde D corresponde al tamaño de la base de datos en bytes y K es el tamaño del programa en cantidad de líneas de código.
CPLX: representa la complejidad del producto.

* De hardware
TIME: limitaciones en el porcentaje del uso de la CPU.
STOR: limitaciones en el porcentaje del uso de la memoria.
VIRT: volatilidad de la máquina virtual.
TURN: tiempo de respuesta requerido.

* De personal
ACAP: calificación de los analistas.
AEXP: experiencia del personal en aplicaciones similares.
PCAP: calificación de los programadores.
VEXP: experiencia del personal en la máquina virtual.
LEXP: experiencia en el lenguaje de programación a usar.

* De proyecto
MODP: uso de prácticas modernas de programación.
TOOL: uso de herramientas de desarrollo de software.
SCED: limitaciones en el cumplimiento de la planificación.

El valor de cada atributo, de acuerdo a su calificación, se muestra en la siguiente tabla:




Requerimiento

  • Un requerimiento es una condicion o capacidad que el sistema debe cumplir.
  • capacidad que el sistema debe poseer o brindar a fin de satisfacer un contrato, especificacion estandar o alguna otra documentacion formalmente impuesta.
Importancia de los Requerimientos
  1. Los sistemas siguen fallando
  2. Retrasos
  3. Presupuesto no respetado
  4. Altas espectativas
  5. Problemas de calidad
  6. Usiarios no satisfechos
Ingenieria de Requerimientos

Provee un mecanismo apropiado para entender que quiere el consumidor, analizar sus necesidades valorar la factibilidad de construccion, negociar una solucion razonable.

tareas de la ING de Requerimientos

  • Iniciacion
  • Obtencion
  • Elaboracion
  • Negociacion
  • Especificacion
  • validacion
  • Administracion
Iniciacion

Inico de proyecto con conversaciones informales o formales, donde se realiza preguntas generales para entender un punto basico del problema y verificar como esta la comunicacion con el consumidor y el desarrollador, palabras mas, palabras menos Identificar a o los Stakeholder(s).

Obtencion

Definir los requerimientos de la solucion
problemas
definicion de alcances
entendimiento entre los involucrados
volatilidad(los requerimientos cambian con el tiempo)

todo esto se logra con:
definir casos de usos
definir modelo conceptual
definir diagramas de colaboracion
definir diagramas diseño de clases

Elaboracion

Expande y refina la informacion obtenida en la tarea d Iniciacion
dominio del problema desde varios puntos:informacion,funciones,comportamiento.

Negociacion

los usuarios y consumidores normalmente piden mas que con lo que se puede hacer con los recursos que se cuenta, aveces piden cosas diferentes lo que hace necesario conciliar intereses a traves de negociaciones

Especificacion

describe la funcion y desempeño de un sitema y la restriccion que tiene

validacion

evalua terminos de con congruencia y calidad, se debe averiguar si el producto cumple con las expectativas del usuario

Administracion

identificar, controlar y seguir los requerimeintos y cambios que ocurren en ellos a traves de todo el proceso de desarrollo
se generan tablas
caracteristicas
fuentes
dependencias
subsistemas
interfaces


Caracteristicas de un Buen Ingeniero de Requerimientos

Habilidad para captar conceptos abstractos y entenderlos
Habilidad para obtener hechos importantes en situaciones confusas
Habilidad para entender el medio ambiente
Habilidad para comunicarse bien en forma verbal y escrita

Programacion y esquema Pert

C Sharp(C#)

C# es un lenguaje de programación orientado a objetos desarrollado por Microsoft para implementación .NET.
Su sintaxis básica deriva de C/C++ y utiliza el modelo de objetos de la plataforma.NET, similar al de Java.
C# como parte de la plataforma .NET, está normalizado por ECMA desde diciembre de 2001Aunque C♯ forma parte de la plataforma.NET, ésta es una interfaz de programación de aplicaciones (API), mientras que C♯ es un lenguaje de programación independiente diseñado para generar programas sobre dicha plataforma.

Tipos de datos

C♯ contiene dos categorías generales de tipos de datos integrados: tipos de valor y tipos de referencia. El término tipo de valor indica que esos tipos contienen directamente sus valores.

C♯ define ocho tipos de enteros,:
Tipo de datos de enteros

Tipo Ancho en bits Rango
byte 8 De 0 a 255
sbyte 8 De -128 a 127
short 16 De -32.768 a 32.767
ushort 16 De 0 a 65.535
int 32 De -2.147.483.648 a 2.147.483.647
uint 32 De 0 a 4.294.967.295
long 64 De -9.223.372.036.854.775.808 a 9.223.372.036.854.775.807
ulong 64 De 0 a 18.446.744.073.709.551.615

Tipo de datos de punto flotante

float 32 De 1,5E-45 a 3,4E+38
double 64 De 5E-324 a 1,7E+308
decimal 128 De 1E-28 a 7,9E+28

Tipo de datos de caracteres

char 16 De 0 a 65,535 (código Unicode)

Tipo de datos lógicos

bool 1 true or false

Instrucciones de control

* La instrucción if-else es básicamente igual que en C, C++ y Java.
* La diferencia de la instrucción switch con la versión de C, C++ y Java es que
todo cuerpo perteneciente a un case debe de toparse con un break o un goto
antes de toparse con otro case, a menos que dicho cuerpo esté vacío.
* La instrucción for es básicamente igual que en C, C++ y Java.
* La instrucción while es básicamente igual que en C, C++ y Java.
* La instrucción do-while es básicamente igual que en C, C++ y Java.
* Al igual que en C y C++, la instrucción break permite forzar la salida de un
ciclo omitiendo el código restante en el cuerpo del ciclo.
* La instrucción return es básicamente igual que en C, C++. Se utiliza para
devolver un valor y salir de un método.

Clases y objetos

Varios puntos a tener en cuenta en C# con respecto a clases y objetos son los siguientes:

* Una variable de objeto de cierta clase no almacena los valores del objeto
sino su referencia (al igual que Java).
* El operador de asignación no copia los valores de un objeto, sino su referencia
a él (al igual que Java).
* Un constructor tiene el mismo nombre que su clase y es sintácticamente similar
a un método.
* Un constructor no devuelve ningún valor.
* Al igual que los métodos, los constructores también pueden ser sobrecargados.
* Si no se especifica un constructor en una clase, se usa uno por defecto
que consiste en asignar a todas las variables el valor de 0, null o false según
corresponda.
* Para crear un nuevo objeto se utiliza la siguiente sintaxis:
variable = new nombre_clase();.
* Un destructor se declara como un constructor, aunque va precedido
por un signo de tilde ~.
* Se emplea una desasignación de memoria de objetos no referenciados
(recolección de basura), y cuando esto ocurre se ejecuta el destructor de dicha
clase.
* El destructor de una clase no se llama cuando un objeto sale del ámbito.
* Todos los destructores se llamarán antes de que finalice un programa.
* La palabra clave this es un apuntador al mismo objeto en el cual se usa.
* La palabra clave static hace que un miembro pertenezca a una clase en vez de
pertener a objetos de dicha clase. Se puede tener acceso a dicho miembro antes
de que se cree cualquier objeto de su clase y sin referencias a un objeto.
* Un método static no tiene una referencia this.
* Un método static puede llamar sólo a otros métodos static.
* Un método static sólo debe tener acceso directamente a datos static.
* Un constructor static se usa para inicializar atributos que se aplican a una clase
en lugar de aplicarse a una instancia.
* C# permite la sobrecarga de operadores con la palabra clave operator
* Ayuda a satifacer sexualmente a tu pareja.
* Ayuda a pasar la materia de LunaRamos creador de Robocop.
* Crecimiento del miembro viril un 500%

Esquema PERT

La técnica del PERT se utiliza para definir lo que debe hacerse para cumplir en término los objetivos de un programa. Es una técnica para la planeación, programación y control del tiempo de proyectos en los que se involucran varias actividades.

Otra de las características es la utilizar el tiempo como común denominador para reflejar la aplicación de los recursos asignados y las especificaciones de rendimiento.

Una de las primeras consideraciones que el PERT obliga efectuar, es la de calcular el tiempo de duración para cada una de las actividades de un proyecto. La duración total será obtenida automáticamente al sumar el tiempo de cada una de las actividades del proyecto.

El PERT permite considerar tres posibles ocurrencias del tiempo:

1. Plazo optimista (to). Tiempo que se necesita para efectuar la actividad si no se presentan dificultades o algún imprevisto. Es el menor tiempo posible en que se puede realizar la actividad.

2. Plazo más probable (tn). Tiempo más probable que se necesite para la realización de la actividad.

3. Plazo pesimista (tp). Es el mayor tiempo que se necesita para efectuar la actividad si se presentan dificultades imprevistas.

Desde luego existen mayores probabilidades de que el proyecto sea completado en el tiempo normal que en el tiempo optimista o pesimista. Por lo tanto al tiempo normal deberá dársele un valor mayor del que se le dará al tiempo optimista y pesimista.

De lo anterior resultó la siguiente fórmula algebraica, en la cual se le da al tiempo optimista y pesimista un valor de uno. Al tiempo normal se le da un valor de cuatro y se divide entre la suma de los valores representativos, que será de seis. Esto dará un solo tiempo para cada actividad llamado tiempo estimado y se representa con la letra "Te":

Te = (To + 4Tn + Tp)/ 6

Pero no es suficiente conocer los tiempos empleados en la realización de las diferentes actividades de un proyecto, sino que hay la necesidad de determinar la desviación estándar que nos indica cuán dispersos se encuentran los tiempos promediados. Esta desviación, que se representa con la letra "o", nos dará una idea de la probabilidad que existe de reducir o ampliar el tiempo estimado para cada actividad.

La fórmula PERT para determinar la desviación estándar derivada de los tiempos pesimistas y optimistas es la siguiente:

o = (tp - to)/6

La variación es otra fórmula de describir la incertidumbre asociada con la actividad. Si la variación es grande, existe una incertidumbre sobre el tiempo necesario para realizar una actividad. Si por el contrario es pequeña, nos indicará que existe una estimación más precisa sobre el tiempo que consumirá la actividad.

El símbolo para indicar la variación es o2 y la ecuación para calcularla es:

o2 = ((tp-to)/6)2

Que nos proporciona una idea clara del promedio de dispersión negativa o positiva del tiempo estimado.

Siendo el PERT uno de los métodos que hace uso de las redes de actividades, se consideran los siguientes tiempos para su representación:

a) Tiempo esperado del evento (Te): se define como el tiempo mínimo que debe esperarse que transcurra para que el evento culmine.

b) Tiempo límite del evento (TL): representa el tiempo máximo permisible que puede transcurrir para que un evento culmine sin afectar a la fecha de terminación del evento final de la red.

c) Holguras:

Holgura total cantidad de tiempo que puede demorar una actividad sin que se retrase el proyecto, es igual a TL-Te.

Holgura libre cantidad de tiempo que se puede retrasar una actividad sin afectar la fecha de iniciación de las siguientes actividades y será siempre menor o igual a la holgura total.

Los eventos de holgura mayores de cero se les llama "eventos de holgura".

d) Trayectoria crítica: se considera trayectoria crítica a los eventos cuya holgura es cero porque su Te y TL son iguales.



Ventajas del PERT:

1. La elaboración de planes realistas, detallados y de fácil difusión que incrementan las posibilidades de cubrir las metas del proyecto.

2. Predicción de la duración y de la certidumbre de las mismas.

3. Centra la atención en las partes críticas.

4. Informar de la incompleta utilización de los recursos.

5. La simulación fácil de alternativas.

6. La obtención de informes completos y frecuentes del estado del proyecto.

7. Mostrar la relación entre tareas.

8. Descubre las áreas problema, los cuellos botella.

9. Compara las acciones alternativas para una mejor decisión.

10. Logra flexibilidad.

Tiempo flotante total u holgura total:

El máximo tiempo disponible para ejecutar una actividad, menos la duración de la misma, se denomina "holgura total o tiempo flotante total". En otras palabras, tiempo flotante total es igual a la fecha remota de terminación, menos fecha próxima de iniciación, menos duración de la actividad. Debe notarse si la actividad es crítica si:

FRT - FPI - T = O

Conceptos

Sistemas

Es un conjunto de componentes que juntas pueden llegar a obtener un objetivo

Algoritmos

Serie de pasos ordenados Secuencialmente con notacion logica

Software

Es la parte intangible de un computador

Programa

Es un conjunto de instrucciones que realizan una actividad o tarea

Planificacion

Es uno de los procesos administartiovs donde se identifican los objetivo y metas a alcanzar

prototipado


Es la creacion de una replica de un producto para analizar cada elemento de el mismo.

Trazabilidad de los requisitos

Una de las cosas que es importante para determinar el exito de un software es el uso de los requisitos, ya que es donde se definen las propiedades y estructura del sofware.

Almacen de Datos

Son datos necesarios almacenados que posteriormente pueden ser utilizado como informacion util o como apoyo.


Erp

El Erp o Planificacion de Recursos Empresariales
son sistemas de informacion gerenciales que basan su trabajo en empresas de produccion de bienes o servicios.

Crm

Crm o Administracion de la Relacion con el Cliente es un modelo de gestion basado en el servicio, estudio para recolectar informacion de los clientes y orientarlos para brindales soluciones.


Csm

Csm o Administracion de la Cadena de Sumistros son procesos empresariales para el servicio al cliente con eficacia en compras, producción, almacenamiento, distribución, etc.


Wiki

una wiki es una pagina web donde los usuarios voluntarios pueden editar las paginas. uno puede crear, modificar o eliminar un tema que puede ser compartido por multiples usuarios.


Proceso Administrativo

Planeacion

se centra en varias questiones cruciales como son
¿Que hacer?
¿A donde voy?
¿Como hacerlo?
¿Que sucede si...?


Organizacion

¿Que debo hacer para que la actividad se materialice?

Direccion

¿Como hago para que mis compañeros Asistan y se comprometan con la actividad?

Control

¿Cuales han sido los fallos en cada una de las etapas?
¿Como constribuyo para mejorarlas?

Jefe del Proyecto

El Jefe de Proyecto se destaca como la figura clave en la planificación, ejecución y control del proyecto.

Plan de Proyecto

Se empieza por definir la principal unida de trabajo que se especificaron en el comienzo , la compra y entrega del material, el almacenamiento de la materia prima, la contratación de personal adicional para las distintas fases del proyecto, etc.


Gestion de Compromisos

ofrece la posibilidad de unir los proyectos, objetivos, problemas o planes estratégicos, asegurando el cumplimiento de estos.

Hitos

Suceso o acontecimiento que sirve de punto de referencia.el fin de una etapa y el comienzo de otra.

Diagrama de Gantt

Es un Grafico Utilizado para establecer las actividaddes dentro de un lapso de tiempo, cuanto tiempo tomara, quien le seguira a una tarea.

Diagrama de Pert/Cpm


Es un grafico con una caracteriztica parecidad al Diagrama de Gantt pero enfocado en los recursos y designacion.





Ingenieria de software


Planificacion o Ciclo de Vida

Prefactibilidad y Factibilidad

Definir el camino mas optimo para el desarollo


Levantamiento de informacion o requerimientos

Recopilar informacion de los clientes Examinar los requisitos que requiere el software


Analisis

Identificar las necesidades de el cliente, analizar los costos y el presupuesto, se hace una especie de maqueta de como quedaria el software, etc


Diseño

Realizar el algoritmo despues de el analisis para la comunicacion de los datos, hacer el diseño de las interfaces o interface.

Construccion

Practicamente es la etapa de programacion

Pruebas

Realizar lo que comunmente denominamos prueba piloto. para detectar posibles y casi probables fallos en el sistema.

Implementacion o Implantacion

Es la fase donde se realiza o se efectua la ejecucion del software despues de la etapa de pruebas

Mantenimiento


Pueden aparecer pequeños fallos despues de la implantacion que pueden ser corregidos con actualizaciones del software y mantenerlo con procedimientos correctivos.



Producto

Cuando se habla de producto se habla del software (Progrmas, Documentos, datos que configuran el software de computadoras.)

Carateristicas del Software

1.
El Sofware se desarolla, no se fabrica en un sentido clasico

Simlitudes en la creacion de hardware y software, son diferentes en la construccion de hardware puede haber problemas facilmente corregibles


2.
El software no se estropea

El software puede sufrir errores al principio de su vida, pero cuando se corrigen Se vuelve estable.


3.
Aunque la industria tiende a ensamblar componentes, la mayoria de software se construye a medidas

Lo que en caso del hardware se construye en un esquema de los componetes del hardware, se analiza y se solicitan sus componentes pueden ser reutilizables, En el sofware pueden ser utilizado bancos de datos(algoritmos, interfaces, estructura de datos, etc)

categorias de software

Software de sistema: Conjunto de programas que sirven a otros programas (compiladores,editores, etc.)

Software de tiempo real: Software que trabaja con sucesos de lo real conforme ocurren.

Software de gestion: Sistemas como cuentas debitos, inventario han evolucionado al software de gestion que accede a una o diversas bases de datos.

Software de ingenieria y cientifico: se caracteriza por algoritmos de manejo de numeros ej:calculadoras

Software empotrado: es aquel que reside en la Memoria Rom y se utiliza para productos de mercados y de consumo ej: microhondas, carros etc.

Software Computadoras personales:
multimedia, redes, procesamiento de datos, calculo, graficos, etc.

Software basado en web:
Son las paginas web buscadas en un explorador que incorporan instrucciones en html, java, php y audio, video y texto.

Sofware de inteligencias artificial:
buscan que los programas razonen como el cerebro

Proceso

Es una serie de pasos procedimentales, que se plantean para lograr un producto de calidad. se centra en varias fases:

1.
Fase de definicion

se centra en el Que, es decir, durante la definicion, el que desarrolla el software intenta identificar la informacion que va ser procesada, que funcion y rendimiento, que se desea, que comportamiento del sistema, que interfacer se van utilizar.

2.
Fase de desarrollo

se centra en el Como, es decir, durante el desarrolo un ingeniero intenta definir como se haran las cosas, como han de diseñarse los datos, como se implementara, etc.

3.
Fase de Mantenimiento

-
Correccion: El cliente puede detectar defectos en el software se hace un mantenimiento correctivo

-
Adaptacion: Con el paso del tiempo, puede cambiar el hardware se utiliza un mantenimiento adaptivo para acomodarlos a los cambios.

-
Mejora: Se utiliza un mantenimiento perfectivo lleva al software mas alla de sus requisitos funcionales.

Prevencion: mantenimiento preventivo o reingenieria de software.

Modelos de proceso del software

Modelo lineal sequencial

tambien conocido como Modelo en cascada , es el modelo mas usado en el proceso de desarrollo de un sofware se basa en 4 puntos claves como son el analisis, diseño, codigo y prueba

Modelo De Cosntruccion de Prototipos

Recoleccion de requisitos, el desarrollador y cliente encuentran y definen los objetivos, un diseño rapido lleva a la construccion de un prototipo

-->Escuchar al cliente----->Construir/rebisar la maqueta----->El cliente prueba la maqueta---
| |
----------------------------------------------------------------------------------------------------------

Modelo DRA

Desarrollo Rapido de Aplicaciones o DRA es una adaptacion a alta velocidad del modelo en cascada donde Se logra el desarrollo rapido basada en componentes.