4 1 personalizacion de metodologias

Metodologías de Ingeniería del software

Personalización de metodologías

METODOLOGIAS DE DESARROLLO DE SOFTWARE

Todos nos hemos hecho esta pregunta al desarrollar un

software, ¿Qué metodología debo usar para desarrollar

un sistema?.

Esto es muy importante ya que como arquitectos de

software, debemos tener un plano en donde apoyarnos.

Por muchos años han existido cientos de propuestas

para buscar una solución y sobre todo asegurar la

calidad del software.

El software debe ser pensado, diseñado y desarrollado

como un producto sujeto a normas de calidad.




El software es un producto desarrollado por grupos de personas cuya interacción

debe ser gestionada.

El énfasis en el proceso de desarrollo asegura un producto adecuado a los

requisitos de los clientes.

Muchas veces realizamos el diseño de

nuestro software de manera rígida, con los

requerimientos que el cliente nos solicitó de

tal manera que el cliente en la etapa final o

de pruebas solicita un cambio se nos hace

muy difícil realizarlo.




El desarrollo de software no es sin dudas una tarea fácil. Como resultado a este

problema ha surgido una alternativa desde hace mucho: la Metodología.

Las metodologías imponen un proceso disciplinado sobre el desarrollo de

software con el fin de hacerlo más predecible y eficiente.

Lo hacen desarrollando un proceso detallado

con un fuerte énfasis en la planificación

inspirado por otras disciplinas de la

ingeniería.

Surgen ante la necesidad de utilizar

procedimientos, técnicas, herramientas y

soporte documental a la hora de desarrollar

un producto software




Las metodologías orientadas al control de los procesos, estableciendo

rigurosamente las actividades a desarrollar, herramientas a utilizar y notaciones

que se usarán. Estas metodologías son llamadas Metodologías Pesadas.

Las metodologías orientadas a la interacción con el cliente y el desarrollo

incremental del software, mostrando versiones parcialmente funcionales del

software al cliente en intervalos cortos de tiempo, para que pueda evaluar y

sugerir cambios en el producto según se va desarrollando. Estas son llamadas

Metodologías ligeras/ágiles.



Metodología RUP

El Proceso Unificado Racional (Rational Unified Process- RUP), es un proceso de

desarrollo de software y junto con el Lenguaje Unificado de Modelado UML,

constituye la metodología estándar más utilizada para el análisis, implementación

y documentación de sistemas orientados a objetos.

El RUP no es un sistema con pasos firmemente establecidos, sino que trata de un

conjunto de metodologías adaptables al contexto y necesidades de cada

organización, donde el software es organizado como una colección de unidades

atómicas llamados objetos, constituidos por datos y funciones, que interactúan

entre sí.

RUP es un proceso para el desarrollo de un proyecto

de un software que define claramente quien, cómo,

cuándo y qué debe hacerse en el proyecto



RUP – como proceso de desarrollo

• RUP es explícito en la definición de software y su trazabilidad, es decir,

contempla en relación causal de los programas creados desde los requerimientos

hasta la implementación y pruebas.

• RUP identifica claramente a los profesionales (actores) involucrados en el

desarrollo del software y sus responsabilidades en cada una de las actividades.



RUP – Elementos básicos

El proceso de desarrollo se representa usando un conjunto de elementos de

modelado: roles (el quién), actividades (el cómo), artefactos (el qué) y flujos de

trabajo (el cuándo).

Rol expresa quién (individuo o grupo)

hace un trabajo

Actividad describe cómo es hecho el

trabajo

Artefacto captura el trabajo

realizado




Roles: Un rol es una definición abstracta del conjunto de responsabilidades, para las

actividades a ser desempeñadas y artefactos a ser producidos dentro del proyecto

por un individuo o grupo.

Analistas: captura de requerimientos -investigan (analista procesos negocios)

Desarrolladores: diseño, implementación (arquitecto de software, el diseñador)

Gerentes: dirección de procesos de

ingeniería.(Gte de proyecto, Gte de

publicación -deployment).

Producción y Soporte: soporte al proceso de

desarrollo del software (escritor técnico,

especialista herramientas, administrador de

sistema, etc.)

Probadores: dirigen las pruebas (probador,

analista de pruebas, etc.)




Actividades: Una actividad es una unidad de trabajo que se asigna a un rol, la cual

se requiere sea ejecutada por el individuo asociado a ese rol.

Las actividades están fraccionadas en pasos y estos agrupados en tres categorías:

Pasos de Análisis: cuando el individuo que

desempeña el rol comprende la naturaleza de

la tarea, recolectando y examinando los

artefactos de entrada y formulando resultados

o solución.

Pasos de Ejecución: El rol crea o actualiza

algún artefacto.

Pasos de Revisión: Donde el rol verifica los

resultados contra algún criterio.




Artefactos:

Un artefacto es una pieza de información que es producida o utilizada por

procesos. Los artefactos son los elementos tangibles de un proyecto, elementos

que el proyecto produce o usa mientras se trabaja en busca del producto final.




Flujos de trabajo:

Un flujo de trabajo es una secuencia de actividades que producen un resultado de

valor observable. Una de las grandes dificultades de describir un proceso de

software, es que hay muchas formas de organizar el conjunto de actividades

dentro de un flujo de trabajo.



RUP – fases de desarrollo de software

Inicio

Elaboración

Construcción

Transición



RUP – fases de desarrollo de software



RUP – Fase de inicio

Se hace un plan de fases, donde se identifican los principales casos de uso y se

identifican los riesgos. Se concreta la idea, la visión del producto, como se

enmarca en el negocio, el alcance del proyecto. El objetivo en esta etapa es

determinar la visión del proyecto.

Modelado del negocio

En esta fase el equipo se familiarizará más al funcionamiento de la empresa,

sobre conocer sus procesos.

Entender la estructura y la dinámica de la organización para la cual el sistema

va ser desarrollado.

Entender el problema actual en la organización objetivo e identificar

potenciales mejoras.

Asegurar que clientes, usuarios finales y desarrolladores tengan un

entendimiento común de la organización objetivo.




Requisitos

En esta línea los requisitos son el contrato que se debe cumplir, de modo que los

usuarios finales tienen que comprender y aceptar los requisitos que

especifiquemos.

Establecer y mantener un acuerdo entre clientes y otros stakeholders sobre lo

que el sistema podría hacer.

Proveer a los desarrolladores un mejor entendimiento de los requisitos del

sistema.

Definir el ámbito del sistema.

Proveer una base para estimar costos y tiempo de desarrollo del sistema.

Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y

metas del usuario.



RUP – Fase de elaboración

Se realiza el plan de proyecto, donde se completan los casos de uso y se mitigan

los riesgos. Planificar las actividades necesarias y los recursos requeridos,

especificando las características y el diseño de la arquitectura.

En esta etapa el objetivo es determinar la arquitectura Óptima.

Análisis y Diseño

En esta actividad se especifican los requerimientos y se describen sobre cómo se

van a implementar en el sistema.

Transformar los requisitos al diseño del sistema.

Desarrollar una arquitectura para el sistema.

Adaptar el diseño para que sea consistente con el entorno de implementación.



RUP – Fase de elaboración



RUP - Fase de construcción

Se basa en la elaboración de un producto totalmente operativo y en la elaboración

del manual de usuario. Construir el producto, la arquitectura y los planes, hasta

que el producto está listo para ser enviado a la comunidad de usuarios.

En esta etapa el objetivo es llevar a obtener la capacidad operacional inicial.

Implementación

Se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y

demás. El resultado final es un sistema ejecutable.

Planificar qué subsistemas deben ser implementados y en qué orden deben ser

integrados, formando el Plan de Integración.

Se decide en qué orden implementa los elementos del subsistema.

Si encuentra errores de diseño, los notifica.

Se integra el sistema siguiendo el plan.




Pruebas

Este flujo de trabajo es el encargado de evaluar la calidad del producto que

estamos desarrollando, pero no para aceptar o rechazar el producto al final del

proceso de desarrollo, sino que debe ir integrado en todo el ciclo de vida.

Encontrar y documentar defectos en la calidad del software.

Generalmente asesora sobre la calidad del software percibida.

Provee la validación de los supuestos realizados en el diseño y especificación de

requisitos por medio de demostraciones concretas.

Verificar las funciones del producto de software según lo diseñado.

Verificar que los requisitos tengan su apropiada implementación.



RUP - Fase de transición

El objetivo es llegar a obtener el release del proyecto. Se realiza la instalación del

producto en el cliente y se procede al entrenamiento de los usuarios. Realizar la

transición del producto a los usuarios, lo cual incluye: manufactura, envío,

entrenamiento, soporte y mantenimiento del producto, hasta que el cliente quede

satisfecho, por tanto en esta fase suelen ocurrir cambios.

Despliegue

Esta actividad tiene como objetivo producir con éxito distribuciones del producto

y distribuirlo a los usuarios. Las actividades implicadas incluyen:

Probar el producto en su entorno de ejecución final.

Empaquetar el software para su distribución. Distribuir e instalar el software.

Proveer asistencia y ayuda a los usuarios.

Formar a los usuarios y al cuerpo de ventas.

Migrar el software existente o convertir bases de datos.



RUP - Fase de transición



RUP – Principios clave

Adaptación del proceso: El proceso deberá adaptarse a las características

propias de la organización.

Balancear prioridades: Los requerimientos de los diversos inversores pueden

ser diferentes. Debe encontrarse un balance que satisfaga los deseos de todos.

Colaboración entre equipos: El desarrollo de software no hace una única

persona sino múltiples equipos.

Demostrar valor iterativamente: Los proyectos se entregan, aunque sea de

modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los

inversores, la estabilidad y calidad del producto.

Elevar el nivel de abstracción: Este principio dominante motiva el uso de

conceptos reutilizables tales como patrón del software.

Enfocarse en la calidad: El control de calidad no debe realizarse al final de

cada iteración, sino en todos los aspectos de la producción.



RUP – características esenciales



RUP – características esenciales

Proceso Dirigido por los Casos de Uso:

La utilización de los Casos de Uso para el desenvolvimiento y desarrollo de las

disciplinas con los artefactos, roles y actividades necesarias. Los Casos de Uso son

la base para la implementación de las fases y disciplinas del RUP.

Proceso Iterativo e Incremental: Este modelo plantea la implementación del

proyecto a realizar en Iteraciones, con lo cual se pueden definir objetivos por

cumplir en cada iteración y así poder ir completando todo el proyecto iteración

por iteración.

Proceso Centrado en la Arquitectura:

Define la Arquitectura de un sistema, y una arquitectura ejecutable construida

como un prototipo evolutivo. Una arquitectura ejecutable es una implementación

parcial del sistema, construida para demostrar algunas funciones y propiedades.



RUP – Quiénes deben usar RUP?

RUP es la metodología indicada para el desarrollo y publicación de proyectos de

software críticos dentro de una organización. Esta metodología fue desarrollada

pensando en dos grupos de usuarios:

• Desarrolladores de software, que trabajan como parte de un equipo de

desarrollo de software.

• Personas que practican la ingeniería de procesos, específicamente gerentes e

ingenieros de procesos de software.

Los desarrolladores de software pueden encontrar en RUP una guía, sobre qué es

lo requerido de su rol (o de ellos como desarrolladores) en la definición de roles.

Esta guía también proporciona el cómo, cada uno de estos roles colaboran entre

si, en términos del trabajo detallado que es requerido para establecer el flujo de

trabajo dentro de una iteración.



RUP – Cuándo usar RUP?

RUP puede ser utilizado desde el principio de un proyecto de software y puede

continuar usándose en los subsecuentes ciclos de desarrollo del software después

que la fase inicial ha finalizado.

Sin embargo, la manera en la cual se use RUP, necesita ser trasformada para

ajustarse a las necesidades. Existen algunas consideraciones que modifican el

cuándo y cómo se utilizarán las diferentes partes de RUP, éstas son:

El ciclo de vida del proyecto (número de iteración, longitud de cada fase, el

largo del proyecto).

Los objetivos de negocio del proyecto, visión, alcance y riesgos.

El tamaño del esfuerzo para el desarrollo del software.



Microsoft Solutions Framework (MSF)

MSF es una guía de desarrollo de software flexible que permite aplicar de manera

individual e independiente cada unos de sus componentes, es escalable pues está

diseñada para poder expandirse según la magnitud del proyecto.

MSF está basada en un conjunto de principios, modelos, disciplinas, conceptos,

directrices y practicas aprobadas por Microsoft, que asegura resultados con menor

riesgo y de mayor calidad, centrándose en el proceso y las personas.

MSF se introdujo por primera vez en 1994 como un conjunto de las mejores

prácticas en los desarrollo de Software de Microsoft y Microsoft Consulting Service.




Éste Framework está basado en los modelos espiral y cascada, lo cual indica que

toma elementos de los métodos tradicionales que aún son referentes importantes

para procesos de software.

Es adaptable, flexible y escalable, e independiente de tecnologías, lo cual

significa que no se cierra a un sólo modelo de programación sino más bien queda

abierto según la naturaleza del proyecto.

Usa como referente el DSL (Domain-Specific Language) para realizar el modelado,

así como RUP se apoya en UML para hacer el modelado (Microsoft).



Microsoft Solutions Framework (MSF) -Componentes

MSF es un FrameWork que contiene tres componentes: Los principios fundamentales,

los modelos y las disciplinas. Pueden ser utilizados individuamente o adoptados

como un todo integrado según la naturaleza del proyecto.

Principios fundamentales

Los principios de MSF son 8 valores y normas que son comunes en todo el

FrameWork, los cuales contribuyen a mejorar el trabajo en equipo y a centrarse en

mantener el objetivo del proyecto siempre en marcha:

• Fomentar la comunicación abierta

• Trabajar hacia una visión compartida

• Empoderar a los miembros del equipo

• Establecer la rendición de cuentas claras y la responsabilidad compartida

• Centrarse en ofrecer valor empresarial

• Mantenerse ágil, en espera de un cambio

• Invertir en la calidad

• Aprender de todas las experiencias




Modelos

Los modelos describen esquemas a seguir para la organización de los equipos y los

procesos del proyecto, y especifica un modelo para el equipo de trabajo y uno para

los procesos:

a) Equipo de trabajo: Este modelo

se encarga de organizar las personas

para que realicen el trabajo y se

asegura que todas las metas del

proyecto se cumplan.

Define los principios, los roles y las

actividades involucrando al equipo

en todas las decisiones

fundamentales que rodean el

proyecto.




Modelos

b) Proceso: Se encarga de organizar los procesos necesarios para lograr llevar a

término una solución.

Para esto se divide las tareas del proyecto en cinco fases, las cuales proporcionan

herramientas para mejorar el control sobre el proyecto, minimizar el riesgo y

aumentar la calidad del producto.

Al igual que el proceso RUP, MSF también

tiene sus prácticas inherentes al desarrollo

de software, tales como la especificación,

el desarrollo, la validación y la evolución

del software.




Fase planificación: Se debe tener la ingeniería de requerimientos, planificación y

gestión de riesgos.

Fase desarrollo: En esta fase se codifica y se realizan las respectivas pruebas,

también se identifican y mitigan los riesgos existentes.

Fase estabilización: Se realizan pruebas beta, se crea un plan de gestión de

incidencias, se revisa la documentación final de la arquitectura y se elabora un

plan de despliegue.

Fase implantación: Se libera la solución software, se crea un registro de mejoras

y sugerencias, se revisan las guías y manuales de usuario y se entrega el proyecto

final.




Disciplinas

MSF presenta un conjunto de métodos para la gestión del proyecto, la gestión del

riesgo y la gestión de preparación para el cambio

o Gestión de proyecto: Permitir mayor escalabilidad en proyectos pequeños,

grandes y complejos, basado en la planificación sobre las entregas cortas, la

incorporación de nuevas características sucesivamente, e identificar cambios

ajustando el cronograma.

o Gestión del riesgo: Ayuda al equipo a tomar las decisiones correctas y controlar

las emergencias que puedan presentarse, por medio de un entorno estructurado

para la toma de decisiones y acciones, valorando los riesgos que puedan provocar.

o Gestión de cambios: Lograr que el equipo sea proactivo en lugar de reactivo,

teniendo en cuenta que los cambios deben considerase riesgos y por lo tanto se

deben registrar y hacer evidentes.




En conclusión, la metodología propuesta por MSF tiene como propósito:

Lograr entregas con un margen amplio de éxito, basados en la calidad del producto

software, teniendo presente las necesidades del cliente y el principio de

flexibilidad, así como el cumplimiento con los compromisos adquiridos, la gestión de

los costos y la minimización de los riesgos inherentes en todo proyecto de desarrollo

de software.



XP (EXTREME PROGRAMMING )

La programación extrema es una metodología de desarrollo ligero (o ágil) basada

en una serie de valores y de prácticas de buenas maneras que persigue el objetivo

de aumentar la productividad a la hora de desarrollar programas.

Este modelo da prioridad a los trabajos que dan un resultado directo y que

reducen la burocracia que hay alrededor de la programación.




Una de las características principales de este método de programación, es que sus

ingredientes son conocidos desde el principio de la informática. Los autores de XP

han seleccionado aquellos que han considerado mejores y han profundizado en sus

relaciones y en cómo se refuerzan los unos con los otros.

El resultado de esta selección ha sido esta metodología única y compacta. Por

esto, aunque no está basada en principios nuevos, sí que el resultado es una nueva

manera de ver el desarrollo de software.

El objetivo que se perseguía en el momento de crear esta metodología era la

búsqueda de un método que hiciera que los desarrollos fueran más sencillos

aplicando el sentido común.




La programación extrema se diferencia de las metodologías tradicionales

principalmente en que pone más énfasis en la adaptabilidad que en la

previsibilidad.

Los defensores de XP consideran que los cambios de requisitos sobre la marcha son

un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos.

Creen que ser capaz de adaptarse a los

cambios de requisitos en cualquier punto de

la vida del proyecto es una aproximación

mejor y más realista que intentar definir

todos los requisitos al comienzo del proyecto

e invertir esfuerzos después en controlar los

cambios en los requisitos.



XP (EXTREME PROGRAMMING ) -Prácticas

Equipo completo: Forman parte del equipo todas las personas que tienen algo

que ver con el proyecto, incluido el cliente y el responsable del proyecto.

Planificación: Se hacen las historias de usuario y se planifica en qué orden se van

a hacer y las mini-versiones. La planificación se revisa continuamente.

Test del cliente: El cliente, con la ayuda de los desarrolladores, propone sus

propias pruebas para validar las mini-versiones.

Versiones pequeñas: Las mini-versiones deben ser lo suficientemente pequeñas

como para poder hacer una cada pocas semanas. Deben ser versiones que

ofrezcan algo útil al usuario final y no trozos de código que no funcionen.

Diseño simple: Hacer siempre lo mínimo imprescindible de la forma más sencilla

posible. Mantener siempre sencillo el código.

Pareja de programadores: Los programadores trabajan por parejas (dos delante

del mismo ordenador) y se intercambian las parejas con frecuencia (un cambio

diario).




Desarrollo guiado por las pruebas automáticas: Se deben realizar pruebas

automáticas con mucha frecuencia. Cuantas más pruebas se hagan, mejor.

Integración continua: Deben tenerse siempre un ejecutable del proyecto que

funcione y en cuanto se tenga una nueva pequeña funcionalidad, debe

recompilarse y probarse.

El código es de todos: Cualquiera puede y debe tocar y conocer cualquier parte

del código. Para eso se hacen las pruebas automáticas.

Normas de codificación: Debe haber un estilo común de codificación, de forma

que parezca que ha sido realizado por una única persona.

Metáforas: Hay que buscar unas frases o nombres que definan cómo funcionan las

distintas partes del programa, de forma que sólo con los nombres se pueda uno

hacer una idea de qué es lo que hace cada parte del programa.

Ritmo sostenible: Se debe trabajar a un ritmo que se pueda mantener

indefinidamente. Esto quiere decir que no debe haber días muertos en que no se

sabe qué hacer y que no se deben hacer un exceso de horas otros días.



XP (EXTREME PROGRAMMING ) –Proceso

Se desarrolla en 4 fases

Fase de planeación: Inicia con las historias de usuario que describen las

características/funcionalidades del software. El cliente asigna un valor o

prioridad a la historia; se evalúa cada historia y le asignan un costo que se mide

en semanas de desarrollo.

Fase de diseño: Con diseños simples y sencillos para facilitar el desarrollo. Se

recomienda la correcta especificación de métodos y clases para facilitar

modificaciones, ampliaciones o reutilización de código.

Fase de codificación: Se deben diseñar las pruebas de unidad que ejercitarán

cada historia de usuario. Después de tener las pruebas, los desarrolladores

trabajarán en parejas en lo que debe implementarse.

Fase de pruebas: Las pruebas de unidad deben implementarse con un marco de

trabajo que permita automatizarlas, con la finalidad de realizar pruebas de

integración y validación diarias.



XP (EXTREME PROGRAMMING ) –Proceso



Diferencias RUP y XP



SCRUM

Scrum es un marco de trabajo para la gestión y desarrollo de software basada en

un proceso iterativo e incremental utilizado comúnmente en entornos basados en

el desarrollo ágil de software.

Puede ser utilizado en equipos de mantenimiento de software, o en una

aproximación de gestión de programas: Scrum de Scrums.

Scrum es una metodología de desarrollo muy

simple, que requiere trabajo duro porque no se

basa en el seguimiento de un plan, sino en la

adaptación continua a las circunstancias de la

evolución del proyecto

• Es un modo de desarrollo de carácter adaptable más que predictivo.

• Orientado a las personas más que a los procesos.

• Emplea estructura de desarrollo ágil: incremental basada en iteraciones y

revisiones



SCRUM

Se comienza con la visión general del producto, especificando y dando detalle a las

funcionalidades o partes que tienen mayor prioridad de desarrollo y que pueden

llevarse a cabo en un periodo de tiempo breve (normalmente de 30 días).

Cada uno de estos periodos de desarrollo es una iteración que finaliza con la

producción de un incremento operativo del producto.

Estas iteraciones son la base del desarrollo ágil,

y Scrum gestiona su evolución a través de

reuniones breves diarias en las que todo el

equipo revisa el trabajo realizado el día anterior

y el previsto para el día siguiente.



SCRUM – Control de evolución del proyecto

Scrum controla empírica y adaptablemente la evolución del proyecto usando:

Revisión de las Iteraciones: Al fin de cada iteración se lleva a cabo una revisión

con todas las personas implicadas en el proyecto.

Desarrollo incremental: El desarrollo incremental implica que al final de cada

iteración se usa una parte del producto que se puede inspeccionar y evaluar.

Desarrollo evolutivo: Los modelos ágiles se emplean para trabajar en entornos de

incertidumbre e inestabilidad de requisitos. Intentar predecir en las fases iniciales

cómo será el producto final no es realista.

Auto-organización: En Scrum los equipos son auto-organizados (no auto-dirigidos),

con decisión suficiente para tomar las acciones que consideren oportunas.

Colaboración: El entorno de trabajo ágiles facilitan la colaboración del equipo.



SCRUM – Visión general del proceso

Scrum denomina “sprint” a cada iteración de desarrollo y recomienda realizarlas

con duraciones de 30 días. El sprint es por tanto el núcleo central que proporciona

la base de desarrollo iterativo e incremental.

Los elementos que conforman el desarrollo Scrum son:

Las reuniones

• Planificación de sprint: Previa al inicio de cada

sprint en la que se determina cuál va a ser el

trabajo y los objetivos que se deben cumplir

en esa iteración.

• Reunión diaria: Breve revisión del equipo del

trabajo realizado hasta la fecha y la previsión

para el día siguiente.

• Revisión de sprint: Análisis y revisión del

incremento generado.



SCRUM



SCRUM - Valores

Scrum es una ayuda para organizar a las personas y el flujo de trabajo; como lo

pueden ser otras propuestas de formas de trabajo ágil.

• Delegación de atribuciones (empowerment) al equipo para que pueda auto-

organizarse y tomar las decisiones sobre el desarrollo.

• Respeto entre las personas. Los miembros del equipo deben confiar entre ellos

y respetar sus conocimientos y capacidades.

• Responsabilidad y auto-disciplina (no disciplina impuesta).

• Trabajo centrado en el desarrollo de lo comprometido.

• Información, transparencia y visibilidad del desarrollo del proyecto.



SCRUM

4 1 personalizacion de metodologias

Education

Transcript of 4 1 personalizacion de metodologias