Porque tener una Metodología o Proceso de Desarrollo de SW?
Es la forma más económica de empezar a introducir buenas practicas para el desarrollo.
Permite que las personas puedan trabajar en forma ordenada.
Puedan detectar sus fallas y adquirir mejoras prácticas.
¿Que características debe tener una Metodología?
Debe abarcar todo el proceso de creación del SW
Debe ser fácil de aplicar
Debe Brindar medidas objetivas para medir los errores y facilitar la estimación
Permitir identificar puntos débiles de las personas
Debe minimizar la introducción de errores
Aplicable a las herramientas de desarrollo utilizadas
El proceso de Construcción del Software
Es un proceso de resolución de problemas: Transformación de una necesidad en una solución automatizada que satisface la necesidad:
Qué: Obtención de los requisitos y Analizarlos
Cómo: Diseñar el sistema
Diseño de Alto Nivel o Preliminar:
Descomposición del Sistema en componentes y sus Relaciones
Diseño de Bajo Nivel o Detallado:
Especificación de la función de cada componente
Hacerlo:
Implementar
Probar:
Pruebas
Usar: Implantación y Uso Mantenimiento
El Proceso Unificado es un proceso de desarrollo de software, de modo que es :
Un conjunto de actividades necesarias para transformar requisitos de los usuarios en un sistema software.
Un marco de trabajo genérico, que puede especializarse para una gran variedad de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyectos.
El PUD y UML
El Proceso Unificado está basado en componentes software interconectados a través de interfaces. Utiliza el Lenguaje Unificado de Modelado (UML) para preparar los esquemas de un sistema de software.
CARACTERÍSTICAS DEL PUD
Dirigido por Casos de Uso
Podríamos decir que un Caso de Uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante Se utilizan para representar los requisitos funcionales.
No sólo inician el proceso de desarrollo, sino que le proporcionan un hilo conductor.
El proceso avanza a través de una serie de flujos de trabajo que parten de los casos de uso.
Los casos de uso se especifican, se diseñan, y los casos de uso finales son la fuente a partir de la cual se constituyen los casos de prueba.
Está centrado en la arquitectura
La arquitectura es una vista del diseño completo con las características más importantes resaltadas, dejando los detalles de lado.
El valor de la arquitectura depende de las personas que se hayan responsabilizado de su creación
Cada producto tiene tanto una función como una forma
Ambas fuerzas deben equilibrarse para lograr un producto de éxito
La función corresponde a los casos de uso y la forma a la arquitectura
Los casos de uso y la arquitectura deben evolucionar en paralelo.
EL PUD es iterativo e incremental
Un producto software puede conllevar mucho tiempo
Resulta más práctico dividirlo en pequeñas partes o miniproyectos Cada miniproyecto es una iteración que acaba en un incremento
Las iteraciones hacen referencia a pasos en el flujo de trabajo y los incrementos al crecimiento del producto
La iteración trata un grupo de casos de uso que amplía la utilidad del producto desarrollado e identifica los riesgos más importantes En cada iteración:
Se identifican y especifican los casos de uso más relevantes
Se crea un diseño utilizando la arquitectura como guía
Se implementa el diseño como componentes y Se verifica que dichos componentes satisfacen los casos de uso
La vida del Proceso Unificado
Se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema.
Cada ciclo concluye con una versión del producto para los clientes.
Como vimos anteriormente, cada fase se subdivide en iteraciones.
Clasificación de los casos de uso
Los casos de uso deben ser clasificados y los que ocupen niveles más altos habrían de abordarse en los ciclos iniciales de desarrollo
Seleccionar aquellos que influyen profundamente en la arquitectura básica, dando soporte al dominio y a las capas de servicios de alto nivel o a los que presentan el máximo riesgo
Cuando Crear Artefactos
En la fase de elaboración pueden crearse ciertos artefactos, entre ellos:
El modelo Conceptual
Casos de uso de alto nivel
Conceptos Importantes
Artefacto:
Pieza de información tangible que:
Es creada, modificada y usada por los trabajadores al realizar las actividades
Representa un área de responsabilidad
Es candidata a ser tenida en cuenta para el control de la configuración.
Un artefacto puede ser:
un modelo
un elemento de un modelo
un documento
el código o alguna parte del mismo
Actividad:
Unidad tangible de trabajo realizada por un trabajador en un flujo de trabajo de forma que:
Implica una responsabilidad bien definida para el trabajador
Produce un resultado bien definido basado en una entrada bien definida
Representa una unidad de trabajo con límites bien definidos
Modelo:
Es una abstracción del sistema, especificando el sistema modelado desde un cierto punto de vista y en un determinado nivel de abstracción
Son abstracciones del sistema que construyen los arquitectos y desarrolladores
Un modelo siempre identifica el sistema que está modelando
No hay comentarios:
Publicar un comentario