Está en la página 1de 14

Metodologías de

software
Docente: Ing. Pedro V. Velasquez Hurtado
Metodología Tradicional

 RUP .
 (Proceso Unificado de Desarrollo)
 Destacan que el proceso de software propuesto por RUP tiene tres
características esenciales: esta dirigido por los Casos de Usos, esta centrado
en la arquitectura, y es iterativo e incremental.
Proceso Dirigido por casos de usos

 Según Kruoo, los casos de uso son una técnica de captura de requisitos que
fuerza a pensar en términos de importancia para el usuario y no solo en
términos de funciones que seria bueno contemplar. Se define un Caso de Uso
como un fragmento de funcionalidad del sistema que proporciona al usuario
un valor añadido Los casos de uso representan los requisitos funcionales del
sistema.
Proceso Centrado en la Arquitectura

 La arquitectura de un sistema es la organización o estructura de sus partes


mas, relevantes, lo que permite tener una visión común entre todos los
involucrados (desarrolladores y usuarios) y una perspectiva clara del sistema
completo, necesaria para controlar el desarrollo.
 La arquitectura se ve influenciada por la plataforma del software, sistema
operativo, gestor de base de datos, protocolos, consideraciones de desarrollo
como sistemas heredados. Muchas de estas restricciones constituyen
requisitos no funcionales del sistema.
Proceso Iterativo e Incremental

 Según el equilibrio correcto entre los casos de uso y la arquitectura es algo


muy parecido al equilibrio de la forma y la función en el desarrollo del
producto, lo cual se consigue con el tiempo. Para esto, la estrategia que se
propone en RUP es tener un proceso iterativo e incremental en donde el
trabajo se divide en partes mas pequeñas o mini proyectos.
Requerimientos funcionales

 Requerimientos funcionales
 Los requerimientos funcionales son declaraciones de los servicios que
proveerá el sistema, de la manera en que éste reaccionará a entradas
particulares. En algunos casos, los requerimientos funcionales de los sistemas
también declaran explícitamente lo que el sistema no debe hacer.
 Ejm:
 El teléfono móvil permitirá crear contactos y almacenarlos en la agenda
(contacto)
 Entre los posibles requerimientos funcionales de un sistema, se incluyen:

 Descripciones de los datos a ser ingresados en el sistema.


 Descripciones de las operaciones a ser realizadas por cada pantalla.
 Descripción de los flujos de trabajo realizados por el sistema.
 Descripción de los reportes del sistema y otras salidas.
 Definición de quien puede ingresar datos en el sistema.
 Como el sistema cumplirá los reglamentos y regulaciones de sector o generales
que le sean aplicables.

Requerimientos no funcionales

 Requerimientos no funcionales
 Son aquellos requerimientos que no se refieren directamente a las funciones
específicas que entrega el sistema, sino a las propiedades emergentes de éste
como la fiabilidad, la respuesta en el tiempo y la capacidad de
almacenamiento. De forma alternativa, definen las restricciones del sistema
como la capacidad de los dispositivos de entrada/salida y la representación
de datos que se utiliza en la interface del sistema.
 Ejm:
 La pantalla del teléfono móvil será tactil
 Al igual que otros tipos de requerimientos de software, como por ejemplo los
requerimientos no funcionales, los requerimientos funcionales se pueden
clasificar según su finalidad, como por ejemplo requerimientos de negocio,
requerimientos originados en aspectos regulatorios, de seguridad, entre otros.
FASES DEL MODELO RUP

 • Inicio

 Esta fase tiene como propósito definir y acordar el alcance del proyecto con
los patrocinadores, identificar los riesgos asociados al proyecto, proponer una
visión muy general de la arquitectura de software y producir el plan de las
fases y el de iteraciones posteriores.
 • Elaboración

 En la fase de elaboración se seleccionan los casos de uso que permiten definir


la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la
especificación de los casos de uso seleccionados y el primer análisis del
dominio del problema, se diseña la solución preliminar.
 • Construcción
 El propósito 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.
 • Transición

 El propósito de esta fase es asegurar que el software esté disponible para los
usuarios finales, ajustar los errores y defectos encontrados en las pruebas de
aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se
debe verificar que el producto cumpla con las especificaciones entregadas por
las personas involucradas en el proyecto.

También podría gustarte