Caja Negra de Facebook

Caja Transparente de Facebook

PAGINA PRINCIPAL

REGISTRO NUEVO USUARIO

ENTRAR A LA CUENTA

CONFIGURACION DE LA PRIVACIDAD DE FACEBOOK

PUBLICAR ESTADO

BARRA DE BUSQUEDA

SALA DE CHAT

ENVIO DE MENSAJES

ACTUALIZAR INFORMACION DEL USUARIO

CENTRO DE APLICACIONES

MENU DE CONFIGURACIONES 

MENU CONFIGURACION DE LA CUENTA

Ingenieria Web

La ingeniería web es la aplicación de metodologías sistemáticas, disciplinadas y cuantificables al desarrollo eficiente, operación y evolución de aplicaciones de alta calidad en la World Wide Web.

La ingeniería web se debe al crecimiento desenfrenado que está teniendo la Web está ocasionando un impacto en la sociedad y el nuevo manejo que se le está dando a la información en las diferentes áreas en que se presenta ha hecho que las personas tiendan a realizar todas sus actividades por esta vía.

Desde que esto empezó a suceder el Internet se volvió más que una diversión y empezó a ser tomado más en serio, ya que el aumento de publicaciones y de informaciones hizo que la Web se volviera como un desafío para los (Ingeniería del software) ingenieros del software, a raíz de esto se crearon enfoques disciplinados, sistemáticos y metodologías donde tuvieron en cuenta aspectos específicos de este nuevo medio.

Los métodos de Ingeniería Web dirigidos por modelos han mejorado tanto la calidad como la eficiencia, a la hora de desarrollar aplicaciones Web. Estos métodos utilizan modelos conceptuales para capturar, de manera abstracta, una representación detallada de la aplicación Web a desarrollar. La ventaja más destacada de esta aproximación es que a partir de estos modelos, ampliamente validados en entornos industriales, es factible la generación sistemática del código que implementa la aplicación Web.

En esta línea de investigación se ha abordado el desarrollo de sistemas software para la Web, a partir de la construcción de modelos conceptuales. En este ámbito, los resultados de investigación abarcan tanto la descripción de los sistemas Web a nivel de modelado como la transformación de modelos al código Web.

A nivel de modelado se ha trabajado en: 

 (1) mejorar la captura de requisitos inherentes a los sistemas Web

 (2) ampliar el grado de adaptatividad de las aplicaciones actuales

 (3) dar soporte a las características que introducen los sitios Web Accesibles

 (4) la generación de servicios Web/REST

 (5) incluir aspectos colaborativos y de interfaces de usuario avanzadas propios de la Web 2.0

A nivel de implementación, se están aplicando nuevas técnicas al desarrollo de compiladores avanzados que transforman estos modelos conceptuales Web en código en una plataforma Web, como puede ser PHP, J2EE o gestores CMS.

La ingeniería de la Web no es un clon o subconjunto de la ingeniería de software aunque ambas incluyen desarrollo de software y programación, pues a pesar de que la ingeniería de la Web utiliza principios de ingeniería de software, incluye nuevos enfoques, metodologías, herramientas, técnicas, guías y patrones para cubrir los requisitos únicos de las aplicaciones web. Sin embargo el termino de ingeniería de la web ha sido un termino muy controvertido especialmente para profesionales en disciplinas tales como la ingeniería del software ya que no la consideran como un campo dentro de la ingeniería.

Los principales aspectos de la ingeniería de la Web incluyen, entre otros, los siguientes temas:

• Diseño de procesos de negocio para aplicaciones web.
• Herramientas CASE para aplicaciones web.
• Generación de código para aplicaciones web.
• Desarrollo web colaborativo.
• Modelado conceptual de aplicaciones web.
• Diseño de Modelos de datos para sistemas de información web.
• Ingeniería web empírica.
• Entornos de desarrollo de aplicaciones web integrados.
• Herramientas de autor para contenido multimedia.
• Pruebas de rendimiento de aplicaciones basadas en web.
• Personalización y adaptación de aplicaciones web.
• Herramientas y métodos de prototipado.
• Control de calidad y pruebas de sistemas.
• Ingeniería de requisitos para aplicaciones web.
• Aplicaciones para la Web Semántica.
• Factorías de software para la web.
• Métodos, herramientas y automatización de pruebas para aplicaciones web.
• Aplicaciones web móviles y ubícuas.
• Usabilidad de aplicaciones web.
• Accesibilidad para la web.
• Metodologías de diseño web.
• Formación en ingeniería de la web.
• Diseño de interfaces de usuario.
• Métricas para la web, estimación de costes y medición.
• Gestión de proyectos web y gestión de riesgos.
• Desarrollo y despliegue de servicios web.

Reingeniera del Software

La evolución del software ha constado de diferentes etapas de desarrollo, y una de ellas se llamo la “crisis del Software”. Esta crisis fue el resultado de la introducción de la tercera generación del Hardware. El hardware dejo de ser un impedimento para el desarrollo de la informática; redujo los costos y mejoro la calidad y eficiencia en el software producido.
A raíz de esta crisis se vio la necesidad de crear estándares de desarrollo del software, esto dio lugar a lo que hoy llamamos "Ingeniería de software" la cual es el establecimiento y uso de principios de la ingeniería a fin de obtener un software que sea fiable y que funcione eficientemente, con los menores costos posibles.

La reingeneiria del software la podemos definir como la modificación de un producto software, o de ciertos componentes, usando para el análisis del sistema existente técnicas de Ingeniería Inversa y, para la etapa de reconstrucción, herramientas de Ingeniería Directa, de tal manera que se oriente este cambio hacia mayores niveles de facilidad en cuanto a mantenimiento, re-utilización, comprensión o evaluación.

Cuando una aplicación lleva siendo usada años, es fácil que esta aplicación se vuelva inestable como fruto de las múltiples correcciones, adaptaciones o mejoras que han podido surgir a lo largo del tiempo. Esto deriva en que cada vez que se pretende realizar un cambio se producen efectos colaterales inesperados y hasta de gravedad, por lo que se hace necesario, si se prevé que la aplicación seguirá siendo de utilidad, aplicar reingeniería a la misma.

Entre los beneficios de aplicar reingeniería a un producto existente se puede incluir:

• Pueden reducir los riegos evolutivos de una organización.
• Puede ayudar a las organizaciones a recuperar sus inversiones en software.
• Puede hacer el software más fácilmente modificable
• Amplía las capacidades de las herramientas CASE
• Es un catalizador para la automatización del mantenimiento del software
• Puede actuar como catalizador para la aplicación de técnicas de inteligencia artificial para resolver problemas de reingeniería

La reingeniería del software involucra diferentes actividades como son:

• análisis de inventarios
• reestructuración de documentos
• ingeniería inversa
• reestructuración de programas y datos
• ingeniería directa

con la finalidad de crear versiones de programas ya existentes que sean de mejor calidad y los mismos tengan una mayor facilidad de mantenimiento.

Modelo Cliente - Servidor

La arquitectura cliente-servidor es un modelo de aplicación distribuida en el que las tareas se reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes, llamados clientes. Un cliente realiza peticiones a otro programa, el servidor, que le da respuesta. Esta idea también se puede aplicar a programas que se ejecutan sobre una sola computadora, aunque es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras

En la arquitectura C/S el remitente de una solicitud es conocido como cliente. Sus características son:

• Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la comunicación (dispositivo maestro o amo).
• Espera y recibe las respuestas del servidor.
• Por lo general, puede conectarse a varios servidores a la vez.
• Normalmente interactúa directamente con los usuarios finales mediante una interfaz gráfica de usuario
• Al contratar un servicio de redes, se debe tener en cuenta la velocidad de conexión que le otorga al cliente y el tipo de cable que utiliza.

Al receptor de la solicitud enviada por el cliente se conoce como servidor. Sus características son:

• Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempeñan entonces un papel pasivo en la comunicación (dispositivo esclavo).
• Tras la recepción de una solicitud, la procesan y luego envían la respuesta al cliente.
• Por lo general, aceptan conexiones desde un gran número de clientes (en ciertos casos el número máximo de peticiones puede estar limitado).
• No es frecuente que interactúen directamente con los usuarios finales.



Herramientas Case

Las herramientas CASE en ingles  (Computer Aided Software Engineering, Ingeniería de Software Asistida por Computadora) son diversasaplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero. Estas herramientas pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, cálculo de costos, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras.

Las herramientas CASE alcanzaron su techo a principios de los años 90. En la época en la que IBM había conseguido una alianza con la empresa de software AD/Cycle para trabajar con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de vida del software. Pero poco a poco los mainframes han ido siendo menos utilizados y actualmente el mercado de las Big CASE ha muerto completamente abriendo el mercado de diversas herramientas más específicas para cada fase del ciclo de vida del software.

Objetivos:

1. Mejorar la productividad en el desarrollo y mantenimiento del software.
2. Aumentar la calidad del software.
3. Reducir el tiempo y costo de desarrollo y mantenimiento de los sistemas informáticos.
4. Mejorar la planificación de un proyecto
5. Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de soluciones para los requisitos.
6. Automatizar el desarrollo del software, la documentación, la generación de código, las pruebas de errores y la gestión del proyecto.
7. Ayuda a la reutilización del software, portabilidad y estandarización de la documentación
8. Gestión global en todas las fases de desarrollo de software con una misma herramienta.
9. Facilitar el uso de las distintas metodologías propias de la ingeniería del software.

Clasificacion:

 las herramientas CASE se pueden clasificar teniendo en cuenta los siguientes parámetros:

1. Las plataformas que soportan.
2. Las fases del ciclo de vida del desarrollo de sistemas que cubren.
3. La arquitectura de las aplicaciones que producen.
4. Su funcionalidad.

Introducción a la Ingeniería del Software

¿QUE ES LA INGENIERIA DE SOFTWARE?

 

 El video nos explica todo sobre la Ingenieria del Software.

                                                    Fuente: http://www.youtube.com/watch?v=YFin8nNnARA

Sala Limpia en Ingeniería del Software

La ingeniería del software de sala limpia es un enfoque que hace hincapié en la necesidad de incluir la corrección en el software a medida que éste se desarrolla. En lugar del ciclo clásico de análisis, diseño, pruebas y depuración, el enfoque de sala limpia sugiere un punto de vista distinto

La filosofía que subyace tras la ingeniería del software de sala limpia consiste en evitar la dependencia de costosos procesos de eliminación de defectos, mediante la escritura de incrementos de código desde un primer momento, y mediante la verificación de su corrección antes de las pruebas.  Su modelo de proceso incluye la certificación estadística de calidad de los incrementos de código, a  medida que estos se van añadiendo con el sistema.

En muchos aspectos, el enfoque de sala limpia eleva la ingeniería del software a otro nivel. Al extender el enfoque adoptado en los métodos formales, el enfoque de sala limpia hace hincapié también en técnicas de control estadístico de calidad, incluyendo las comprobaciones basadas en el uso anticipado del software por parte de los clientes.

Caja Transparente

Las pruebas de caja blanca (también conocidas como pruebas de caja de cristal o pruebas estructurales) se centran en los detalles procedimentales del software, por lo que su diseño está fuertemente ligado al código fuente. El testeador escoge distintos valores de entrada para examinar cada uno de los posibles flujos de ejecución del programa y cerciorarse de que se devuelven los valores de salida adecuados.

Al estar basadas en una implementación concreta, si ésta se modifica, por regla general las pruebas también deberán rediseñarse.

Aunque las pruebas de caja blanca son aplicables a varios niveles —unidad, integración y sistema—, habitualmente se aplican a las unidades de software. Su cometido es comprobar los flujos de ejecución dentro de cada unidad (función, clase, módulo, etc.) pero también pueden testear los flujos entre unidades durante la integración, e incluso entre subsistemas, durante las pruebas de sistema.

A pesar de que este enfoque permite diseñar pruebas que cubran una amplia variedad de casos de prueba, podría pasar por alto partes incompletas de la especificación o requisitos faltantes, pese a garantizar la prueba exhaustiva de todos los flujos de ejecución del código analizado.

Las principales técnicas de diseño de pruebas de caja blanca son:

• Pruebas de flujo de control
• Pruebas de flujo de datos
• Pruebas de bifurcación (branch testing)
• Pruebas de caminos básicos

Pruebas de Software

La prueba es la ejecución de un programa con la intención de encontrar un error. Objetivos Descubrir un error. Una buena prueba es la que tiene una alta probabilidad de detectar un error. Una prueba tiene éxito si descubre un error no detectado hasta entonces. Principios de la prueba Hacer un seguimiento de las pruebas hasta los requisitos. Los errores más graves son aquellos que impiden que el software cumpla con los requisitos del cliente. Planificar las pruebas desde antes que comiencen. Aplicar el principio de Pareto. El 20% de las instrucciones provocan el 80% de los errores. Comenzar las pruebas por lo pequeño (módulos individuales) y terminar en lo grande (todo el sistema). No hacer pruebas exhaustivas. Las pruebas deben ser conducidas por un grupo independiente. Diseño de pruebas Pruebas de caja blanca. Examinan los detalles procedimentales. Comprueban los caminos lógicos. Examinan el estado del programa en varios puntos. Pruebas de caja negra. No toma en cuenta la estructura lógica. Examinan si las entradas se aceptan de forma adecuada y si se produce un resultado correcto. Revisa la integridad de la información externa (archivos). Pruebas de caja blanca. Prueba del camino básico Genera casos de prueba que garanticen que se ejecuta, por lo menos una vez, cada instrucción del programa. Usando el código dibujar el grafo de flujo. Obtener la complejidad ciclomática V(G). V(G) = aristas - nodos + 2, o V(G) = nodos predicado + 1 Especificar un conjunto básico de caminos linealmente independientes. Un camino independiente está constituido por lo menos por una arista que no haya sido recorrida anteriormente a la definición del camino. Preparar los casos de prueba que forzarán la ejecución de cada camino del conjunto básico. Prueba de condición Construye pruebas que ejecuten las condiciones lógicas. Prueba de flujo de datos Busca caminos de prueba de acuerdo a la definición y uso de las variables el programa. Si se limita el uso de variables globales, se puede eliminar estas pruebas. Prueba de ciclos Busca validar los ciclos. Ciclos independientes. Hacer casos de prueba para: Pasar por alto el ciclo. Entrar una sola vez. Entrar dos veces. Entrar m veces, con m < n. Entrar n - 1, n y n + 1 veces. Ciclos anidados. Aplicar las pruebas de ciclos independientes al ciclo más interno dejando los ciclos externos con sus valores mínimos. Seguir hacia afuera, dejando los ciclos externos con sus valores mínimos y los internos con valores "típicos". Continuar hasta probar todos los ciclos. Ciclos dependientes. Aplicar el enfoque usado para los ciclos anidados. Pruebas de caja negra. Partición equivalente. Divide el dominio de la entrada del módulo en clases de datos de las cuales se pueden derivar casos de pruebas. Las clases se pueden derivar de acuerdo a cada variable de entrada: Si es un rango, se define una clase válida y dos no válidas. Si es un valor específico, se define una clase válida y dos no válidas. Si es miembro de un conjunto, se define una clase válida y una no válida. Si es booleana, se define una clase válida y una no válida. Pruebas de valores límite Desarrollar pruebas para ejercitar los valores límite en las entradas y salidas (p.e. generar el número máximo o mínimo de datos a desplegar). Prueba de la interface gráfica de usuario (GUI) Hacer casos de prueba para revisar: Ventanas. Accesabilidad de los componentes dentro de la ventana. Funciones operativas de la ventana (cerrar, mover, ajuste del tamaño). Nombre de cada ventana. Colores de la ventana de acuerdo a la especificación. Menús. Contexto adecuado de los menús. Nombres claros de las opciones. Checar cada opción. Checar los short-cuts. Fuente y tamaño de texto adecuada. Ayuda sensible al contexto. Entradas de datos. Validación de los datos de entrada. Mensajes de error adecuados.

Caja Negra

Se denomina caja negra a aquel elemento que es estudiado desde el punto de vista de las entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su funcionamiento interno. En otras palabras, de una caja negra nos interesará su forma de interactuar con el medio que le rodea (en ocasiones, otros elementos que también podrían ser cajas negras) entendiendo qué es lo que hace, pero sin dar importancia a cómo lo hace.

Por tanto, de una caja negra deben estar muy bien definidas sus entradas y salidas, es decir, su interfaz; en cambio, no se precisa definir ni conocer los detalles internos de su funcionamiento.

Cuando de un subsistema se conocen sólo las entradas y las salidas pero no los procesos internos se dice que es una caja negra.

Un sistema formado por módulos que cumplan las características de caja negra será más fácil de entender ya que permitirá dar una visión más clara del conjunto. El sistema también será más robusto y fácil de mantener, en caso de ocurrir un fallo, éste podrá ser aislado y abordado más ágilmente.

Sitio Web - Descargar Avance

Ingresa a este link y podras descargar el avance del Sitio Web de Distribuidora J.RUIZ

Sitio WEB-J. RUIZ-Kevin Palacios

SISTEMATICO 2

1) Realizar un pequeño mural con recortes periodisticos aceca de lo que las empresas estan requiriendo (ofertas de puestos) en el area informatica, desde el dia en que entramos a clases.

2) Del proyecto realizado a nivel de Análisis y Diseño estructurado y orientado a objetos, calcule las métricas orientadas al tamaño, punto de función y aplicadas así como las metricas de calidad.

 Diagrama de Contexto

 

3)De la tabla de Analisis de Riesgo. (Dar Ejemplos)

4)Preparar material didáctico acerca de la garantía de calidad y garantía de configuración del software para ser expuesto en plenario 

 

SISTEMATICO 1

1) Mediante las tecnicas cuadro sinoptico, dibujo o marco logico conceptual explique las caracteristicas del software.

El software se desarrolla no se construye.

El software no se estropea

 

 El software se desarrolla a medida

 

2) Ejemplifique cada una de las aplicaciones de software

• software de sistema:

                    sistemas contables

• software de tiempo real:   

                    redes sociales como facebook, twitter, hi5, etc

• software de gestion:

                    Sidunea World

• software de ingenieria y cientifico: 

                    Softwares aplicados a dipositivos medicos como el Ultrasonido

• software de pc: 

                   controladores, sistemas operativos

• software basado en web 

                 Transacciones en linea, Tiendas Online como Amazon

• software de inteligencia artificial: 

                  Dispositivos como fotocopiadoras

3)Mediante un dibujo establezca los escenarios donde se reflejan los mitos y realidades del software en cuanto a gestion, cliente y desarrollo. 

4)Explique las capas (dibujo del pastel) de desarrollo de software. 

Calidad: Cuando hablamos de calidad nos enfocamos a la parte del Analisis de Dicho Sistema, lo que llevara, cuanto tiempo vamos a demorar en desarrollarlo , que tipo de aplicacion sera, etc.

Proceso: Es a travez de que manera lo vamos a desarrollar dicho software

Metodos: En esta fase tenemos que estar claros de todo lo que constituira nuestro software y asi implementar las tecnicas de desarrollo.

Herramientas: Aqui nos enfocamos en el lenguaje de programacion que tomaremos para lograr el desarrollo de Software por ejemplo Java, C++, Visual Studio entre otros y quien del equipo se dedicara a las diferentes estructuras de dicho proyecto.

5) Testifique cuales situaciones ha aplicado los modelos de desarrollo del software.

1. El modelo secuencial lo hemos utilizado en programacion en aquellos programas que no requieren de mucho trabajo.
2.  El modelo de desarrollo de software lo hemos aplicado a los proyectos de programacion en Java los cuales necesitaban de otros paquetes para que su funcionalidad sea estable.
3. El modelo de prototipo lo aplicamos en programacion con la herrameinta Visio de la paqueteria de Office.

 

CUESTIONARIO 1

1) Sabiendo las caracteristicas del software, ejemplifique como se aplicaria a un sistema contable.

Para Iniciar hay que enfocarse en el Analisis y Diseño de Sistemas para asi poder tener una colecion de datos que nos seran utiles al desarrollar nuestro software, es decir saber lo que realmente desea para su empresa o su pequeño negocio. Entre los datos a tomar en cuenta es lo que el sistema contable realizara, ya que en terminos de Contabilidad hay que ser precisos, en cuanto tiempo se puede desarrolar, desarrollar en el mismo un sistema de cuenta de usuario para no permitir que se viole la informacion ya que seria un delito,entre otros.

 

2) Mencione las Diferencias entre un tipo de aplicacion de Software y otro de los tantos estudiados en clases.

Software de Hoja de Calculo: por medio de estos programas el usuario puede trabajar y operar con datos que sean alfanuméricos que se encuentran distribuidos en columnas y filas. Por medio de este programa el usuario logra realizar operaciones aritméticas y también gráficos.

Software en tiempo real: Estos son todas las aplicaciones web que nos permiten la comunicacion rapida entre 1 o mas personas. Entre estos estan: Facebook, Windows Live Messenger, Twitter, Sonico, Google Plus, etc.

 

 

3) Explique en que consiste el grafico del pastel.

 
El pastel graficamente nos muestra los procesos a llevar a cabo a la hora de desarrollar nuestro software, empezando por saber el tipo de aplicacion a desarrollar, a travez de que herramientas podemos desarrollar dicho sistema. Es decir no podemos dejar a un lado ninguno de estos metodos esenciales a la hora de trabajar.

4) Elabore un cuadro sinoptico con las fases genericas que se practican durante el proceso del software.

 5) Proponga una situación donde tenga que hacer el uso de hito que se expresa en el marco de trabajo común de la Ing. de Software.

Hito:  herramienta que admin. En forma integrada y centralizada los requerimientos que llegan a las áreas de soporte de las empresas.

Situación: Decisión importante para las empresas o para un proyecto.

-Evento significativo para el desarrollo de un proyecto. 

 6) En que consisten los modelos de desarrollo de software y a que situacion los aplicaria.

El modelo de etapas 

Este modelo estipula que el software será desarrollado en sucesivas etapas: 
Plan operativo

• Especificación de requerimientos
• Especificación funcional
• Diseño
• Implementación
• Integración
• Validación y verificación
• Mantención

El modelo de cascada

El modelo de cascada es también conocido como “Modelo en cascada” o “Modelo lineal secuencial” o “Ciclo de vida básico” o “Ciclo de vida clásico”.

 

Es un refinamiento altamente influenciado para 1970 del modelo de etapas. Existe, para este modelo, un reconocimiento de los ciclos de retroalimentación entre etapas, y una guía para confinar las retroalimentaciones a las etapas sucesivas con el objetivo de minimizar el costo del retrabajo involucrado en retroalimentaciones a través de muchas etapas.

El modelo de desarrollo orientado a prototipos

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. 

 

 

El modelo espiral

El modelo es representado por una espiral dividida en cuatro cuadrantes, en que cada uno describe las actividades mencionadas anteriormente. El modelo espiral utiliza un esquema de desarrollo iterativo donde la primera iteración comienza en el centro del círculo e, incrementalmente, se va desplazando hacia afuera. Las siguientes iteraciones sucesivas son versiones más completas del software que está siendo construido. Al principio de cada iteración del ciclo de vida se hace un análisis de riesgo, mientras, por el otro extremo, la revisión del proyecto se realiza al final de la iteración. Así, se puede contrarrestar cualquier riesgo observado mediante las acciones adecuadas en el tiempo preciso.

 El modelo Basado en Componentes

El Desarrollo de Software Basado en Componentes (DSBC) trata de apoyar las bases para el diseño y desarrollo de aplicaciones distribuidas basadas en componentes software reutilizables. Esta norma cuenta en la actualidad con una utilidad, tanto desde el panorama académico como desde el industrial, en donde su demanda de temas es cada día mayor.

La finalidad primordial de (DSBC) es entender los diferentes modelos de desarrollo de software y la importancia de sus componentes y servicios. También evaluar las diferencias entre este modelo y los estudiados anteriormente en el transcurso de desarrollar este tipo de software.

 El modelo Incremental

El Modelo Incremental combina elementos del MLS con la filosofía interactiva de construcción de prototipos.

En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o “Pipeline”, utilizado en muchas otras formas de programación. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento.