Este enfoque metodolgico que ordena rigurosamente las etapas del ciclo de vida del software, de forma tal

que el inicio de cada etapa debe esperar a la finalizacin de la inmediatamente anterior. la palabra cascada sugiere, mediante la metafora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases ms avanzadas de un proyecto. Modelo en Cascada: El mas conocido, esta basado en el ciclo convencional de una ingeniera, el paradigma del ciclo de vida abarca las siguientes actividades: - Ingenieria y Anlisis del Sistema - Anlisis de los Requisitos - Diseo - Codificacin - Prueba - Mantenimiento 1.- 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 algun subconjunto de estos requisitos al software. 2.- ANLISIS DE SISTEMAS DE COMPUTACIN Se lleva a cabo teniendo den cuenta ciertos principios: - Debe presentarse y entenderse el dominio de la informacin de unproblema. - Defina las funciones que debe realizar el Software. - Represente el comportamiendo del Software a consecuencias de acontecimientos externos. - Divida en forma jerrquica los modelos que represerntan la informacin, funciones y comportamiento. Se analizan las necesidades de los usuarios finales del Software para determinar que objetivos debe cubrir. 3.- DISEO

Traduce los requisitos en una representacion del Software con la calidad requerida antes de que comience la codificacin. - Diseo del sistema: Se descompone y organiza el sistema en elementos que puedad elaborarse por separado, aprovechando los ventajas del desarrollo en equipo, as como la manera en que se combinan unos con otros. - Diseo del Programa: Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario as como tambin los anlisis necesarios para saber que herramientas usar en la etapa de Codificacin. 4.- CODIFICACIN El diseo debe traducirse en una forma legible para la maquina. Se implementa el cdigo fuente. Dependiendo del lenguaje de programacion y su versin se crean las libreras y componentes reutilizables dentro del mismo proyecto para hacer que la programacin sea un proceso mucha ms rpido. 5.- PRUEBA Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente antes de ser puesto en explotacin. Las pruebas de Software, testing o beta testing es un proceso usado para identificar posibles fallos. En general, los usuarios distinguen entre errores de programacion ( o bugs ) y defectos de forma. en un defecto de forma, el programa no realiza lo que el usuario espera. Por el contrario, un error de programacin puede describirse como un fallo en la semntica de un rpograma de ordenador. A la versin del producto de pruebas y que es anterior a la versin final ( o master ) se denomina beta, y a dicha fase de pruebas, beta testing. Finalmente y antes de salir al mercado, es cada vez ms habitual que se realice una fase de RTM testing ( Release To Market ), dnde se comprueba cada funcionalidad del programa completo en entornos de produccin. 6.- IMPLANTACIN El Software obtenido se pone en produccin. Se implantan los niveles Software y Hardware que componen el proyecto. La implantacin es la fase con ms duracin y con ms cambios en el ciclo de elaboracin de un proyecto. Es una de las fases finales del proyecto. Durante la explotacin del sistema Software pueden surgir cambios, bien para corregir errores o bien para introducir mejorar. Todo ello recoge en los Documentos de Cambios. 7.- 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.

Ventajas: - Se tiene todo bien organizado y no se mezclan las fases. - Es perfecto para proyectos que son rigidos. - Idieal para proyectos donde se especifiquen muy bien los requerimientos. - Ideal para proyectos en que se conozca muy bien la herramienta a utilizar. - Sumamente sencillo ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el Software. Desventajas: - Difcilmente un cliente va a establecer al principio todos los requerimientos necesaros, por lo que provoca un gran atraso trabajando en este modelo, ya que este es muy restrictivo y no permite movilizarse entre fases. - Los resultados y/o mejoras no son visibles, el producto se ve recin cuando este est finalizado.

El Desarrollo en Espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985, utilizado generalmente en la Ingeniera de software. Las actividades de este modelo son una espiral, cada bucle es una actividad. Para cada actividad habr cuatro tareas: No. 1 Planificacin: Determinacin de objetivos, alternativas y restricciones. Revisamos todo lo hecho, evalundolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la prxima actividad. No. 2 Anlisis de riesgo: Anlisis de alternativas e identificacin/resolucin de riesgos. No. 3 Ingeniera: Desarrollo del producto del siguiente nivel Tareas de la actividad propia y se prueba. Anlisis de alternativas e identificacin resolucin de riesgos. No.4 Evaluacin del cliente: Valorizacin de los resultados de la ingeniera. Ventajas: - El anlisis del riesgo se hace de forma explcita y clara. Une los mejores elementos de los restantes modelos. - Reduce riesgos del proyecto - Incorpora objetivos de calidad

- Integra el desarrollo con el mantenimiento, etc. - Adems es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodologa, ya que este ciclo de vida no es rgido ni esttico. Desventajas: - Genera mucho tiempo en el desarrollo del sistema. - Modelo costoso. - Requiere experiencia en la identificacin de riesgos. CONCLUCION: El paradigma del modelo en espiral para la ingeniera de software es actualmente el enfoque ms realista para el desarrollo de software y de sistemas a gran escala. Utiliza un enfoque evolutivo para la ingeniera de software, permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel evolutivo. Utiliza la creacin de prototipos como un mecanismo de reduccin de riesgo, pero, lo que es ms importante permite a quien lo desarrolla aplicar el enfoque de creacin de prototipos en cualquier etapa de la evolucin de prototipos.

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 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 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.

El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo software iterativo e incremental. El refinamiento ms conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP. El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos especficos. De la misma forma, el Proceso Unificado de Rational, tambin es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto. El nombre Proceso Unificado se usa para describir el proceso genrico que incluye aquellos elementos que son comunes a la mayora de los refinamientos existentes. Tambin permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). El primer libro sobre el tema se denomin, en su versin espaola, El Proceso Unificado de Desarrollo de Software (ISBN 8478290362) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh, conocidos tambin por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado. Desde entonces los autores que publican libros sobre el tema y que no estn afiliados a Rational utilizan el trmino Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre de Proceso Unificado de Rational. Caractersticas: - Iterativo e Incremental El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboracin, Construccin y Transicin. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio slo consta de varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que aade o mejora las funcionalidades del sistema en desarrollo. Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clsico o en cascada: Anlisis de requisitos, Diseo, Implementacin y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas vara a lo largo del proyecto. - Dirigido por los casos de uso En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteracin tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a travs de las distintas disciplinas: diseo, implementacin, prueba, etc. el proceso dirigido por casos de uso es el

rup. Nota: en UP se est Dirigido por requisitos y riesgos de acuerdo con el Libro UML 2 de ARLOW , Jim que menciona el tema. - Centrado en la arquitectura El Proceso Unificado asume que no existe un modelo nico que cubra todos los aspectos del sistema. Por dicho motivo existen mltiples modelos y vistas que definen la arquitectura de software de un sistema. La analoga con la construccin es clara, cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanera, etc. - Enfocado en los riesgos El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos crticos en una etapa temprana del ciclo de vida. Los resultados de cada iteracin, en especial los de la fase de Elaboracin, deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero.

Proceso Software Personal El Proceso Personal de Software es una versin pequea de CMM donde se preocupa solo por un conjunto de las KPAs. Fue propuesto por Watts Humphrey en 1995 y estaba dirigido a estudiantes. A partir de 1997 con el lanzamiento del libro An introduction to the Personal Software Process se dirige ahora a ingenieros principiantes. El PSP se caracteriza porque es de uso personal y se aplica a programas pequeos de menos de 10.000 lneas de cdigo. Se centra en la administracin del tiempo y en la administracin de la calidad a travs de la eliminacin temprana de defectos. En el PSP se excluyen los siguientes temas: Trabajo en equipo, Administracin de configuraciones y Administracin de requerimientos. El PSP se orienta el conjunto de reas clave del proceso que debe manejar un desarrollador cuando trabaja de forma individual. Los siguientes son los niveles y las KPAs que se manejan en cada uno: Nivel 2 - Inicial: - Seguimiento y control de proyectos - Planeacin de los proyectos Nivel 3 - Repetible: - Revisin entre colegas. - Ingeniera del producto de software. - Manejo integrado del software. - Definicin del proceso de software. - Foco del proceso de software. Nivel 4 - Definido: - Control de calidad. - Administracin cuantitativa del proyecto. Nivel 5 - Controlado: - Administracin de los cambios del proceso. - Administracin del cambio tecnolgico.

- Prevencin de defectos. - El PSP tiene varias fases: PSP0: Proceso Base. PSP0.1: Complementos al proceso base. PSP1 y PSP1.1: Planeacin personal. PSP2 y PSP2.1: Control de calidad personal. PSP3: Programas ms grandes. ITCG 4.5 Proceso Software personal El Proceso Personal Software, conocido por sus siglas como PSP, es una metodologa de reciente creacin, proveniente del Instituto de Ingeniera del Software (SEI). PSP es una alternativa dirigida a los ingenieros de sistemas, que les permite mejorar la forma en la que construyen software. Considerando aspectos como la planeacin, calidad, estimacin de costos y productividad, PSP es una metodologa que vale la pena revisar cuando el ingeniero de software est interesado en aumentar la calidad de los productos de software que desarrolla dentro de un contexto de trabajo individual. Atendiendo a la premisa de que existe una fuerte relacin entre las habilidades de los ingenieros de software y la calidad de los productos que desarrollan, las actividades establecidas en PSP estn orientadas al conocimiento, administracin y mejora de sus habilidades al construir programas.
En PSP todas las tareas y actividades que el ingeniero de software debe realizar durante el proceso de desarrollo de un producto de software, estn puntualmente definidas en un conjunto de documentos conocidos como scripts. Los scripts son el punto medular de PSP, por lo que se hace mucho nfasis en que deben ser seguidos en forma disciplinada, ya que de ello depender el xito de la mejora que se busca. Gran parte de las tareas y actividades definidas en los scripts generar en su realizacin un conjunto de datos, fundamentalmente de carcter estadstico. La aplicacin de PSP en varios procesos de desarrollo, y el anlisis de la informacin estadstica generada en cada uno de stos, permitirn al ingeniero de software identificar, tanto sus fortalezas como sus debilidades, y crecer a travs de un proceso de autoaprendizaje y automejora.

Los scripts se organizan en cuatro niveles, identificados del 0 al 3, atendindose en cada nivel un conjunto de aspectos a mejorar del proceso de desarrollo de software. Al primer nivel se le conoce como 0 o de medicin personal, al segundo como nivel 1 o de planeacin personal, al tercero, como nivel 2 o de calidad personal, y al cuarto, como nivel 3 o cclico

personal. Cada uno de estos niveles, con excepcin del 3, tiene una versin que los extiende, introduciendo tareas y actividades para un mejor manejo de los aspectos de inters en nivel, o bien para incluir nuevos aspectos.