1. Uia PoeinlItricpiai d
ndd rfsoa nedsilnra e
Igneí yCeca Scae y
neira
inis oils
Amnsrtvs
diitaia.
UNIDAD DE APRENDIZAJE
HERRAMIENTAS AUTOMATIZADAS
GRUPO:
2NM50
ACTIVIDAD:
MODELO INCREMENTAL
ALUMNOS:
CANO NAVARRO ISRAEL ALEJANDRO
CORNEJO GONZALEZ ALAN NERY
JAÉN VARGAS BRANDON
RIVERA IBARRA JORGE ALBERTO
SALGADO FLORES LIGORIO EDWIN
FECHA DE ENTREGA:
29 DE AGOSTO DE 2013
1
3. Introducción
La ingeniería del software es una disciplina de la ingeniería que comprende todos los
aspectos de la producción de software desde las etapas iniciales de la especificación del
sistema hasta el mantenimiento de este después que se utiliza. (ingeniería de software,
Sommerville). La IEEE define la ingeniería de software como la aplicación de un enfoque
sistemático, disciplinado y cuantificable al desarrollo, operación (funcionamiento) y
mantenimiento del software (Abran & IEEE, 2005).
Al inicio, el desarrollo de software era artesanal en su totalidad, la fuerte necesidad de
mejorar el proceso y llevar los proyectos a la meta deseada, tuvieron que importarse la
técnicas, modelos y fundamentos de metodologías existentes en otras áreas y
adaptarlas al desarrollo de software. Así surgió la ingeniería de software y con ella las
metodologías de desarrollo Esta nueva etapa de adaptación contenía el desarrollo
dividido en etapas de manera secuencial (Metodología de cascada) que en parte
mejoraba la necesidad latente en el campo del software.
Las metodologías de desarrollo de software se refieren a un conjunto estandarizado de
conceptos, prácticas y criterios usados para estructurar, planear y controlar el proceso de
desarrollo en sistemas de información (CMS, 2005). El desarrollo de los sistemas
tradicionales de ciclo de vida se originó en la década de 1960 para desarrollar a gran
escala sistemas de negocio con mayor funcionalidad en una época de grandes
conglomerados empresariales. La idea principal era continuar el desarrollo de los
sistemas de información en una forma muy deliberada, estructurada y metódica,
reiterando cada una de las etapas del ciclo de vida (Wikipedia, 2013).
Las metodologías de desarrollo se pueden clasificar en según su enfoque (y también
según su evolución histórica) en metodologías tradicionales y metodologías ágiles, las
primeras pensadas para el uso exhaustivo de documentación durante todo el ciclo del
proyecto, mientras que las segundas ponen vital importancia en la capacidad de
respuesta a los cambios, la confianza en las habilidades del equipo y al mantener una
buena relación con el cliente.
Entre las principales metodologías tradicionales, también llamadas formales, tenemos los
ya tan conocidos Cascada, Incremental, RUP (IBM) y MSF (Microsoft) entre otros, que
centran su atención en llevar una documentación exhaustiva de todo el proyecto y centran
su atención en cumplir con un plan de proyecto, definido todo esto, en la fase inicial del
desarrollo del proyecto.
3
4. En contraste a lo anterior, las metodologías ágiles dan mayor valor al individuo, a la
colaboración con el cliente y al desarrollo incremental del software con iteraciones muy
cortas. Este enfoque está mostrando su efectividad en proyectos con requisitos muy
cambiantes y cuando se exige reducir drásticamente los tiempos de desarrollo pero
manteniendo una alta calidad. Las metodologías ágiles están revolucionando la manera
de producir software (Canós, Letelier, & Penadés, 2002).
Este caso de estudio se centra en la metodología incremental, para dar un marco de
referencia adecuado para el lector se tiene que retroceder en el concepto y detallar a su
predecesora la metodología en cascada llamado por muchos ingenieros en software
como “El Ciclo de Vida Clásico”, sugiere un enfoque sistemático y secuencial para el
desarrollo de software.(Pressman)
Modelo en cascada
El modelo en cascada es el paradigma más antiguo para la ingeniería de software, este
marco se trabajo se basa en siete etapas: I. Identificación del problema, oportunidades y
objetivos. II. Determinación de los requerimientos de información. III. Análisis de las
necesidades del sistema. IV. Diseño del sistema recomendado. V. Desarrollo y
documentación del software. VI. Pruebas y mantenimiento del sistema. VII. Implantación y
evaluación del sistema.
Este modelo es también llamado ‘Lineal secuencial’. Proporciona una simple visión del
desarrollo del Software. A los procesos los representa como fases separadas y
secuenciales en tiempo. Antes de codificar debemos diseñar el software, además
probarlo antes de construirlo y ponerlo en operación.
El modelo de cascada representó un avance significativo en la ingeniería de software
frente al desarrollo artesanal, facilitó y dio simplicidad al diseño y modelaje de sistemas y
a la planificación de proyectos. Se convirtió en casi un estándar en la industria y fue el
modelo a seguir por la mayoría de directores de proyecto, analistas y programadores,
incluso al día de hoy sus fases son conocidas por casi todos los desarrolladores. Además
fue el primer modelo en facilitar la comprensión del sistema que se estaba construyendo
para el cliente y aún mejor para los usuarios.
4
5. Sin embargo en los últimos años se ha cuestionado la eficiencia del método de cascada,
en parte porque es una metodología ‘anticuada’, diseñada para sistemas de información
basados paradigmas de programación y lenguajes en desuso en el ámbito empresarial,
algunas de las deficiencias que presenta este método para las necesidades actuales de
la industria del software son:
● Los proyectos actuales raramente siguen un proceso lineal como el definido en
este ciclo de vida.
● Es difícil que el cliente exponga explícitamente todos los requisitos al principio.
● El cliente debe tener paciencia pues obtendrá el producto solo al final del ciclo de
vida.
● No refleja exactamente cómo se programa realmente el sistema, en el que suele
haber un gran componente iterativo.
● Puede resultar complicado regresar a etapas anteriores (ya acabadas) para
realizar correcciones.
● El producto final obtenido puede que no refleje todos los requisitos del usuario.
● La naturaleza del modelo en cascada conduce a estados de bloque en los cuales
algunos miembros del equipo del proyecto tienen que esperar a otros para
terminar tareas dependientes.
Lo anterior no quiere decir que el modelo en cascada sea obsoleto en lo absoluto, este
modelo de proceso puede ser útil en un proyecto donde los requerimientos están fijos y
donde el trabajo se realiza de principio a fin de manera lineal.
Modelo Incremental
El modelo incremental es un modelo tipo cascada el cual origina una primera versión con
su respectiva funcionalidad, posteriormente se aplica de nuevo cascada sobre aquella
primer versión y se obtiene una segunda versión con más una funcionalidad. Este proceso
se repite hasta terminar el desarrollo.
Fue propuesto por Mills en 1980. Sugiriendo una forma de reducir la repetición del trabajo
en el proceso del desarrollo y dar la oportunidad de retrasar la toma de decisiones en
los requisitos hasta adquirir experiencia con el sistema.
5
6. El modelo incremental tiene un enfoque lineal e iterativo:
● Lineal porque sigue cada uno de los pasos de cascada para desarrollar cada una
de las versiones del sistema.
● Iterativo porque el modelo se repite varias veces, siempre logrando un sistema
más robusto y cercano a las necesidades del cliente con cada repetición o
iteración.
Múltiples ciclos de desarrollo toman lugar aquí, convirtiendo el ciclo de vida en un “ciclo
de múltiple cascada”. El proyecto es dividido en pequeños módulos más fáciles de
manejar, cada módulo pasa a través de las fases de requerimientos, diseño,
implementación y prueba. Bajo este modelo se entrega software “por partes funcionales
más pequeñas”, pero reutilizables, llamadas incrementos o iteraciones. En general cada
incremento se construye sobre aquel que ya fue entregado. (Véase figura 1) Luego de
cada incremento se entrega un producto con mayor funcionalidad que el previo. El
proceso se repite hasta finalizar el desarrollo y lograr el software final (Alarcos, 2012).
Figura 1. Esquema de la metodología incremental
Fuente: (Aruquipa, n.d.)
Siendo iterativo, con el modelo incremental se entrega un producto parcial pero
completamente operacional en cada incremento, y no una parte que sea usada para
reajustar los requisitos (como sí ocurre en el modelo de construcción de prototipos).
Desarrollar un software de manera incremental resulta más barato y provee mayor
facilidad para realizar cambios conforme este se diseña, ya que se avanza en una serie
de pasos hacia una solución y se retrocede cuando se detecta algún error.
6
7. Ventajas de la Metodología Incremental vs. Método de Cascada
Al comparar la metodología incremental con su antecesor, el modelo en cascada, el
desarrollo incremental tiene tres beneficios importantes:
1. Se reduce el costo de adaptar requerimientos cambiantes del cliente. La
cantidad de análisis y documentación que se debe reelaborar es menor.
2. Se obtiene retroalimentación inmediata del cliente sobre el trabajo que se
realizó.
3. Es posible que la entrega e implementación de software útil sea más rápida.
El desarrollo en incrementos proporciona una progresiva funcionalidad para el cliente en
cada etapa. El modelo incremental debe ser desarrollado en un lapso de tiempo en
donde, con ayuda de un calendario, se registran las fases completadas y así se podrá
contemplar con anticipación las fases futuras.
El primer incremento tienden a ser los requisitos básicos que proporciona el cliente. La
esencia del producto usualmente es evaluada por el mismo. Después de la evaluación se
obtiene un plan de desarrollo para el siguiente incremento. Así, en cada incremento es
necesario tener en mente más características y funciones que puedan ser añadidas al
núcleo del proyecto.
El proceso de evaluación se realizará por el cliente en cada incremento del proyecto hasta
su finalización. Los incrementos anteriores al incremento principal es llamado como la
versión “simplificada” del proyecto final. Estas versiones son las evaluadas por el cliente.
En base a eso, el cliente puede sugerir nuevos requerimientos.
Uno de los beneficios del modelo incremental es que puede ser usado para planear
riesgos técnicos. Si el número de trabajadores en el equipo de trabajo es reducido, es
conveniente considerar completar cada etapa antes de la fecha límite. Si la esencia del
proyecto esta bien definida, en caso de ser necesario, es posible añadir más personal al
equipo de trabajo.
Actualmente la metodología incremental sigue vigente en el desarrollo de sistemas, a
continuación se explican las fortalezas por la cuales sigue siendo un método utilizado y
también sus debilidades.
7
8. Fortalezas de la metodología incremental
➔ La entrega inicial del proyecto es rápida.
➔ El costo de entrega inicial es reducido.
➔ La esencia del proyecto es desarrollada primero, por lo tanto la funcionalidad
principal es agregada desde el primer incremento.
➔ Después de cada iteración, se debe realizar una prueba de regresión. Durante
ésta prueba, los elementos defectuosos del software pueden ser identificados
rápidamente porque algunos cambios son realizados en una sola iteración (CMS,
2005).
➔ Generalmente es más fácil probar y corregir que usar los otros métodos de
desarrollo de software porque relativamente hay pequeños cambios en cada
iteración.(Technotrice, n.d.)
➔ En cada revisión, una nueva característica es agregada al proyecto.
➔ La carga de trabajo es menor.
➔ Permite una mejor explotación del potencial de conocimientos adquiridos en un
incremento temprano mientras se desarrollan incrementos posteriores
(Sommerville & Alfonso Galipienso, 2005).
➔ El control moderado se mantiene durante la vida del desarrollo del proyecto
mediante el uso de documentación escrita, revisión formal y aprobación por parte
del usuario.(Technotrice, n.d.)
➔ Se pueden dar pruebas concretas de la situación del proyecto a las partes
interesadas durante todo el ciclo de vida.
➔ Ayuda a mitigar los riesgos de integración y arquitectura más temprano en el
proyecto.
➔ Permite la entrega de una serie de implementaciones que se completan
gradualmente y pueden entrar en producción más rápidamente como versiones
incrementales (CMS, 2005).
➔ La implementación gradual proporciona la capacidad de controlar el efecto de los
cambios incrementales, aislar los problemas y hacer ajustes antes de la
organización se vea afectada (Sommerville & Alfonso Galipienso, 2005).
Debilidades de la metodología incremental
➔
➔
➔
➔
8
Requiere un buen análisis.
El costo resultante puede ser superior al presupuesto de la organización.
Cada fase de iteración es fija, por lo tanto no es posible el traslape con otra fase.
Cuando una característica es añadida al proyecto, pueden surgir problemas con la
arquitectura del sistema, los cuales no son visibles en los prototipos anteriores
9. ➔ Cuando se utiliza una serie de mini cascadas para una pequeña parte del sistema
antes de pasar al siguiente incremento, por lo general hay una falta de
consideración global del problema de la empresa y los requisitos técnicos para el
sistema general.(CMS, 2005)
➔ Dado que algunos módulos se completarán mucho antes que otros, se requieren
interfaces bien definidas.(CMS, 2005)
➔ El proceso no es visible. Los administradores necesitan entregas regulares para
medir el avance. Si los sistemas se desarrollan rápidamente, resulta poco efectivo
en términos de costo producir documentos que reflejen cada versión del sistema
(Sommerville & Alfonso Galipienso, 2005).
➔ La estructura del sistema tiende a degradarse conforme se tienen nuevos
incrementos. la incorporación demás cambios de software se vuelve cada vez más
difícil y costosa (Sommerville & Alfonso Galipienso, 2005).
➔ Los problemas difíciles tienden a ser empujados hacia el futuro para demostrar el
éxito inicial de la gestión (CMS, 2005).
Modelo DRA (Desarrollo Rápido de Aplicaciones)
Es un modelo de proceso de desarrollo de Software lineal secuencial que enfatiza un ciclo
de desarrollo extremadamente corto (es una adaptación a alta velocidad del modelo lineal
secuencial).
Permite al equipo de desarrollo crear un sistema completamente funcional dentro de
períodos de tiempo muy cortos. El DRA comprende las siguientes etapas:
●
●
●
●
●
Modelado de Gestión
Modelado de Datos
Modelado del Proceso
Generación de Aplicaciones
Prueba y Entrega
En el modelado de gestión se modela el flujo de información entre las funciones de
gestión. Este flujo debe responder a preguntas tales como: ¿quién la genera?, ¿hacia
dónde va la información?, ¿quién la procesa?
En el modelado de datos se definen las características (atributos) de cada objeto formado
a partir del flujo de información, y las relaciones entre ellos.
En el modelado del proceso, las descripciones del proceso se crean para añadir,
modificar, suprimir o recuperar un objeto de datos.
9
10. La generación de aplicaciones en lugar de crear software, el RAD reutiliza componentes
de programas ya existentes o crear componentes reutilizables. Los componentes ya han
sido examinados y probados, lo cual permite que el tiempo de duración de las pruebas
sea menor.
Algunas de las desvantajas de este modelo podrían ser que en proyectos a gran escala
se requieren recursos humanos suficientes como para crear el número suficiente de
equipos, además debe haber un compromiso muy fuerte entre todas las partes para
completar el sistema en el tiempo necesario, es por esto que no es adecuado
implementar la métodología DRA cuando los riesgos técnicos son muy altos.
Bibliografía
Abran, A., & IEEE. (2005). Guide to the software engineering body of knowledge: 2004
version. Los Alamitos, CA: IEEE Computer Society Press.
Alarcos. (2012). Ciclo de vida del software. Universidad de CastillaLa Mancha. Retrieved
from http://alarcos.infcr.uclm.es/doc/ISOFTWAREI/Tema03.pdf
Aruquipa, O. (n.d.). Análisis comparativos de los distintos ciclo de vida en el software.
UAGRM DIPLOMADO 2012 GERENCIA DE PROYECTOS DE DESARROLLO DE
SOFTWARE. Retrieved from http://oscararuquipacolque.blogspot.mx/
Canós, J. H., Letelier, P., & Penadés, M. C. (2002). Métodologías Ágiles en el Desarrollo de
Software. Retrieved from http://noqualityinside.com.ar/nqi/nqifiles/XP_Agil.pdf
CMS. (2005, February 17). Selecting a development aproach. CMS. Retrieved from
https://www.cms.gov/ResearchStatisticsDataandSystems/CMSInformationTechnology/
XLC/Downloads/SelectingDevelopmentApproach.pdf
PRESSMAN, R. S. A., & Murrieta, J. E. M. (2005). Ingeniería del software: un enfoque
práctico.
Mcgraw
Hill/Interamericana
Editores.
Retrieved
from
http://books.google.es/books?id=rEoxQQAACAAJ
Sommerville, I., & Alfonso Galipienso, M. I. (2005). Ingeniería del software. Madrid: Pearson
AddisonWesley.
Technotrice. (n.d.). Incremental Model In Software Engineering : What Is It? Advantages &.
Retrieved
August
29,
2013,
from
http://www.technotrice.com/incrementalmodelinsoftwareengineering/
Wikipedia. (2013). Metodología de desarrollo de software. Retrieved August 29, 2013, from
http://es.wikipedia.org/wiki/Metodolog%C3%ADa_de_desarrollo_de_software
10