Modelo Incremental



Introducción:


El modelo incremental fue propuesto por Harlan Mills en el año 1980. Surgió el enfoque incremental de desarrollocomo una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirirexperiencia con el sistema. Este modelo se conoce también bajo las siguientes denominaciones:
  • Método de las comparaciones limitadas sucesivas.
  • Ciencia de salir del paso.
  • Método de atacar el problema por ramas.

El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la filosofía interactiva de Construcción de Prototipos. Como se muestra en la Figura 1, el modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. El primer incremento generalmente es un producto esencial denominado núcleo.

En una visión genérica, el proceso se divide en 4 partes:
  • Análisis
  • Diseño
  • Código
  • Prueba

imagen.png

Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o Pipeline. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabora el producto completo. De esta forma el tiempo de entrega se reduce considerablemente.

El Modelo Incremental es de naturaleza interactiva brindando al final de cada incremento la entrega de un producto completamente operacional. Este modelo es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añadirá personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos.

Durante el proceso se trata de llevar a cabo al proyecto en diferentes partes que al final terminará siendo la solución completa requerida por el cliente, pero éstas partes no se pueden realizar en cualquier orden, sino que dependen de lo que el cliente este necesitando con más urgencia, de los puntos más importantes del proyecto, los requerimientos más básicos, difíciles y con mayor grado de riesgo, ya que estos se deben hacer al comienzo, de manera que se disminuya la dificultad y el riesgo en cada versión.
De este modo podemos terminar una aplicación ejecutable (primera versión) que podrá ser entregada al cliente para que éste pueda trabajar en ella y el programador pueda considerar las recomendaciones que el cliente efectúe para hacer mejoras en el producto. Estas nuevas mejoras deberán esperar a ser integradas en la siguiente versión junto con los demás requerimientos que no fueron tomados en cuenta en la versión anterior.

El modelo incremental consiste en un desarrollo inicial de la arquitectura completa del sistema, seguido de sucesivos incrementos funcionales. Cada incremento tiene su propio ciclo de vida y se basa en el anterior, sin cambiar su funcionalidad ni sus interfaces. Una vez entregado un incremento, no se realizan cambios sobre el mismo, sino únicamente corrección de errores. Dado que la arquitectura completa se desarrolla en la etapa inicial, es necesario conocer los requerimientos completos al comienzo del desarrollo.

Al iniciar del desarrollo, los clientes o los usuarios, identifican a grandes rasgos, las funcionalidades que proporcionará el sistema. Se confecciona un bosquejo de requisitos funcionales y será el cliente quien se encarga de priorizar que funcionalidades son mas importantes. Con las funcionalidades priorizadas, se puede confeccionar un plan de incrementos, donde en cada incremento se indica un subconjunto de funcionalidades que el sistema entregará. La asignación de funcionalidades a los incrementos depende de la prioridad dada a los requisitos. Finalizado el plan de incrementos, se puede comenzar con el primer incremento.

Características:

  • Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta frecuencia.
  • El usuario se involucra mas.
  • Dificil de evaluar el costo total.
  • Dificil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo.
  • Requiere gestores experimentados.
  • Los errores en los requisitos se detectan tarde.
  • El resultado puede ser positivo.

Ventajas:

  • Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial.
  • También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del software.
  • El modelo proporciona todas las ventajas del modelo en Cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.
  • Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.

Desventajas:

  • El modelo incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido y/o de alto índice de riesgos.
  • Requiere de mucha planeación, tanto administrativa como técnica.
  • Requiere de metas claras para conocer el estado del proyecto.

Conclusión:


Un modelo incremental lleva a pensar en un desarrollo modular, con entregas parciales del producto Software denominados "incrementos" del sistema, que son escogidos en base a prioridades predefinidas de algún modo.
El modelo permite una implementación con refinamientos sucesivos (ampliación y/o mejoras).
Con cada incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien se mejora la versión previamente implementada del producto software.

Léxico Extendido del Lenguaje (LEL)


Número
Símbolo
Tipo
1
Análisis
Verbo
2
Analista
Sujeto
3
Codificación
Verbo
4
Desarrollador
Sujeto
5
Diseñador
Sujeto
6
Diseño
Verbo
7
Entregar el incremento
Verbo
8
Especificación de requisitos
Objeto
9
Incremento
Objeto
10
Incremento rechazado
Estado
11
Incremento validado
Estado
12
Modelo de arquitectura de software
Objeto
13
Modelo de diseño
Objeto
14
Núcleo
Objeto
15
Plan de incremento
Objeto
16
Producto
Objeto
17
Producto completo
Estado
18
Producto incompleto
Estado
19
Prueba
Verbo
20
Prueba de aceptación
Verbo
21
Prueba de integración
Verbo
22
Prueba unitaria
Verbo
23
Tester
Sujeto

Definición de Símbolos


Símbolo Nº: 1

Tipo: Verbo
Nombre/s
Análisis
Noción
  • Es la actividad en la que se obtienen e interpretan los requisitos de un incremento.
  • Es llevada a cabo por el analista.
Impacto
  • Se elicitan los requisitos del incremento con el cliente.
  • Se interpretan los requisitos obtenidos.
  • Se realiza el documento de especificación de requisitos.
  • Se validan los requisitos elicitados con cliente.

Símbolo Nº: 2

Tipo: Sujeto
Nombre/s
Analista

Noción
  • Es el encargado de realizar el análisis de los requisitos que corresponden a un incremento.
Impacto
  • Define cuales son las necesidades del cliente.
  • Se encarga de elicitar requisitos con el cliente.
  • Realiza el análisis de los requisitos de cada incremento.
  • Se encarga de realizar el documento de especificación de requisitos.

Símbolo Nº: 3

Tipo: Verbo
Nombre/s
Codificación
Noción
  • Es la actividad en la que se elabora la funcionalidad de un incremento.
  • Es realizada por el desarrollador.
  • Sucede luego de la actividad de análisis.
Impacto
  • Se desarrolla en base a los requisitos registrados en el documento de especificación de requisitos que corresponden a un incremento.
  • Agrega funcionalidad al producto.

Símbolo Nº: 4

Tipo: Sujeto
Nombre/s
Desarrollador
Noción
  • Es el encargado de realizar la codificación que corresponde a un incremento.
Impacto
  • Toma los requisitos del documento de especificación de requisitos que corresponden al incremento que se está elaborando.
  • Revisa el documento de especificación de requisitos.
  • Revisa el documento de modelo de diseño.
  • Realiza la codificación correspondiente a los requisitos de un incremento teniendo en cuenta el modelo de diseño detallado.

Símbolo Nº: 5

Tipo: Sujeto
Nombre/s
Diseñador
Noción
  • Es el encargado de realizar el modelo de diseño.
  • Es el encargado de realizar el modelo de arquitectura de software.
Impacto
  • Define el modelo de diseño en base al documento de especificación de requisitos.
  • Define el modelo de arquitectura del software en base al documento de especificación de requisitos.
  • Toma los requisitos que corresponden al incremento que se está elaborando.
  • Revisa el documento de especificación de requisitos.
  • Se encarga de llevar a cabo la actividad de diseño.

Símbolo Nº: 6

Tipo: Verbo
Nombre/s
Diseño
Noción
  • Es la actividad que permite llevar a cabo el modelo de diseño de un incremento.
  • Es la actividad que permite llevar a cabo el modelo de arquitectura de software de un incremento.
  • Es realizada por el diseñador.
  • Sucede luego de la actividad de análisis.
Impacto
  • Se revisan los requisitos del incremento que se encuentran en el documento de especificación de requisitos.
  • Se determina la estructura requerida para el incremento, la cual es realizada con el modelo de arquitectura de software.
  • Se detallan los componentes que se van utilizar para el incremento, los cuales se realizan con el modelo de arquitectura de software.
  • Se definen los diagramas a utilizar para el modelo de diseño del incremento.

Símbolo Nº: 7

Tipo: Verbo
Nombre/s
Entregar el incremento
Noción
  • Es la actividad que corresponde a la entrega del producto al cliente de la funcionalidad solicitada.
Impacto
  • Se realiza la instalación del incremento en el cliente.
  • Se realiza la prueba de aceptación con el cliente.
  • Se verifica que los requisitos del documento de especificación de requisitos coincidan con el incremento entregado.
  • El incremento es utilizado por el cliente.

Símbolo Nº: 8

Tipo: Objeto
Nombre/s
Especificación de requisitos
Noción
  • Es un documento que se confecciona durante la actividad de análisis.
  • Es toda la información necesaria para comprender la necesidad del cliente.
Impacto
  • Es confeccionado por el analista.
  • Contiene los requisitos del sistema que surgen en cada incremento.
  • El primer documento generado da origen al núcleo.
  • Es utilizado por el desarrollador para la codificación.
  • Es utilizado por el diseñador para realizar el modelo de diseño.
  • Es utilizado por el diseñador para realizar el modelo de arquitectura de software.

Símbolo Nº: 9

Tipo: Objeto
Nombre/s
Incremento
Noción
  • Es una porción del software que cumple con un conjunto de funcionalidades requeridas por el cliente.
  • Toda la documentación relevante del incremento y que es proporcionada por el cliente se vuelca en el plan de incremento.
Impacto
  • Cada incremento pasa por las siguientes actividades: análisis, diseño, codificación y prueba.
  • Es aceptado o rechazado en base a los resultados de la prueba de aceptación.
  • Cumple con un conjunto de requisitos solicitados por el cliente y que se encuentran documentados en la especificación de requisitos.

Símbolo Nº: 10

Tipo: Estado
Nombre/s
Incremento rechazado
Noción
  • Indica que un incremento no representa lo esperado por el cliente.
  • Se determina luego de realizar las pruebas de aceptación con el cliente.
Impacto
  • Se deben redefinir los requisitos que no fueron bien interpretados hasta que el incremento pase a ser un incremento validado.
  • Se vuelven a realizar las actividades de análisis y codificación.

Símbolo Nº:11

Tipo: Estado
Nombre/s
Incremento validado
Noción
  • Indica que un incremento representa lo esperado por el cliente.
  • Se determina luego de realizar las pruebas de aceptación con el cliente.
Impacto
  • Se puede proceder a la elaboración del siguiente incremento.
  • Si luego surgen nuevos requisitos los mismos se tendrán en cuenta en futuros incrementos y se deberá armar un nuevo plan de incremento.

Símbolo Nº: 12

Tipo: Objeto
Nombre/s
Modelo de arquitectura del software
Noción
  • Es un documento donde se indica la estructura e interacción entre las partes que componen el producto software.
Impacto
  • Es realizada por el diseñador.
  • Se realiza durante la actividad de diseño.
  • Se utiliza para elaborar la estructura general de la implementación del producto.
  • Define la relación entre los elementos estructurales del producto software.
  • Es utilizado para la actividad de codificación.

Símbolo Nº: 13

Tipo: Objeto
Nombre/s
Modelo de diseño
Noción
  • Es la representación de la solución en el desarrollo del producto.
Impacto
  • Es creado por el diseñador.
  • Se realiza durante la actividad de diseño.
  • Define las funcionalidades, los componentes y las interfaces que forman parte del producto.
  • Es utilizado para la actividad de codificación.

Símbolo Nº: 14

Tipo: Objeto
Nombre/s
Núcleo
Noción
  • Es el primer incremento entregado.
  • Es la base para futuros incrementos.
  • Contiene las principales funcionalidades del sistema.
Impacto
  • Genera una versión estable del producto.
  • Genera un producto completo.
  • Es determinado por el cliente luego de que éste haya seleccionado cuales requisitos de la especificación de requisitos formarán parte del primer incremento.

Símbolo Nº: 15

Tipo: Objeto
Nombre/s
Plan de incremento
Noción
  • Documento que contiene toda la información del incremento a elaborar.
  • Contiene las funcionalidades, fechas y responsables a incluir en el incremento.
Impacto
  • Se utiliza para organizar el próximo incremento a elaborar.
  • Lo lleva a cabo el analista.
  • Se elabora en conjunto con el cliente.

Símbolo Nº:16

Tipo: Objeto
Nombre/s
Producto
Noción
  • Es el software construido por el desarrollador.
  • Es la documentación que acompaña al software.
  • Son los datos que configuran el software.
  • Es lo que se entrega al finalizar un incremento.
Impacto
  • Se lo puede modificar en cualquiera de las fases del proceso de software.
  • Su creación comienza desde la actividad de análisis.
  • Si las pruebas de aceptación con el cliente son exitosas se lo considera producto completo.
  • Si las pruebas de aceptación con el cliente no son exitosas se lo considera producto incompleto.

Símbolo Nº:17

Tipo: Estado
Nombre/s
Producto completo
Noción
  • Sucede luego de que el producto cumple con los requisitos establecidos por el cliente.
Impacto
  • El producto puede ser entregado al cliente.
  • El producto es utilizado por el cliente.

Símbolo Nº:18

Tipo: Estado
Nombre/s
Producto incompleto
Noción
  • Sucede luego de que el producto no cumple con los requisitos establecidos por el cliente.
  • Indica que el producto no se encuentra apto para ser entregado.
Impacto
  • El producto no puede ser entregado al cliente.
  • El producto se debe corregir para poder concluir el incremento.
  • Una vez corregido, probado y aceptado por el cliente mediante las pruebas de aceptación, pasa a ser un producto completo y el incremento pasa a ser un incremento validado.

Símbolo Nº:19

Tipo: Verbo
Nombre/s
Prueba
Noción
  • Es la actividad que permite evaluar el funcionamiento del producto.
  • Sucede luego de la actividad de codificación.
  • Es realizada por el desarrollador.
  • Es realizada por el tester.
  • Es realizada por el cliente.
Impacto
  • El desarrollador puede llevar a cabo una prueba unitaria del producto.
  • El tester puede llevar a cabo una prueba de integración del producto.
  • El cliente puede llevar a cabo una prueba de aceptación del producto.

Símbolo Nº:20

Tipo: Verbo
Nombre/s
Prueba de aceptación
Noción
  • Sucede al momento de hacer la entrega del incremento al cliente.
  • Permite validar si el producto cumple con el funcionamiento esperado por el cliente.
  • Es realizada por el cliente.
Impacto
  • Identificar errores en el producto.
  • Utiliza diversos juegos de datos para llevar a cabo el ensayo.
  • Si el producto cumple con todos los requisitos esperados por el cliente, entonces el incremento pasa a ser un incremento validado.
  • Si el producto no cumple con todos los requisitos esperados por el cliente, entonces el incremento pasa a ser un incremento rechazado.

Símbolo Nº:21

Tipo: Verbo
Nombre/s
Prueba de integración
Noción
  • Sucede durante la actividad de codificación.
  • Se lleva a cabo sobre el producto a entregar teniendo en cuenta que la nueva funcionalidad se integre con lo que actualmente se encuentra funcionando.
  • Es realizada por el tester.
Impacto
  • Identificar errores en el producto.
  • Utiliza diversos juegos de datos para llevar a cabo el ensayo.
  • Los errores detectados son reportados al desarrollador para su corrección.

Símbolo Nº:22

Tipo: Verbo
Nombre/s
Prueba unitaria
Noción
  • Sucede durante la actividad de codificación.
  • Se lleva a cabo sobre el producto a entregar teniendo en cuenta solamente la funcionalidad que se agrega.
  • Es la actividad realizada por el desarrollador.
Impacto
  • Identifica errores en el producto.
  • Utiliza diversos juegos de datos para llevar a cabo el ensayo.
  • El desarrollador se encarga de corregir los errores detectados.

Símbolo Nº:23

Tipo: Sujeto
Nombre/s
Tester
Noción
  • Es el encargado de realizar las pruebas de integración del producto.
Impacto
  • Asegura que la funcionalidad que está probando se integre correctamente con el resto del producto.
  • Realiza la documentación de las pruebas de integración.
  • Informa los errores detectados para luego ser corregidos por el desarrollador.
  • Verifica las correcciones realizadas al producto por el desarrollador.

Referencias Bibliográficas


  • "Harlan D. Mills Award". IEEE Computer Society. Fecha: 13 de abril de 2011
  • Science and Engineering for Software Development: A Recognition of Harlan D. Mills' Legacy, IEEE Computer Society
  • Título: Modelo Incremental
Link: http://ingenieraupoliana.blogspot.mx/2010/10/modelo-incremental.html
Autor: Wynnie Calero (Estudiante de Ingeniería en Sistemas de Información de la Universidad Politécnica de Nicaragua(UPOLI))
Fecha: 8 de octubre de 2010
  • Título: Introducción Ingeniería de Software
Link: http://esalas334.blogspot.es/1193761920/
Fecha: 30 de octubre de 2007
  • Título: Ingeniería del Software
Autor: Roger Pressman
Editorial: MacGraw Hill - 5ta Edición
  • Título: Ingeniería del Software
Autor: Ian Sommerville
Editorial: Prentice Hall – 7ma Edición

Integrantes


GRUPO N° 02
  • Bermudez, Cristian
  • Garrido, Erika
  • Lara, Natalia
Surgió el enfoque incremental de desarrollo como una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema.