PROCESO DE SOFTWAREUnproceso de softwarees un conjunto de actividades que conducen a la creacin de un producto de software. Un proceso de software define qu, cuando y como alcanzar un objetivo, marca las pautas para solucionar la problemtica de desarrollo de software.Segn Antonio Garrido las actividades que involucran un proceso de software son: Anlisis: en esta etapa se considera los requisitos del sistema, el "qu". Diseo: se define los componentes, la arquitectura del sistema, el "cmo". Implementacin: en esta fase se plasma el diseo en cdigo. Prueba: aqu se refina la solucin. Evolucin y mantenimiento: una vez que ya se es usado el producto se llega a considerar la eliminacin de fallas. Proceso de softwareLa meta de la ingeniera de software es construir productos de software, o mejorar los existentes; en ingeniera de procesos, la meta es desarrollar o mejorar procesos. Un proceso de desarrollo de software es un conjunto de personas, estructuras de organizacin, reglas, polticas, actividades y sus procedimientos, componentes de software, metodologas, y herramientas utilizadas o creadas especficamente para definir, desarrollar, ofrecer un servicio, innovar y extender un producto de software. Un proceso de software efectivo habilita a la organizacin a incrementar su productividad al desarrollar software: Permite estandarizar esfuerzos, promover reuso, repeticin y consistencia entre proyectos. Provee la oportunidad de introducir mejores prcticas de la industria. Permite entender que las herramientas deben ser utilizadas para soportar un proceso. Establece la base para una mayor consistencia y mejoras futuras. Un proceso de software mejora los esfuerzos de mantenimiento y soporte: Define cmo manejar los cambios y liberaciones a sistemas de software existentes. Define cmo lograr la transicin del software a la operacin, y cmo ejecutar los esfuerzos de operacin y soporte. Necesitamos un proceso de software cuya funcionalidad est probada en la prctica, y personalizado para que cumpla con nuestras necesidades especficas.

Una estructura de proceso general para la ingeniera consta de cinco actividades:ComunicacinAntes de que se empiece cualquier trabajo tcnico, tiene importancia crtica comunicarse y colaborar con el cliente (y con otros participantes). Se busca entender los objetivos de los participantes respecto del proyecto, y reunir los requerimientos que ayuden a definir las caractersticas y funciones del software.PlaneacinCualquier viaje complicado se simplifica si existe un mapa. Un proyecto de software es un viaje complicado, y la actividad de planeacin crea un "mapa" que gua al equipo mientras viaja. El mapa (llamado plan del proyecto de software) define el trabajo de ingeniera de software al describir las tareas tcnicas por realizar, los riesgos probables, los recursos que se requieren, los productos del trabajo que se obtendrn y una propagacin de las actividades.ModeladoSi eres diseador de paisaje, constructor de puentes, ingeniero aeronutico, carpintero o arquitecto, a diario trabajas con modelos. Se crea un "bosquejo" del objeto por hacer a fin de entender el panorama general (cmo se ver arquitectnicamente, cmo ajustan entre s las partes constituyentes y muchas caractersticas ms). Si se requiere, refina el bosquejo con ms y ms detalles en un esfuerzo por comprender mejor el problema y cmo resolverlo. Un ingeniero de software hace lo mismo al crear modelos a fin de enteder mejor los requerimientos del software y el diseo que los satisfar.ConstruccinEsta actividad mezcla la generacin de cdigo (ya sea manual o automatizada) y las pruebas que se requieren para descubrir errores en ste.DespliegueEl software (como entidad completa o cmo un incremento parcialmente terminado) se entrega al consumidor que lo evala y que le da retroalimentacin, misma que se basa en dicha evaluacin.Estas cinco actividades estructurales genricas se usan durante el desarrollo de programas pequeos y sencillos, en la creacin de aplicaciones web grandes y en la ingeniera de sistemas enormes y complejos basados en computadoras. Los detalles del proceso de software sern distintos en cada caso, pero las actividades estructurales son las mismas.Para muchos proyectos de software, las actividades estructurales se aplican en forma iterativa a medida que avanza el proyecto. Es decir, la comunicacin, la planeacin, el modelado, la construccin y el despliegue se ejecutan a travs de cierto nmero de repeticiones del proyecto. Cada iteracin produce un incremento del software que da a los participantes un subconjunto de caractersticas y funcionalidades generales del software. Conforme se produce cada incremento, el software se hace ms y ms completo.Las actividades estructurales del proceso de ingeniera de software son complementadas por cierto nmero de actividades sombrila. En general, las actividades sombrilla se aplican a lo largo de un proyecto de software y ayudan al equipo que lo lleva a cabo a administrar y controlar el avance, la calidad, el cambi y el riesgo. Es comn que las actividades sombrilla sean las siguientes:Seguimiento y control del proyecto de softwarePermite que el equipo de software evale el progreso comparndolo con el plan del proyecto y tom cualquier accin necesaria para apegarse a la programacin de actividades.Administracin de riesgoEvala los riesgos que puedan afectar el resultado del proyecto o la calidad del producto.Aseguramiento de la calidad del softwareDefine y ejecuta las actividades requeridas para garantizar la calidad del software.Revisiones tcnicasEvala los productos del trabajo de la ingeniera de software a fin de descubrir y eliminar errores antes de que se propaguen a la siguiente actividad.MedicinDefine y rene mediciones del proceso, proyecto y producto para ayudar al equipo a entregar el software que satisfaga las necesidades de los participantes; puede usarse junto con todas las dems actividades estructurales y sombrilla.Administracin de la configuracin del softwareAdministra los efectos del cambi a lo largo del proceso de software.Administracin de la reutilizacinDefine criterios para volver a usar el producto del trabajo (incluso los componentes del software) y establece mecanismos para obtener componentes reutilizables.Preparacin y produccin del producto del trabajoAgrupa las actividades requeridas para crear productos del trabajo, tales cmo modelos, documentos, registros, formatos y listas.Como mencione anteriormente el proceso de ingeniera de software no es una prescripcin rgida que debe seguir en forma dogmtica el equipo que lo crea. Al contrario, debe ser gil y adaptable (al problema, al proyecto, al equipo y a la cultura organizacional). Por tanto, un proceso adaptado para un proyecto puede ser significativamente distinto de otro adoptado para otro proyecto. Entre las diferencias se encuentran las siguientes: Flujo general de las actividades, acciones y tareas, as cmo de las interdependencias entre ellas. Grado en el que las acciones y tareas estn definidas dentro de cada actividad estructural. Grado en el que se identifican y requieren los productos del trabajo. Forma en la que se aplican las actividades de aseguramiento de la calidad. Manera en la que se realizan las atividades de seguimiento y control del proyecto. Grado general de detalle y rigor con el que se describe el proceso. Grado con el que el cliente y otros participantes se involucran con el proyecto. Nivel de autonoma que se da al equipo de software. Grado con el que son prescritos la organizacin y los roles del equipo.Los modelos de proceso prescriptivo enfatizan la definicin, la identificacin y la aplicacin detalladas de las actividades y tareas de proceso. Su objetivo es mejorar la calidad del sistema, desarrollar proyectos ms manejables, hacer ms predecibles las fechas de entrega y los costos, y guiar a los equipos de ingenieros de software cundo realizan el trabajo que se requiere para construir un sistema. Desafortunadamente, ha habido casos en los que stos objetivos no se han logrado. Si los modelos prescriptivos se aplican en forma dogmtica y sin adaptacin, pueden incrementar el nivel de burocracia asociada con el desarrollo de sistemas basados en computadora y crear inadvertidamente dificultades para todos los participantes.Los modelos de proceso gil ponen el nfasis en la "agilidad" del proyecto y siguen un conjunto de principios que conducen a un enfoque ms informal (pero no menos efectivo, dicen sus defensores) del proceso de software. Por lo general, se dice que stos modelos del proceso son "giles" porque acentan la maniobrabilidad y la adaptabilidad. Son apropiados para muchos tipos de proyectos y sn tiles en particular cundo se hace ingeniera sobre aplicaciones web.Proceso

Metodologa:Todo desarrollo de software es riesgoso y difcil de controlar, pero si no llevamos una metodologa de por medio, se obtieneclientesinsatisfechos con el resultado y desarrolladores aun mas.Sin embargo muchas veces no se toma en cuenta el utilizar una metodologa adecuada, sobre todo cuando se trata deproyectospequeos de dos o tres meses.Con relacin a los proyectos que se desarrollan con mayor envergadura, hay si se toma el sentido de basarse en una metodologa de desarrollo y se empieza a buscar cual seria la mas apropiada para dicho caso. A fin de cuenta no encontramos muchas veces la meas adecuada y se termina por hacer un diseo propio de metodologa, por supuesto no esta mal siempre y cuando sirva para alcanzar elobjetivo.Muchas veces se realiza el diseo del software de manera rgida, tal cual como el cliente lo solicito, de esa manera cuando el cliente en la "etapa de prueba" solicita uncambiose hace muy difcil de realizarlo, pues si se hace altera las cosas que no se haban previsto, y este es uno de los factores que atrasan elproyectoy crea incomodidad al desarrollador y en muchas oportunidades no llegan a cumplir con el cambio solicitado, esto conlleva malestar en el cliente puesto que no se sido tomado en cuenta su pedido; para evitar estos incidentes se debe llegar a un acuerdo formal con el cliente al inicio del proyecto de manera que no perjudique el desarrollo del mismo.Muchas veces los usuarios finales se dan cuenta que dejaron de mencionar algunas cosas y lo manifiestan en la etapa inicial del proyecto cuando se lemuestrael prototipo del mismo.ALGUNAS Metodologas conocidas: La metodologa RUP es la ms adaptable para proyectos de largo plazo. La metodologa XP en cambio, se recomienda para proyectos de corto plazo. La metodologa MSF se adapta a proyectos de cualquier dimensin y de cualquiertecnologa. Se puede decir adems que lo ms importante antes de elegir la metodologa que se debe usar para implementar el software, es determinar el alcance que tendr y luego de all ver cual es la que mas se acomoda a la aplicacin. Ejemplos: El ejemplo del software lo hacen numerosas empresas, cada vez mas gobiernos (registrogratis). Los expertos lo recomiendan, lo hacen particulares a millones. Hasta (a regaadientes)Microsoft. La idea absurda de dejar abierta las tripas del software y permitir que la gente las mire, e incluso que las modifique, copie y use en condiciones diferentes, en laindustriade lainformticaes muy comn. De hecho se extiende a los ms pequeos rincones del mundo desde una orden mgica hermtica de tradicin masnica y rosacruciana a telefnica I+D. Si hasta las empresas enfilosofams expuesta o menos rpidas en novacin y lassociedadessecretas son capaces de ver las ventajas del "OPEN SOURCE" (abierto o libre). No ha sido sencillo la idea conocida como dicho software (abierto o libre) a tenido una vida larga pero difcil, dirigida por polmicas aparentemente absurda pero que contienen un profundodebateideolgico y practico; a veces dividido en partes enfrentadas con mucha pasin; siempre descalificada, lo cierto es que lacomunidaddel software abierto hoy es una fuerte y sana realidad.

Importancia: Actualmente la transicin que estamos viviendo hacia unasociedaddelconocimientoa cambiado profundamente las relaciones entre las personas, empresas y gobiernos: las empresas usan laredpara comunicarse con los clientes, utilizan tambinherramientasdegestindel conocimiento para hacer masa eficientes, los gobiernos mejoran su presencia enInternety losserviciosa los ciudadanos a travs de la red, los usuarios usan las herramientas para sus relaciones personales, etc. Se va de forma imparable hacia una sociedad altamente interconectada donde el eje fundamental es lainformacin. El software es el intermediario cada vez mas grande entre la informacin y lainteligenciahumana. De la misma manera que preocupa parapoderacceder a la informacin, si existe la censura, es tema de preocupacin de quien controla este intermediario y las garantas de su transparencia y confiabilidad. En principio, el software es un programa informtico o conjunto de ellos que tiene un fin determinado, es el de procesar los textos que usamos, el controlador de grabacin de nuestros espacios favoritos o las aplicaciones que permiten operar untelfonomvil. Esta compuesto por un conjunto de instrucciones que el usuario realiza para ejecutar unafuncinespecifica. Normalmente los programadores escriben en unlenguajeen el que todos pueden entender y que despus es traducido al lenguaje binario el nico que las maquinas entienden. El conjunto de rdenes enel lenguajeque todos trabajan se llamancdigofuente. Sino se accede al cdigo solo se puede usar el programa, no se puede ver como esta hecho o introducir comentarios. Un ejemplo muy utilizado es el de la receta de cocina, en el que el cdigo fuente son las instrucciones que permite confeccionar un plato. Sin la receta solo se pude degustar el plato, pero no se sabe si se le aade algo vaya en contra de algunos de esos ingredientes ya que se desconocen su composicin y proporcin. En este sentido, elcodigofuente juega un papel fundamental en la manera como se debe entender el software. Se podran poner varios ejemplos para entender dicha importancia. A finales de los 90 se pudo ver en todo el mundo la preocupacin por parte de empresa y gobiernos por las consecuencias que podan tener el llamado efecto 2000. El famoso error informtico era debido al hecho de que muchosprogramasalmacenaban la parte de la fecha correspondiente al ao utilizando nicamente dos dgitos, de tal manera, que despus del ao 99 (el 1999) podamos pasar al ao 00 ( ao 2000 o ao 1900?) causando todo tipo de errores en el calculo de periodo de tiempo. Los ordenadores de las empresas elctricas, centrales nucleares, sistema de control de aviacin,bancosy en general, todo el software de uso cotidiano, tuvieron que ser revisados. Finalmente algunas aplicaciones fueron corregidas, otras ya funcionaban correctamente y no hubo que lamentar ninguna catstrofe, pero hubo miles de predicciones apocalpticas sobre las consecuencias que se podra llegar a obtener este error, as podra ver sido si no se hubiera reparado a tiempo. Es por eso, el software tiene un papel muy importante en la sociedad sobre manera garantizarmtodostrasparentes en sus diferentes fases deproducciny explotacin.

Caractersticas de los Proce-sos SoftwareLa definicin de Proceso Software (PS) com-plementa el concepto de ciclo de vida en elsentido de que ste ltimo define el esqueletoy la filosofapara llevar acabo un PS,perono es suficiente para guiar y controlar unproyecto de desarrollo y/o mantenimiento.Un PS es un conjunto coherente de polti-cas, estructuras organizacionales, tecnolo-gas, procedimientos y artefactos que sonnecesarios para concebir, desarrollar, insta-lar y mantener un producto software [3].La naturaleza especial de los PS est deter-minada por las siguientes caractersticas:a)Son complejos.b)No sonprocesosde produccin tpicos,yaqueestndirigidosporexcepciones,sevenmuydeterminadosporcircunstanciasimpredecibles y cada uno tiene peculiarida-des que lo distinguen de los dems.c)Tampoco sonprocesosde ingenierapura, ya que se desconocen las abstraccio-nes adecuadas (no existe una ciencia experi-mental en la que apoyarse), dependen dema-siado de demasiada gente, el diseo y laproduccin no estn claramente diferencia-dos, y los presupuestos, calendarios y cali-dad no pueden ser planificados de formasuficientemente fiable.d)No son (completamente) procesoscreativos, ya que algunas partes pueden serdescritas en detalle y algunos procedimien-tos son impuestos previamente.e)Estnbasadosen descubrimientos quedependen de lacomunicacin, coordinaciny cooperacin dentro demarcos detrabajopredefinidos: los entregables generan nue-vosrequerimientos;loscostesdelcambiodel software no suelen reconocerse; y el xitodepende de la implicacin del usuario y de lacoordinacin de muchos roles (ventas, desa-rrollo tcnico, cliente, etc.).La necesidad de participacin humana deforma creativa y la ausencia de accionesrepetitivas hacen que ni el desarrollo ni elmantenimiento del software sean procesosde fabricacin, pero existen algunas simili-tudes entre ambos tipos de procesos que sontiles para comprender los procesos soft-wareconunaperspectivamsamplia.Aligual que los procesos de fabricacin, losprocesos software constan de dos sub-pro-cesos interrelacionados: el proceso de pro-duccin y el proceso de gestin

SEGN GERARDO CANFORA

MODELO DE PROTOTIPOS: El Modelo de prototipos, enIngeniera de software, pertenece a los modelos de desarrollo evolutivo. El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar muchos recursos.El diseo rpido se centra en una representacin de aquellos aspectos del software que sern visibles para el cliente o el usuario final. Este diseo conduce a la construccin de un prototipo, el cual es evaluado por el cliente para una retroalimentacin; gracias a sta se refinan los requisitos del software que se desarrollar. La interaccin ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.VENTAJAS Este modelo es til cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. Tambin ofrece un mejor enfoque cuando el responsable del desarrollo del software est inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debera tomar la interaccin humano-mquina.

INCONVENIENTES El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intencin de crear un prototipo de forma rpida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su funcin. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertira en unprototipo evolutivo, pero partiendo de un estado poco recomendado. En aras de desarrollar rpidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementacin poco convenientes (por ejemplo, elegir un lenguaje de programacin incorrecto porque proporcione un desarrollo ms rpido). Con el paso del tiempo, el desarrollador puede olvidarse de la razn que le llev a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final...

MODELO DE PROTOTIPOEste modelo tambin denominadomodelo de desarrollo evolutivo.Para comprender este modelo, comenzaremoscon la definicin de los objetivos globales para el software, despus identificaremos los requerimientos que conocemos y los sitios del diseo en donde es necesaria ms definicin. Entonces planteamos con rapidez una iteracin de construccin de prototipos y se presenta el modelado (en forma de un diseo rpido).Los modelos evolutivos son iterativos; los caracteriza la forma en que permiten que los ingenieros de software desarrollen versiones cada vez ms completas del software.El diseo rpido se basa en una representacin de aquellos aspectos del software que sern visibles para el cliente o el usuario final (por ejemplo, la configuracin de la interfaz con el usuario y el formato de los despliegues de salida). El diseo rpido conduce a la construccin de un prototipo, el cual es evaluado por el cliente o el usuario para una retroalimentacin; gracias a sta se refinan los requisitos del software que se desarrollar. La iteracin ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.CONSTRUCCION DE PROTOTIPOSA menudo un cliente define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. El responsable del desarrollo del software est inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debera tomar la interaccin humana mquina, entonces en este caso cuando utilizamos la construccin de prototipos.El paradigma de construccin de prototipos se inicia con la comunicacin. El ingeniero de software y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las reas del esquema en donde es necesaria ms definicin. Entonces se plantea con rapidez una iteracin de construccin de prototipos y se presenta el modelado (en la forma de un diseo rpido). El diseo rpido se centra en una representacin de aquellos aspectos del software que sern visibles para el usuario final. El diseo rpido conduce a la construccin de un prototipo. Despus, el prototipo lo evala el usuario y con la retroalimentacin se refinan los requisitos del software que se desarrollar. La iteracin ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo se desarrollador entienda mejor lo que se debe hacer.VENTAJAS:No modifica el flujo del ciclo de vida.Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios.Reduce costos y aumenta la probabilidad de xito.Exige disponer de las herramientas adecuadas.No presenta calidad ni robustez.Una vez identificados todos los requisitos mediante el prototipo, se construye el producto de ingeniera.DESVENTAJASA los usuarios les gusta el sistema real y a los desarrolladores les gusta construir algo de inmediato. Sin embargo, la construccin de prototipos se torna problemtica por las siguientes razones:El cliente ve funcionando lo que para el es la primera versin del prototipo que ha sido construido con chicle y cable para embalaje, y puede decepcionarse al indicarle que el sistema aun no ha sido construido.El desarrollador puede caer en la tentacin de aumentar el prototipo para construir el sistema final sin tener en cuenta los obligaciones de calidad y de mantenimiento que tiene con el cliente.Caractersticas:Consiste en construir un prototipo que sirva para identificar los requisitos del software antes de desarrollar la aplicacin definitiva. Los prototipos se construyen y supervisan con la ayuda de los usuarios, siendo, por tanto, una tcnica orientada al USUARIO.Adems, permite abordar riesgos tecnolgicos del proyecto antes de su desarrollo,Por otro lado, facilita la creacin de un modelo del software que se tiene que construir.Puede tener una de las formas siguientes: o En papel o un modelo basado en computador que describa la interaccin hombre/mquina de forma que d al usuario una idea bsica de cmo se realizar la interaccin. o Un prototipo que implemente algunas de las funcionalidades del sistema. o Un prototipo que ejecute parte o toda la funcionalidad deseada pero con caractersticas por mejorar. Tipos de prototipos: Evolutivos: Se van aadiendo funcionalidades hasta que el prototipo se convierte en el sistema final. Desechables: Se utiliza para determinar las necesidades del usuario y todo o parte de l esre diseadocon el objetivo de obtener un sistema ms eficiente. Totales: Se construye para el sistema completo. Parciales: Se construye slo para modelar una parte del sistema.

MODELO CASCADAEnIngeniera de softwareeldesarrollo en cascada, tambin llamadomodelo en cascada(denominado as por la posicin de las fases en el desarrollo de esta, que parecen caer en cascadapor gravedadhacia las siguientes fases), es el enfoque metodolgico que ordena rigurosamente las etapas delproceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalizacin de la etapa anterior.1Al final de cada etapa, el modelo est diseado para llevar a cabo una revisin final, que se encarga de determinar si el proyecto est listo para avanzar a la siguiente fase. Este modelo fue el primero en originarse y es la base de todos los dems modelos de ciclo de vida.La versin original fue propuesta por Winston W. Royce en 1970 y posteriormente revisada porBarry Boehmen 1980 e Ian Sommerville en 1985.2Un ejemplo de una metodologa de desarrollo en cascada es:1. Anlisis de requisitos.2. Diseo del Sistema.3. Diseo del Programa.4. Codificacin.5. Pruebas.6. Verificacin.7. Mantenimiento.De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costos del desarrollo. La palabracascadasugiere, mediante la metfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases ms avanzadas de un proyecto.Si bien ha sido ampliamente criticado desde el mbito acadmico y la industria[citarequerida], sigue siendo el paradigma ms seguido al da de hoyAnlisis de requisitos[editar]En esta fase se analizan las necesidades de los usuarios finales del software para determinar qu objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificacin de requisitos), que contiene la especificacin completa de lo que debe hacer el sistema sin entrar en detalles internos.Es importante sealar que en esta etapa se debeconsensuartodo lo que se requiere del sistema y ser aquello lo que seguir en las siguientes etapas, no pudindose requerir nuevos resultados a mitad del proceso de elaboracin del software de una manera.Diseo del Sistema[editar]Descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseo del Software), que contiene la descripcin de la estructura relacional global del sistema y la especificacin de lo que debe hacer cada una de sus partes, as como la manera en que se combinan unas con otras.Es conveniente distinguir entre diseo de alto nivel o arquitectnico y diseo detallado. El primero de ellos tiene como objetivo definir la estructura de la solucin (una vez que la fase de anlisis ha descrito el problema) identificando grandes mdulos (conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello se define la arquitectura de la solucin elegida. El segundo define los algoritmos empleados y la organizacin del cdigo para comenzar la implementacin...Diseo del Programa[editar]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 qu herramientas usar en la etapa de CodificacinCodificacin[editar]Es la fase en donde se implementa elcdigo fuente, haciendo uso de prototipos as como de pruebas y ensayos para corregirerrores.Dependiendo del lenguaje de programacin y su versin se crean las bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la programacin sea un proceso mucho ms rpido.Pruebas[editar]Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos, antes de ser entregado al usuario final.Verificacin[editar]Es la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya realizaron exhaustivas pruebas para comprobar que el sistema no falle.En la creacin de desarrollo de cascada se implementa los cdigos de investigacin y pruebas del mismo.Mantenimiento[editar]Una de las etapas mas criticas, ya que se destina un 75% de los recursos, es el mantenimiento del Software ya que al utilizarlo como usuario final puede ser que no cumpla con todas nuestras expectativas.Ventajas[editar]Realiza un buen funcionamiento en equipos dbiles y productos maduros, por lo que se requiere de menos capital y herramientas para hacerlo funcionar de manera ptima.Es un modelo fcil de implementar y entender.Est orientado a documentos.Es un modelo conocido y utilizado con frecuencia.Promueve una metodologa de trabajo efectiva: Definir antes que disear, disear antes que codificar.4Desventajas[editar]En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementacin del modelo, lo cual hace que lo lleve al fracaso.El proceso de creacin del software tarda mucho tiempo ya que debe pasar por el proceso de prueba y hasta que el software no est completo no se opera. Esto es la base para que funcione bien.Cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costos del desarrollo.Una etapa determinada del proyecto no se puede llevar a cabo a menos de que se haya culminado la etapa anterior.modelo de cascadaEnIngeniera de softwareeldesarrollo en cascada, tambin llamadomodelo en cascada, es el enfoque metodolgico que ordena rigurosamente las etapas delproceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalizacin de la etapa anterior.1Un ejemplo de una metodologa de desarrollo en cascada es:1. Anlisis de requisitos.2. Diseo del Sistema.3. Diseo del Programa.4. Codificacin.5. Pruebas.6. Implantacin.7. Mantenimiento.De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costos del desarrollo. La palabracascadasugiere, mediante la metfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases ms avanzadas de un proyecto.Si bien ha sido ampliamente criticado desde el mbito acadmico y la industria, sigue siendo el paradigma ms seguido al da de hoy.

Anlisis de requisitosEn esta fase se analizan las necesidades de los usuarios finales del software para determinar qu objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificacin de requisitos), que contiene la especificacin completa de lo que debe hacer el sistema sin entrar en detalles internos.Es importante sealar que en esta etapa se debeconsensuartodo lo que se requiere del sistema y ser aquello lo que seguir en las siguientes etapas, no pudindose requerir nuevos resultados a mitad del proceso de elaboracin del software.Diseo del SistemaDescompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseo del Software), que contiene la descripcin de la estructura relacional global del sistema y la especificacin de lo que debe hacer cada una de sus partes, as como la manera en que se combinan unas con otras.Es conveniente distinguir entre diseo de alto nivel o arquitectnico y diseo detallado. El primero de ellos tiene como objetivo definir la estructura de la solucin (una vez que la fase de anlisis ha descrito el problema) identificando grandes mdulos (conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello se define la arquitectura de la solucin elegida. El segundo define los algoritmos empleados y la organizacin del cdigo para comenzar la implementacin.Diseo del ProgramaEs 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.CodificacinEs la fase en donde se implementa elcdigo fuente, haciendo uso de prototipos as como de pruebas y ensayos para corregirerrores.Dependiendo del lenguaje de programacin y su versin se crean las bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la programacin sea un proceso mucho ms rpido.PruebasLos elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos, antes de ser entregado al usuario final.Verificacin Es la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya realizaron exhaustivas pruebas para comprobar que el sistema no falle.En la creacion de desarrollo de cascada se implementa los codigos de investigacion y puebas del mismoMantenimientoUna de las etapas mas criticas, ya que se destina un 75% de los recursos, es el mantenimiento del Software ya que al utilizarlo como usuario final puede ser que no cumpla con todas nuestras expectativas.

*CaracteristicasFases:-Ingeniera y anlisis del sistema-Anlisis de los Requisitos-Diseo-Codificacin-Prueba-MantenimientoIng. del Software- Modelo Incremental & Modelo Cascada - Trejo Anthony, Rodriguez Robert 10. *Ventajas-Se tiene todo bien organizado y no semezclan las fases.-Es perfecto para proyectos que sonrgidos, y adems donde se especifiquenmuy bien los requerimientos y se conozcamuy bien la herramienta a utilizar.- La planificacin es sencilla.- La calidad del producto resultante esalta.- Permite trabajar con personal pococualificado.Ing. del Software- Modelo Incremental & Modelo Cascada - Trejo Anthony, Rodriguez Robert 11. *Desventajas-Iteraciones costosas.-Los problemas que se presentan soncorregidos posteriormente.-Puede que el software no cumpla con losrequisitos.-Es difcil incorporar nuevas cosas si sequiere actualizar.-Es normal detenerse en su desarrollo yseguir con otras fases.Ing. del Software- Modelo Incremental & Modelo Cascada - Trejo Anthony, Rodriguez Robert

Modelo Cascada CARACTERISTICAS Es el ms utilizado. Es una visin del proceso de desarrollo de software como una sucesin de etapas que producen productos intermedios. Para que el proyecto tenga xito deben desarrollarse todas las fases. Las fases continan hasta que los objetivos se han cumplido. Si se cambia el orden de las fases, el producto final ser de inferior calidad, 9. Modelo Cascada 10. DESVENTAJAS Se tarda mucho tiempo en pasar por todo el ciclo El mantenimiento se realiza en el cdigo fuente Las revisiones de proyectos de gran complejidad son muy difciles.MODELO CASCADA MODIFICADA.En respuesta a los problemas que se observan con el modelo de cascada pura, se han introducido muchos modelos de cascada modificados. Estos modelos pueden abordar algunas o todas las crticas al modelo de cascada pura. Muchos modelos diferentes estn cubiertos por Steve McConnell en la "Planificacin del ciclo de vida" captulo de su libro Desarrollo Rpido: Taming Horarios Software salvajes.Si bien todos los modelos de desarrollo de software tienen cierta similitud con el modelo de cascada, ya que todos los modelos de desarrollo de software incorporan al menos algunas fases similares a los utilizados en el modelo de cascada, esta seccin se ocupa de las personas ms cercanas al modelo de cascada. Para los modelos que se aplican otras diferencias en el modelo de cascada, o radicalmente diferentes modelos de buscar informacin general sobre el proceso de desarrollo de software.

MODELO CASCADA MODIFICADA Se invent para permitir retroalimentacin y encimamiento entre fases. Es un modelo iterativo y no lineal. Para facilitar la terminacin de metas y tareas, es normal congelar partes del desarrollo despus de cierto punto en la iteracin. Se agregaron los pasos de verificacin (checar que el sistema es correcto, construir el sistema correctamente) y validacin (checar que el sistema cumple con los deseos del cliente, construir el sistema correcto).

Modelo de cascada modificadoEl modelo de la cascada (y el de la cascada modificada) son inflexibles en el particionamiento del proyecto en sus distintas fases. Sin embargo, generalmente reflejan la prctica de la ingeniera.Modelo RAD (Diseo Rpido de Aplicaciones)Es un modelo de proceso de desarrollo de software de cascada que enfatiza un ciclo de desarrollo extremadamente corto. Este modelo se puede usar si: Se comprenden bien los requisitos y se limita el mbito del proyecto. Es fcil dividir al sistema en mdulos. Se utiliza un enfoque de construccin basado en objetos reusables.Tiene algunas desventajas: Requiere recursos humanos suficientes como para crear el nmero correcto de equipos. Necesita que el cliente y el desarrollador se comprometan en las actividades necesarias para completar un sistema en un tiempo corto. DEFINICIN Proceso de desarrollo de software que permite construir sistemas utilizables en poco tiempo, normalmente de 60 a 90 das, frecuentemente con algunas concesiones. 3.CARACTERSTICAS Equipos Hbridos Herramientas Especializadas "Timeboxing Prototipos Iterativos y Evolucionarios. 4.EQUIPOS HBRIDOSEquipos compuestos por alrededor de seis personas, incluyendo desarrolladores y usuarios de tiempo completo del sistema as como aquellas personas involucradas con los requisitos.Los desarrolladores de RAD deben ser renacentistas": analistas, diseadores y programadores en uno. 5. HERRAMIENTAS ESPECIALIZADASDesarrollo "visual"Creacin de prototipos falsos (simulacin pura)Creacin de prototipos funcionalesMltiples lenguajesCalendario grupalHerramientas colaborativas y de trabajo en equipoComponentes reusablesInterfaces estndares (API) 6. "TIMEBOXING Las funciones secundarias son eliminadas como sea necesario para cumplir con el calendario. 7. PROTOTIPOS ITERATIVOS Y EVOLUCIONARIOS Reunin JAD (Joint Application Development): Se reunen los usuarios finales y los desarrolladores. Lluvia de ideas para obtener un borrador inicial de los requisitos. Iterar hasta acabar: Los desarrolladores construyen y depuran el prototipo basado en los requisitos actuales. Los diseadores revisan el prototipo. Los clientes prueban el prototipo, depuran los requisitos. Los clientes y desarrolladores se reunen para revisar juntos el producto, refinar los requisitos y generar solicitudes de cambios. Los cambios para los que no hay tiempo no se realizan. Los requisitos secundarios se eliminan si es necesario para cumplir el calendario.

Modelos evolutivosEsta familia de modelos se utilizan en las siguientes circunstancias: Si los requisitos cambian conforme el desarrollo avanza. Si las fechas de mercado hacen imposible tener un producto completo y hay que introducir una versin limitada. Si los requisitos centrales estn bien definidos pero todava hay que definir los detalles de las extensiones del producto.1. Modelo incremental Combina elementos del modelo de cascada (aplicados repetitivamente) con la filosofa interactiva de construccin de prototipos. El primer incremento es unproducto esencial(ncleo), se afrontan requisitos bsicos y muchas funciones extras (conocidas o no) quedan para los siguientes incrementos. El cliente usa el producto central y en base a la utilizacin y/o evaluacin se desarrolla un plan para el incremento siguiente. Este proceso se repite hasta que se elabora el producto completo. Es interactivo, al igual que el de construccin de prototipos y otros enfoques evolutivos. Pero a diferencia del modelo de construccin de prototipos, el modelo incremental entrega un producto operacional en cada incremento. Es til cuando la dotacin de personal no est disponible para una implementacin completa. El primer incremento se pueden implementar con pocas personas. Si el producto central es bien recibido, se puede aadir mas personal.2. Modelo de la espiral de Boehm Combina los elementos controlados y sustemticos del modelo de cascada con la filosofa interactiva de construccin de prototipos. Proporciona el potencial para el desarrollo rpido de versiones incrementales del software. El software se desarrolla en una serie de versiones incrementales. Durante las primera iteraciones, la versin incremental puede ser un modelo en papel o un prototipo. Durante las ltimas iteraciones, se producen versiones cada vez ms completas del sistema. El modelo se divide en un nmero de actividades estructurales llamadasregiones de tareasque pueden ser de tres a seis. Pressman define las siguientes regiones de tareas: Comunicacin con el cliente. Planeacin. Define recursos, tiempo y otras informaciones relacionadas con el proyecto. Anlisis de riesgos. Evala riesgos tcnicos y de administracin. Ingeniera. Construye una o ms representaciones de la aplicacin. Construccin y adaptacin. Construye, prueba, instala y proporciona soporte al usuario (p.e. documentacin). Evaluacin del cliente. Cada regin tiene tareas que se adaptan a las caractersticas del proyecto. El primer circuito de la espiral produce una especificacin de productos; los pasos siguientes en la espiral se podran usar para desarrollar un prototipo y progresivamente versiones ms sofisticadas del software. Cada paso por la regin de planificacin produce ajustes en el plan del proyecto. El costo y la planificacin se ajustan segn la reaccin ante la evaluacin del cliente. A diferencia del modelo de vida clsico que termina cuando se entrega el software, el modelo en espiral se puede adaptar y aplicarse a lo largo de toda la vida del software.Su principal desventaja es que es nuevo (1988) y no se ha utilizado tanto como otros modelos de ciclo de vida. Adems puede resultar difcil convencer a algunos clientes que el proceso es controlable.

Modelo de mtodos formales Permiten especificar, desarrollar y verificar un sistema aplicando una notacin rigurosa y matemtica. Eliminan muchos de los problemas que son difciles de superar con otros paradigmas. La ambiguedad, la incompletez y la inconsistencia se pueden descubrir y corregir, no mediante una revisin, sino mediante la aplicacin del anlisis matemtico. Su principal desventaja es que requiere que el desarrollador y el cliente tengan conocimientos formales para poderlos aplicar y comunicarse entre s.

Tcnicas de cuarta generacin (4GT) Permite especificar el software usando lenguajes especializados o notaciones grficas que describan el problema. Requiere usar alguna herramienta CASE (Computer-aided Software Engineering) con herramientas tales como: SQL (Structured Query Language), generador de reportes, base de datos, definidores de pantallas, generadores de cdigo, generador de grficas, hoja de clculo, etc. Idealmente el cliente describe los requisitos, que son traducidos inmediatamente a un prototipo operativo. En aplicaciones pequeas, se puede ir directamente a la implementacin usando un lenguaje de cuarta generacin (4GL). El aplicaciones grandes, el uso de 4GL sin diseo provocar los mismos problemas que los otros paradigmas (poca calidad, mantenimiento pobre y mala aceptacin del cliente). El uso de 4GL permite al desarrollador centrarse en la representacin de los resultados deseados. Para transformar una implementacin 4GT en un producto, el desarrollador debe dirigir una prueba completa, hacer una buena documentacin y ejecutar el resto de las actividades de integracin requeridas en los otros paradigmas. Adems, el software desarrollado con 4GT debe ser construido de modo que facilite el mantenimiento. Las tcnicas de cuarta generacin son un conjunto muy diverso de mtodos y herramientas que tienen por objeto el de facilitar el desarrollo del software, facilitan al que desarrolla el software la propiedad de especificar algunas caractersticas del mismo a alto nivel, mas tarde, la herramienta genera automticamente el cdigo fuente a partir de esta especificacin. Los tipos ms comunes de generadores de cdigo cubren uno o varios de los siguientes aspectos: 1.-Acceso a base de datos:utilizando lenguajes de consulta de alto nivel. Generadores de cdigos:a partir de una especificacin de los requisitos se genera automticamente toda la aplicacin 2.-Generacin de pantallas:permitiendo disear la pantalla dibujndola directamente, incluyendo adems el control del cursor y la gestin de los errores de los datos de entrada. 3.-Gestin de entornos grficos. 4.-Generacin de informes.:Como otros paradigmas, T4G comienza con el paso de recoleccin de requerimientos. En el mejor de los casos el cliente debera describir los requerimientos y stos traducirse directamente a un prototipo operacional pero en general esto no es as. El cliente puede no estar seguro de lo que necesita, puede ser ambiguo en la especificacin de hechos que son conocidos y puede ser incapaz o no desear especificar la informacin en la forma que una herramienta T4G puede construirla, adems las herramientas actuales T4G no son lo suficientemente sofisticadas para acomodar realmente lenguaje natural y no lo sern por algn tiempo. Para aplicaciones pequeas puede ser posible ir directamente desde el paso de establecimiento de requerimientos a la implementacin,sin embargo es necesaria una estrategia del diseo para el sistema. El uso de T4G sin diseo para grandes proyectos causar las mismas dificultades (poca calidad, pobre mantenimiento, mala aceptacin por el cliente) que se encuentran cuando se desarrolla software usando los mtodos convencionales. El ltimo paso de la figura anterior contiene la palabra producto para transformar una implementacin T4G en un producto, el que lo desarrollo debe dirigir una prueba completa, desarrollar una documentacin con sentido y ejecutar todas las otras actividades de transicin requeridas en los otros paradigmas de la ingeniera de software. Los defensores aducen reducciones dramticas en el tiempo de desarrollo en el software y una mejora significativa en la productividad de la gente que construye el software. Los detractores de este paradigma aducen que los lenguajes de programacin, que el cdigo fuente producido por tales herramientas es ineficiente y que el mantenimiento de grandes sistema de software desarrollado usando T4g est abierta a discusin. Hay algunos mritos en las razones de cada parte. Aunque es algo difcil separar los hechos de las suposiciones es posible resumir el estado actual de los mtodos T4G: Con muy pocas excepciones el dominio de aplicacin actual de las T4G est limitada a las aplicaciones de sistema de informacin comerciales, especficamente del anlisis de informacin comercial, especficamente del anlisis de informacin y de la obtencin de informes en las grandes bases de datos. Hasta la fecha T4G se han usado muy poco en productos de ingeniera y reas de aplicacin de sistemas. La recoleccin de datos preliminares que acompaan al uso de T4G parece indicar que el tiempo requerido para producir software se reduce mucho para aplicaciones pequeas de trabajo medio as como tambin la cantidad de anlisis y diseo. Sin embargo el uso de T4G para grandes trabajos de desarrollo de software exige el mismo o ms tiempo de anlisis, diseo y prueba perdindose as un tiempo sustancial que se ahorra mediante la eliminacin de la codificacin. En conclusin podemos definir que las tcnicas de cuarta generacin pueden reducir drsticamente el esfuerzo y tiempo de desarrollo en aplicaciones de pequeo y mediano nivel, sin embargo debido a su imperfecto estado actual el desarrollo de grandes aplicaciones con estas esta aun muy lejos de convertirse en una realidad.

Actividades del desarrollo de software[editar]

Actividades del proceso de desarrollo de software representados en eldesarrollo en cascada. Hay algunos modelos ms para representar este proceso.Planificacin[editar]La importante tarea a la hora de crear un producto de software es obtener losrequisitoso elanlisis de los requisitos. Los clientes suelen tener una idea ms bien abstracta del resultado final, pero no sobre las funciones que debera cumplir el software.Una vez que se hayan recopilado los requisitos del cliente, se debe realizar un anlisis del mbito del desarrollo. Este documento se conoce como especificacin funcional.Implementacin, pruebas y documentacin[editar]Laimplementacines parte del proceso en el que losingenieros de softwareprogramanel cdigo para el proyecto.Laspruebas de softwareson parte esencial del proceso de desarrollo del software. Esta parte del proceso tiene la funcin de detectar loserrores de softwarelo antes posible.Ladocumentacindel diseo interno del software con el objetivo de facilitar su mejora y su mantenimiento se realiza a lo largo del proyecto. Esto puede incluir la documentacin de unAPI, tanto interior como exterior.Despliegue y mantenimiento[editar]Eldesplieguecomienza cuando el cdigo ha sido suficientemente probado, ha sido aprobado para suliberaciny ha sido distribuido en el entorno de produccin.Entrenamiento y soporte para el softwarees de suma importancia y algo que muchos desarrolladores de software descuidan. Los usuarios, por naturaleza, se oponen al cambio porque conlleva una cierta inseguridad, es por ello que es fundamental instruir de forma adecuada a los futuros usuarios del software.Elmantenimientoo mejora del software de un software con problemas recientemente desplegado, puede requerir ms tiempo que el desarrollo inicial del software. Es posible que haya que incorporar cdigo que no se ajusta al diseo original con el objetivo de solucionar un problema o ampliar la funcionalidad para un cliente. Si los costes de mantenimiento son muy elevados puede que sea oportuno redisear el sistema para poder contener los costes de mantenimiento.RUPElProceso Racional Unificado(Rational Unified Processen ingls, habitualmente resumido como RUP) es un proceso de desarrollo de software desarrollado por la empresaRational Software, actualmente propiedad deIBM. Junto con el Lenguaje Unificado de ModeladoUML, constituye la metodologa estndar ms utilizada para el anlisis, diseo, implementacin y documentacin de sistemas orientados a objetos.El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas adaptables al contexto y necesidades de cada organizacin. Tambin se conoce por este nombre al software, tambin desarrollado por Rational, que incluye informacin entrelazada de diversosartefactosy descripciones de las diversas actividades. Est incluido en elRational Method Composer(RMC), que permite la personalizacin de acuerdo con las necesidades.Originalmente se dise un proceso genrico y de dominio pblico, elProceso Unificado, y una especificacin ms detallada, elRational Unified Process, que se vendiera como producto independiente...Principales caractersticas[editar] Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y cmo) Pretende implementar las mejores prcticas en Ingeniera de Software Desarrollo iterativo Administracin de requisitos Uso de arquitecturabasada en componentes Control de cambios Modelado visual del software Verificacin de la calidad del softwareEl RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo decasos de uso, el cdigo fuente, etc.) y roles (papel que desempea una persona en un determinado momento, una persona puede desempear distintos roles a lo largo del proceso).Fases[editar] Establece oportunidad y alcance Identifica las entidades externas o actores con las que se trata Identifica los casos de usoRUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas:'Proceso':Las etapas de esta seccin son: (Revise nuevamente la grfica) Modelado de negocio Requisitos Anlisis y Diseo Implementacin Pruebas DespliegueSoporte:En esta parte nos encontramos con las siguientes etapas: Gestin del cambio y configuraciones Gestin del proyecto EntornoLa estructura dinmica de RUP es la que permite que ste sea un proceso de desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases descritas anteriormente: Inicio (tambin llamado Incepcin o Concepcin). Elaboracin. Desarrollo (tambin llamado Implementacin, Construccin). Cierre (tambin llamado Transicin).Fase de Inicio: Esta fase tiene como propsito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visin muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores.Fase de elaboracin: En la fase de elaboracin se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificacin de los casos de uso seleccionados y el primer anlisis del dominio del problema, se disea la solucin preliminar.Fase de Desarrollo: El propsito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto.Fase de Transicin: El propsito de esta fase es asegurar que el software est disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptacin, capacitar a los usuarios y proveer el soporte tcnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.Fase de concepcinEsta fase tiene como propsito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos potencialesasociados al proyecto, proponer una visin muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones.Fase de elaboracinEn la fase de elaboracin se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificacin de los casos de uso seleccionados y el primer anlisis del dominio del problema, se disea la solucin preliminar.Fase de construccinEl propsito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requerimientos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto.Fase de transicinEl propsito de esta fase es asegurar que el software est disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptacin, capacitar a los usuarios y proveer el soporte tcnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.Este tipo de metodologa no ha sido aplicada probablemente por su complejidad de administracin o desconocimiento de la misma, desaprovechando sus considerables ventajas respecto a los mtodos tradicionales. Por esto, es necesario entonces desarrollar mecanismos de apropiacin tecnolgica ms eficaces, que permitan mantener actualizadas las prcticas organizacionales y los marcos de referencia aqu mencionados. Es aqu, donde es necesario considerar que el conocimiento de la metodologa y desarrollo de habilidades de los analistas, programadores, administradores de bases de bases de datos y dems miembros del equipo de desarrollo, comienzan desde su preparacin universitaria donde es necesario conocer este enfoque y aplicarlo en proyectos en donde utilicen las guas de trabajo definidas en el RUP y desarrollen los artefactos asociados;