Modelado De Negocios 2.1.

1 Cascada

Modelo en Cascada (Bennington 1956): El ms conocido, esta basado en el ciclo convencional de una ingeniera, el paradigma del ciclo de vida abarca las siguientes actividades:

Ingeniera y Anlisis del Sistema: Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algn subconjunto de estos requisitos al software. Anlisis de los requisitos del software: el proceso de recopilacin de los requisitos se centra e intensifica especialmente en el software. El ingeniero de software (Analistas) debe comprender el mbito de la informacin del software, as como la funcin, el rendimiento y las interfaces

requeridas. Diseo: el diseo del software se enfoca en cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterizacin de la interfaz. El proceso de diseo traduce los requisitos en una representacin del software con la calidad requerida antes de que comience la codificacin. Codificacin: el diseo debe traducirse en una forma legible para la maquina. El paso de codificacin realiza esta tarea. Si el diseo se realiza de una manera detallada la codificacin puede realizarse mecnicamente. Prueba: una vez que se ha generado el cdigo comienza la prueba del programa. La prueba se centra en la lgica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren. Mantenimiento: el software sufrir cambios despus de que se entrega al cliente. Los cambios ocurrirn debido a que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos perifricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento. Desventajas: Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay iteraciones y se crean problemas en la aplicacin del paradigma. Normalmente, es difcil para el cliente establecer explcitamente al principio todos los requisitos. El ciclo de vida clsico lo requiere y tiene dificultades en acomodar posibles incertidumbres que pueden existir al comienzo de muchos productos. El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto, no estar disponible una versin operativa del programa. Un error importante no detectado hasta que el programa este funcionando puede ser desastroso. La ventaja de este mtodo radica en su sencillez ya que sigue los pasos intuitivos a la hora de desarrollar el software.

Metodologias De Desarrollo
2.1.2 Incremental
El Modelo Incremental combina elementos del MLS con la filosofa interactiva de construccin de prototipos. En una visin genrica, el proceso se divide en 4 partes: Anlisis, Diseo, Cdigo y Prueba. Sin embargo, para la produccin del Software, se usa el principio de trabajo en cadena o Pipeline, utilizado en muchas otras formas de programacin. Con esto s e 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 elabore el producto completo. De esta forma el tiempo de entrega se reduce considerablemente. Al igual que los otros mtodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional. El Modelo Incremental es particularmente til cuando no se cuenta con una dotacin de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se aadir personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos tcnicos. El Modelo Incremental se puede ver aqu en forma grafica: - Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia. - El usuario se involucra ms. - Difcil de evaluar el coste total.

- Difcil 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 muy positivo. Pipeline La arquitectura en pipeline (basada en filtros) consiste en ir transformando un flujo de datos en un proceso comprendido por varias fases secuenciales, siendo la entrada de cada una la salida de la anterior. Esta arquitectura es muy comn en el desarrollo de programas para el intrprete de comandos, ya que se pueden concatenar comandos fcilmente con tuberas (pipe). Tambin es una arquitectura muy natural en el paradigma de programacin funcional, ya que equivale a la composicin de funciones matemticas. Interprete de comandos Parte fundamental de un sistema operativo que ordena la ejecucin de mandatos obtenidos del usuario por medio de una interfaz alfanumrica. Caractersticas - Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia. - El usuario se involucre ms. - Dificil de evaluar el costo total. - Dficil 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 muy positivo. Ventajas: - Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial. - Tambin 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 slo al mbito de cada incremento. - Permite entregar al cliente un producto ms rpido en comparacin del modelo de cascada. - Resulta ms sencilo acomodar cambios al acotar el tamao de los incrementos. - Por su versatilidad requiere de una planeacin cuidadosa tanto a nivel administrativo como tcnico. 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. - Requere de mucha planeacion, tanto administrativa como tcnica. - Requiere de metas claras para conocer el estado del proyecto. Conclusion: Un modelo incremental lleva a pensar en un desarrollo modular, con entregas parciales del productoSoftware denomidados incrementos del sistema, que son escogidos en base a prioridades predefinidas de algn modo. El modelo permite una implementacin con refinacmientos sucesivos (ampliacin y/o mejora). Con cada incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien se mejora la versin previamente implementada del producto software

Metodologias De Desarrollo
2.1.2 Incremental
El Modelo Incremental combina elementos del MLS con la filosofa interactiva de construccin de prototipos. En una visin genrica, el proceso se divide en 4 partes: Anlisis, Diseo, Cdigo y Prueba. Sin embargo, para la produccin del Software, se usa el principio de trabajo en cadena o Pipeline, utilizado en muchas otras formas de programacin. Con esto s e 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 elabore el producto completo. De esta forma el tiempo de entrega se reduce considerablemente. Al igual que los otros mtodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional. El Modelo Incremental es particularmente til cuando no se cuenta con una dotacin de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se aadir personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos tcnicos. El Modelo Incremental se puede ver aqu en forma grafica: - Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia. - El usuario se involucra ms. - Difcil de evaluar el coste total.

- Difcil 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 muy positivo. Pipeline La arquitectura en pipeline (basada en filtros) consiste en ir transformando un flujo de datos en un proceso comprendido por varias fases secuenciales, siendo la entrada de cada una la salida de la anterior. Esta arquitectura es muy comn en el desarrollo de programas para el intrprete de comandos, ya que se pueden concatenar comandos fcilmente con tuberas (pipe). Tambin es una arquitectura muy natural en el paradigma de programacin funcional, ya que equivale a la composicin de funciones matemticas. Interprete de comandos Parte fundamental de un sistema operativo que ordena la ejecucin de mandatos obtenidos del usuario por medio de una interfaz alfanumrica. Caractersticas - Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia. - El usuario se involucre ms. - Dificil de evaluar el costo total. - Dficil 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 muy positivo. Ventajas: - Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial. - Tambin 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 slo al mbito de cada incremento. - Permite entregar al cliente un producto ms rpido en comparacin del modelo de cascada. - Resulta ms sencilo acomodar cambios al acotar el tamao de los incrementos. - Por su versatilidad requiere de una planeacin cuidadosa tanto a nivel administrativo como tcnico. 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. - Requere de mucha planeacion, tanto administrativa como tcnica. - Requiere de metas claras para conocer el estado del proyecto. Conclusion: Un modelo incremental lleva a pensar en un desarrollo modular, con entregas parciales del productoSoftware denomidados incrementos del sistema, que son escogidos en base a prioridades predefinidas de algn modo. El modelo permite una implementacin con refinacmientos sucesivos (ampliacin y/o mejora). Con cada incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien se mejora la versin previamente implementada del producto software