Diferencia entre revisiones de «Proceso Unificado de Desarrollo»
Contenido eliminado Contenido añadido
Sin resumen de edición |
|||
Línea 29:
Estas son las fases en que se divide cada uno de los ciclos de vida por los que pasa un proyecto software:
*'''Concepción''': El alcance de un acuerdo entre todos los interesados respecto a los objetivos (de este ciclo) del proyecto. Los objetivos en esta fase son:
**
**Discriminar los casos de uso más importantes del sistema.
**
**Estimar los riesgos potenciales.
**
*'''Elaboración''': El establecimiento de una línea base para la arquitectura del sistema. Los objetivos en esta fase son:
**Garantizar que la arquitectura, los requisitos y los planes son lo bastante estables, y que los riesgos están suficientemente mitigados.
**Tratar todos los riesgos arquitectónicamente significativos del proyecto.
**Producir un prototipo de componentes de calidad de producción.
**Establecer un entorno de soporte.
*'''Construcción''': La finalización del desarrollo del sistema basado en la arquitectura de línea base anterior. Los objetivos en esta fase son:
**Minimizar los costos de desarrollo optimizando los recursos y evitando las reconstrucciones y los fragmentos innecesarios.
**Conseguir la calidad adecuada de forma rápida y práctica.
**Conseguir versiones útiles (alfa, beta y otros releases de prueba) de forma rápida y práctica.
**Completar el análisis, diseño, desarrollo y prueba de toda la funcionalidad necesaria.
**Desarrollar de forma iterativa e incremental un producto.
*'''Transición''': La garantía de que el software está operativo y es de utilidad para los usuarios. Los objetivos en esta fase son:
**Ejecutar el despliegue.
**Prueba de versión beta para validar el nuevo sistema contra las expectativas del usuario.
**Convertir bases de datos operativas.
**Formación de usuarios y mantenedores.
**Despliegue de la fuerza de marketing, distribución y ventas.
**Alcanzar la capacidad de soporte propio del usuario.
=== Componentes y servicios===
Línea 76 ⟶ 68:
SOA define un conjunto de técnicas y productos de trabajo, tal como aparece en la figura de esta sección, para definir modelos de solución de extremo a extremo.
==
Los casos de uso son una técnica, muy característica de este modelo de proceso, con la que especificar el comportamiento del sistema.
Un Caso de Uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios.
Si vemos el software como un sistema que ofrece a su entorno una serie de servicios, un caso de uso es una forma de expresar la manera en que un usuario o un sistema externo (llamado 'actor') lo utiliza.
Los casos de uso no describen ninguna funcionalidad interna (oculta al exterior) del sistema, ni explican cómo se implementará. Simplemente muestran los pasos que el actor sigue para realizar una tarea.
La técnica de caso de uso es muy útil en el desarrollo de sistemas interactivos, ya que expresa la intención que tiene el actor al hacer uso del sistema.
Como técnica de extracción de requisitos permite que el analista se centre en las necesidades del usuario (¿qué espera éste lograr al utilizar el sistema?), evitando que los desarrolladores dirijan la funcionalidad del nuevo sistema basándose solamente en criterios tecnológicos.
A su vez, mientras se obtienen los requisitos, el analista se concentra en las tareas centrales del usuario, las más importantes, describiendo por lo tanto los casos de uso que mayor valor aportan al negocio. Esto facilita luego la priorización de estos requisitos.
Los casos de uso pueden ser útiles para establecer requisitos de comportamiento, pero no establecen completamente los requisitos funcionales ni permiten determinar los requisitos no funcionales. Los casos de uso deben complementarse con información adicional como reglas de negocio, requisitos no funcionales, diccionario de datos, etc. que complementa los requisitos formales del sistema. De hecho cada caso de uso considerado 'crítico' debería tener una serie de requisitos no funcionales que especifiquen a fondo el comportamiento asociado.
==Ventajas y recomendaciones de uso==
Cualquier Proceso Unificado, y concretamente RUP, proporciona un entorno de proceso bastante configurable y basado en fuertes estándares. Este entorno de proceso permite establecer un método personalizado para cada organización, configurándolo para satisfacer las necesidades exclusivas de cada proyecto.
Línea 90 ⟶ 97:
*La estructura del ciclo vital del proyecto (número de iteraciones, duración total del proyecto y de cada una de sus fases)
==
En resumidas cuentas, podemos decir que el Proceso Unificado es un importante marco de referencia en Ingeniería de Software con el que definir, implementar y distribuir aplicaciones de software.
Presenta un modelo dividido en 4 fases:
*Concepcion: Sobretodo define el alcance del proyecto
*Elaboración: Especificación formal, análisis y diseño
*Construcción: Implementación
*Transición: Cierre del proyecto y paso a producción
Las ventajas de este modelo son la reducción de riesgos en el proyecto, la garantía de calidad, y la integración entre lo que es propiamente desarrollo con mantenimiento de software (a base de ir iterando en cada fase, combinando actividades de uno y otro tipo).
Como desventajas, podemos señalar que requiere una gran previsión sobre lo que va a ocurrir (para poder controlarlo) y que genera abundante trabajo adicional (y costes asociados) de documentación y comunicación, con lo que no suele resultar práctico para proyectos pequeños.
==Lecciones relacionadas==
*
*
*
*[[Scrum]]
==Referencias==
| |||