Professional Documents
Culture Documents
del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalizacin de la etapa anterior. Un ejemplo de una metodologa de desarrollo en cascada es: 1. 2. 3. 4. 5. 6. 7. Anlisis de requisitos Diseo del Sistema Diseo del Programa Codificacin Pruebas Implantacin 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 costes del desarrollo. La palabra cascada sugiere, mediante la metfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases ms avanzadas de un proyecto.
Anlisis de requisitos
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 sDiseo del Sistema
Se 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.
] Codificacin
Es la fase en donde se implementa el cdigo fuente, haciendo uso de prototipos as como de pruebas y ensayos para corregir errores. 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
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
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.
Mantenimiento
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. Modelos evolutivos
El software evoluciona con el tiempo. Los requisitos del usuario y del producto suelen cambiar conforme se desarrolla el mismo. Las fechas de mercado y la competencia hacen que no sea posible esperar a poner en el mercado un producto absolutamente completo, por lo que se debe introducir una versin funcional limitada de alguna forma para aliviar las presiones competitivas. En esas u otras situaciones similares los desarrolladores necesitan modelos de progreso que estn diseados para acomodarse a una evolucin temporal o progresiva, donde los requisitos centrales son conocidos de antemano, aunque no estn bien definidos a nivel detalle. En el modelo Cascada y Cascada Realimentado no se tiene en cuenta la naturaleza evolutiva del software, se plantea como esttico con requisitos bien conocidos y definidos desde el inicio.6 Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez ms completas y complejas, hasta llegar al objetivo final deseado; incluso evolucionar ms all, durante la fase de operacin. Los modelos iterativo incremental y espiral (entre otros) son dos de los ms conocidos y utilizados del tipo evolutivo.9
Las herramientas CASE (Computer Aided Software Engineering, Ingeniera de Software Asistida por Computadora) son diversasaplicaciones informticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en trminos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseo del proyecto, clculo de costes, implementacin de parte del cdigo automticamente con el diseo dado, compilacin automtica, documentacin o deteccin de errores entre otras. Sistema de software que intenta proporcionar ayuda automatizada a las actividades del proceso de software. Los sistemas CASE a menudo se utilizan como apoyo al mtodo.
Objetivos
1. 2. 3. 4. 5. 6. 7. 8. 9. Mejorar la productividad en el desarrollo y mantenimiento del software. Aumentar la calidad del software. Reducir el tiempo y coste de desarrollo y mantenimiento de los sistemas informticos. Mejorar la planificacin de un proyecto Aumentar la biblioteca de conocimiento informtico de una empresa ayudando a la bsqueda de soluciones para los requisitos. Automatizar el desarrollo del software, la documentacin, la generacin de cdigo, las pruebas de errores y la gestin del proyecto. Ayuda a la reutilizacin del software, portabilidad y estandarizacin de la documentacin Gestin global en todas las fases de desarrollo de software con una misma herramienta. Facilitar el uso de las distintas metodologas propias de la ingeniera del software.
[editar] Clasificacin
Aunque no es fcil y no existe una forma nica de clasificarlas, las herramientas CASE se pueden clasificar teniendo en cuenta los siguientes parmetros:
1. 2. 3. 4.
Las plataformas que soportan. Las fases del ciclo de vida del desarrollo de sistemas que cubren. La arquitectura de las aplicaciones que producen. Su funcionalidad.
Actividades del proceso de desarrollo de software representados en el desarrollo en cascada. Hay algunos modelos ms para representar este proceso.
Un proceso para el desarrollo de software, tambin denominado ciclo de vida del desarrollo de software es una estructura aplicada al desarrollo de un producto de software. Hay varios modelos a seguir para el establecimiento de un proceso para el desarrollo de software, cada uno de los cuales describe una enfoque diferente para diferentes actividades que tienen lugar durante el proceso. Algunos autores consideran un modelo de ciclo de vida un trmino ms general que un determinado proceso para el desarrollo de software. Por ejemplo, hay varios procesos de desarrollo de software especficos que se ajustan a un modelo de ciclo de vida de espiral.
El modelo de cascada muestra un proceso donde los desarrolladores han de seguir las siguientes fases de forma sucesiva:
1. 2. 3. 4. 5. 6.
Especificacin de requisitos Diseo del software Integracin Pruebas (o validacin) Despliegue (o instalacin) Mantenimiento
Siguiendo el modelo de cascada de forma estricta, slo cuando se finaliza una fase, comienza la otra. En ocasiones se realiza una revisin antes de iniciar la siguiente fase, lo que permite la posibilidad de cambios (lo que puede incluir un proceso de control formal de cambio). Las revisiones tambin se utilizar para asegurar que la fase anterior ha sido totalmente finalizada; los criterios paracompletar una fase se conoce frecuentemente con el trmino ingls "gate" (puerta). Este modelo desaconseja revisitar y revisar fases que ya se han completado. Esta falta de flexibilidad en un modelo de cascada puro ha sido fuente de crtica de los defensores de modelos ms flexibles.
La principal caractersticas del modelo en espiral es la gestin de riesgos de forma peridica en el ciclo de desarrollo. Este modelo fue creado en 1988 por Barry Boehm, combinando algunos aspectos clave de las metodologas del modelo de cascada y del desarrollo rpido de aplicaciones, pero dando nfasis en un rea que para muchos no jug el papel que requiere en otros modelos: un anlisis iterativo y concienzudo de los riesgos, especialmente en el caso de sistema complejos de gran escala. La espiral se visualiza como un proceso que pasa a travs de algunas iteraciones con el diagrama de los cuatro cuadrantes representativos de las siguientes actividades:
1. crear planes con el propsito de identificar los objetivos del software,seleccionados para implementar el programa y clarificar las restricciones en el desarrollo del software; 2. Anlisis de riesgos: una evaluacin analtica de programas seleccionados, para evaluar como identificar y eliminar el riesgo; 3. la implementacin del proyecto: implementacin del desarrollo del software y su pertinente verificacin;
Modelo de espiral con nfasis en los riesgos, haciendo hincapi en las condiciones de las opciones y limitaciones para facilitar la reutilizacin de software, la calidad del software puede ayudar como una meta propia en la integracin en el desarrollo del producto. Sin embargo, el modelo en espiral tiene algunas limitaciones, entre las que destacan:
1. El nfasis se sita en el anlisis de riesgo, y por lo tanto requiere de clientes que acepten este anlisis y acten en consecuencia. Para ello es necesaria confianza en los desarrolladores as como la predisposicin a gastar ms para solventar los temas, por lo cual este modelo se utiliza frecuentemente en desarrollo interno de software a gran escala.
2. Si la implementacin del riesgo de anlisis afectar de forma esencial los beneficios del proyecto, no debera utilizarse este modelo. 3. Los desarrolladores de software han de buscar de forma explcita riesgos y analizarlos de forma exhaustiva para que este modelo funcione.
La primera fase es la bsqueda de un plan para conseguir los objetivos con las limitaciones del proyecto para as buscar y eliminar todos los riesgos potenciales por medio de un cuidadoso anlisis, y si fuera necesario incluyendo la fabricacin de un prototipo. Si es imposible descartar algunos riesgos, el cliente ha de decidir si es conveniente terminar el proyecto o seguir adelante ignorando los riesgos. Por ltimo, se evalan los resultados y se inicia el diseo de la siguiente fase.
El desarrollo gil de software utiliza un desarrollo iterativo como base para abogar por un punto de vista ms ligero y ms centrado en las personas que en el caso de las soluciones tradicionales. Los procesos giles utilizan retroalimentacin en lugar de planificacin, como principal mecanismo de control. La retroalimentacin se canaliza por medio de pruebas peridicas y frecuentes versiones del software. Hay muchas variantes de los procesos giles:
En el caso de la programacin extrema (XP), las fases se realizan en pasos muy cortos (o "continuos") con respecto al anterior. El primer paso (intencionalmente incompleto) por los pasos puede ocurrir en un da o en una semana, en lugar de los meses o aos de cada paso completo en el modelo en cascada. En primer lugar, se crean pruebas automatizadas para proveer metas concretas al desarrollo. Despus se programa el cdigo, que ser completo cuando todas las pruebas se superan sin errores, y los desarrolladores ya no sabran como mejorar el conjunto de pruebas necesario. El diseo y la arquitectura emergen a partir de la refactorizacin del cdigo, y se da despus de programar. El diseo lo realizan los propios desarrolladores del cdigo. El sistema, incompleto, pero funcional se despliega para su demostracin a los usuarios (al menos uno de los cuales pertenece al equipo de desarrollo). Llegado este punto, los profesionales comienzan a escribir las pruebas para la siguiente parte del sistema de ms importancia.
tiempo de forma explcita para el diseo, los programadores comienzan de forma inmediata a producir cdigo. Antes o despus comienza la fase de pruebas de software (a menudo de forma tarda) y los inevitables errores que se encuentran han de eliminarse antes de poder entregar el software.
Los mtodos formales se suelen aplicar en software de aviacin, especialmente si es software de seguridad crtico. Los estndares de aseguramiento del software de seguridad, tales como DO178B demandan mtodos formales en el nivel ms alto de categorizacin (Nivel A). La formalizacin del desarrollo de software est ganando en fuerza poco a poco, en otros mbitos, con la aplicacin del lenguaje de especificacin OCL2.0 (y especializaciones tales como Java Modeling Language) y particularmente con Modeldriven Architecture, que permite la ejecucin de diseos, incluso especificaciones. Otra tendencia que est surgiendo en el desarrollo de software es la redaccin de especificaciones en algn tipo de lgica (normalmente una variacin de FOL), para acto seguido ejecutar esa lgica como si se tratase de un programa. El lenguaje OWL, basado en lgica descriptiva, es un buen ejemplo. Tambin se est trabajando en enlazar un idioma natural de forma automtica con lgica, lgica que puede ejecutarse. Ejemplo en este campo es el Attempto Controlled English, una lgica de negocios de Internet, que no busca controlar el vocabulario o la sintaxis. Una caractersticas de los sistemas que apoyan el vnculo bidireccional ingls-lgica y ejecucin directa de la lgica es que pueden explicar sus resultados en ingls en un nivel de negocios o cientfico.
Proceso Unificado
De Wikipedia, la enciclopedia libre Saltar a: navegacin, bsqueda
El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser 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 84-7829-036-2) 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
Diagrama ilustrando como el nfasis relativo en las distintas disciplinas cambia a lo largo del proyecto.
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.