Metodologías de Desarrollo de Software

METODOLOGÍAS DE DESARROLLO DE SOFTWARE
● Metodologías estructuradas
■ Fines de los 70’s con la Programación Estructurada
● Técnicas para el Diseño
○ Diagrama de Estructura
○ Diagramas de Flujo de Datos
■ Estas metodologías son particularmente apropiadas en proyectos que
utilizan para la implementación lenguajes de 3ra y 4ta generación.
■ Ejemplos de metodologías:
● MERISE (Francia)
● MÉTRICA (España)
● SSADM (Reino Unido)
● Gane & Sarson Ward & Mellor
● Yourdon & DeMarco
● Information Engineering.
● Metodologías orientadas a objetos
■ Unidas a la evolución de los lenguajes de programación orientada a

objeto,
● SIMULA (60’s)
● Smalltalk-80L (70’s)
● C++ por Bjarne Stroustrup (1981)
● Java , Visual Basic, C# (Actualidad).
■ Métodos OO :
● OOAD (Booch)
● OOSE (Jacobson, Coad & Yourdon, Shaler & Mellor)
● OMT (Rumbaugh)
● UML (Booch y Rumbaugh)
■ Algunas metodologías orientadas a objetos que utilizan la notación
UML son:
● Rational Unified Process (RUP)
● OPEN
● MÉTRICA (que también soporta la notación estructurada).
● Metodologías tradicionales (no ágiles)
■ Están guiadas por una fuerte planificación durante todo el proceso de

desarrollo;
■ Se realiza una intensa etapa de análisis y diseño antes de la
construcción del sistema.
■ Todas las propuestas metodológicas antes indicadas pueden
considerarse como metodologías
■ tradicionales.
● Metodologías ágiles
● Características:
○ incremental
○ cooperativo
○ sencillo
○ adaptable
○ Extreme Programming .
○ Scrum.
○ Kanban
○ Lean
○ Familia de Metodologías Crystal.
○ Feature Driven Development .
○ Proceso Unificado Rational, una configuración ágil.
○ Dynamic Systems Development Method .
○ Adaptive Software Development .
○ Open Source Software Development .
Diferencia entre metodologías de desarrollo

SCRUM Principios y aspectos
Definición de Requerimiento
● Condición o capacidad que necesita el usuario para resolver un problema o alcanzar

un objetivo
● Condición o capacidad que debe satisfacer o poseer un sistema o una componente
de un sistema para satisfacer un contrato, un estándar, una especificación u otro
documento formalmente impuesto
● Representación documentada de una condición o capacidad como en 1 o 2.
Definición de Ingeniería de Requerimientos
Definición de stakeholders
● Son los individuos u organismos que ganan o pierden con algún cambio, son
impactados positiva o negativamente independientemente o no de su voluntad.
Tienen interés en el resultado del cambio
● Loucopoulos (cap 3):
○ “the parties who have interest in the software system under development”
● (Wieringa&Glinz, 2007)
○ “A stakeholder is a person or organization who influences a system’s
requirements or who is impacted by that system”
Clasificación de stakeholders
● Interesados en su construcción
○ Responsabilidad por el diseño y desarrollo
○ Incluye: project managers, diseñadores de software, expertos en
comunicaciones
● Interés financiero
○ Responsabilidad por la compra o la venta
○ Incluye: analista de negocios, gerente de ventas, comprador
● Interesados en su introducción y operación
○ Responsabilidad por la implementación y el mantenimiento
○ Incluye: equipo de entrenamiento y soporte del usuario, ingenieros de
instalación y mantenimiento, gerentes usuarios
● Interesados en su uso
○ Interés en su uso
○ Incluye: gerentes usuarios, toda clase de usuarios (directos e indirectos)
El Contrato social
● Derechos del usuario

○ Que el analista que hable su lenguaje
○ Que el analista aprenda sobre su negocio y sus objetivos
○ Que el analista escriba una Especificación de Requerimientos de Software
○ Recibir explicaciones de los productos creados en el proceso de
requerimientos
○ Recibir un trato respetuoso de los Desarrolladores
○ Que le ofrezcan ideas y alternativas para los requerimientos y su
implementación
○ Características del producto que lo hagan simple y agradable de usar
○ Manejar opciones de ajustar sus requerimientos para permitir la reutilización
de componentes de software preexistentes
○ Recibir estimaciones de buena fe de costos de los cambios
○ Recibir un sistema que satisfaga sus necesidades funcionales y de calidad
○ Educar a los analistas y desarrolladores en su negocio
○ Destinar tiempo a proveer y clarificar los negocios
○ Ser específico y preciso acerca de los requerimientos
○ Tomar decisiones a tiempo
○ Respetar las evaluaciones de costo y factibilidad de los desarrolladores
○ Establecer prioridades a los requerimientos
○ Revisar los documentos de requerimientos y evaluar prototipos
○ Comunicar los cambios a los requerimientos
○ Seguir el proceso de cambios de la organización de desarrollo
○ Respetar el proceso de Ingeniería de Requerimientos que el analista utiliza
Categorías de requerimientos
● Orientados al Mercado
○ Bocetos e informales
○ Técnicas más de manufactura que de SE
○ Especificación en forma de presentación comercial
○ “Cliente” no fácilmente identificable
○ Consultores para aspectos deseables
○ Enfoque poco estructurado.
● Específicos para un cliente

○ Voluminosos y más “formales”
○ Uso de técnicas de SE
○ Largas especificaciones
○ Uso del conocimiento del dominio
○ Proyectos basados en personal propio
○ Enfoque estructurado con un enfoque particular
Validación de requerimientos
● Proceso que certifica que se ataca el problema correcto

● Hay enfoques de RE que no lo separan de elicitación y especificación
● La diferenciación es importante por razones conceptuales y prácticas
Proceso de requerimientos
● EL PROCESO GLOBAL
● ELICITACIÓN
● ESPECIFICACIÓN
● VALIDACIÓN
Elicitación de requerimientos
● Cuando se trata de resolver un problema la primero es descubrir más sobre él

● “Elicitación de requerimientos es el proceso de adquirir (“eliciting”) [sonsacar] todo el
conocimiento relevante necesario para producir un
● modelo de los requerimientos de un dominio de problema” (Loucopoulos)
● Objetivo: entender el dominio del problema en particular
● Producto: conocimiento del dominio
● Sin un conocimiento del problema no se puede:
○ entender la terminología
○ testear la consistencia y completitud de una especificación
● Problema en el proceso de elicitación:
○ ¿dónde se puede encontrar el conocimiento de un dominio y cómo se puede
elicitar ese conocimiento?
○ el conocimiento está distribuido en diferentes fuentes.
○ muchas veces esta diversidad es conflictiva.
○ una parte importante puede residir en expertos humanos
● Problemas en la transmisión del conocimiento del dominio:

○ el conocimiento no está disponible en una forma utilizable para los analistas.
○ es difícil elicitar el conocimiento en especial cuando se trata de un experto
humano.
○ el efecto Hawthorne: la presencia de un observador deforma el resultado.
○ los usuarios pueden estar sesgados por el sistema actual.
○ el sesgo que introduce el ingeniero en el proceso.
Especificación de requerimientos
Una especificación puede ser vista como un contrato entre usuarios y desarrolladores de
software, que define el comportamiento funcional deseado del artefacto de software (y otras
propiedades de este, tales como performance, confiabilidad, etc.) sin mostrar como será
alcanzada tal funcionalidad
Validación de requerimientos
● Proceso que certifica que se ataca el problema correcto

● Hay enfoques de RE que no lo separan de elicitación y especificación
● La diferenciación es importante por razones conceptuales y prácticas
Propósito de las Historias de Usuario
● Sirven para describir lo que el usuario desea ser capaz de hacer.

● Se centran en el valor que viene de usar el sistema en lugar de una especificación
detallada de lo que el sistema debe hacer.
● Están concebidos como un medio para fomentar la colaboración
Características INVEST
● Independientes: De ser necesario, combinar las historias dependientes o buscar

otra forma de dividir las historias de manera que resulten independientes.
● Negociables: La historia en si misma no es lo suficientemente explícita como para
considerarse un contrato, la discusión con los usuarios debe permitir esclarecer su
alcance y éste debe dejarse explícito bajo la forma de pruebas de validación.
● Valoradas por los clientes o usuarios: Los intereses de los clientes y de los
usuarios no siempre coinciden, pero en todo caso, cada historia debe ser importante
para alguno de ellos más que para el desarrollador.
● Estimables: Un resultado de la discusión de una historia de usuario es la estimación
del tiempo que tomará completarla. Esto permite estimar el tiempo total del proyecto.
● Pequeñas: Las historias muy largas son difíciles de estimar e imponen restricciones
sobre la planificación de un desarrollo iterativo. Generalmente se recomienda la
consolidación de historias muy cortas en una sola historia.
● Verificables: Las historias de usuario cubren requerimientos funcionales, por lo que
generalmente son verificables. Cuando sea posible, la verificación debe
automatizarse, de manera que pueda ser verificada en cada entrega del proyecto.
Características de los prototipos
● Debe ser un sistema con el que se pueda experimentar

● Debe ser comparativamente barato(menor que el 10%)
● Debe desarrollarse rápidamente
● Énfasis en la interfaz de usuario
● Equipo de desarrollo reducido
● Herramientas y lenguajes adecuadas
Ventajas y desventajas de los prototipos
● Ventajas
○ No modifica el flujo del ciclo de vida
○ Reduce el riesgo de construir productos que no satisfagan las necesidades
de los usuarios
○ Reduce costo y aumenta la probabilidad de éxito
○ Exige disponer de las herramientas adecuadas
○ 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.
○ También 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
debería tomar la interacción humano máquina.
● Desventajas
○ Debido a que el usuario ve que el prototipo funciona piensa que este es el
producto terminado y no entienden que recién se va a desarrollar el software.
○ El desarrollador puede caer en la tentación de ampliar el prototipo para
construir el sistema final sin tener en cuenta los compromisos de calidad y
mantenimiento que tiene con el cliente
Categorías de modelos de sistemas

Clases abstractas
● Permite abstraer o obtener lo importante de lo no importante

● Obtener características y funcionalidades comunes del mismo objeto y crear
estructuras que nos permitan abstraer.
● Puede tener métodos abstractos
● Algo que se va a volver a utilizar después
Agregación
Cuando desaparece el objeto padre se mantiene el objeto hijo, es decir simplemente se

relaciona.
Composición
Cuando desaparece el objeto padre desaparece el objeto hijo

Metodologías de Desarrollo de Software

Cargado por

Copyright:

Formatos disponibles

Metodologías de Desarrollo de Software

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Metodologías de Desarrollo de Software

Cargado por

Copyright:

Formatos disponibles

METODOLOGÍAS DE DESARROLLO DE SOFTWARE

● Metodologías orientadas a objetos

■ Unidas a la evolución de los lenguajes de programación orientada a

● Metodologías tradicionales (no ágiles)

■ Están guiadas por una fuerte planificación durante todo el proceso de

Diferencia entre metodologías de desarrollo

● Condición o capacidad que necesita el usuario para resolver un problema o alcanzar

Definición de Ingeniería de Requerimientos

● Derechos del usuario

● Específicos para un cliente

● Proceso que certifica que se ataca el problema correcto

● Cuando se trata de resolver un problema la primero es descubrir más sobre él

● Problemas en la transmisión del conocimiento del dominio:

● Proceso que certifica que se ataca el problema correcto

Propósito de las Historias de Usuario

● Sirven para describir lo que el usuario desea ser capaz de hacer.

● Independientes: De ser necesario, combinar las historias dependientes o buscar

Características de los prototipos

● Debe ser un sistema con el que se pueda experimentar

Ventajas y desventajas de los prototipos

Categorías de modelos de sistemas

● Permite abstraer o obtener lo importante de lo no importante

Cuando desaparece el objeto padre se mantiene el objeto hijo, es decir simplemente se

Cuando desaparece el objeto padre desaparece el objeto hijo

También podría gustarte

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.