SlideShare una empresa de Scribd logo
Análisis y Sistemas
20/05/2015
Por: Yeltsin Aldair Torres Recinos
INSTITUTO PRIVADO TECNOLÒGICO SPENCER W. KIMBALL
Bachiller industrial y perito en computación.
5to computación
Análisis y sistemas
Prof.: Álvaro Martínez
Metodologías para el desarrollo del software.
Yeltsin Aldair Torres Recinos
Fecha de entrega: 20/05/2015
Análisis y Sistemas
20/05/2015
Por: Yeltsin Aldair Torres Recinos
Introducción
El presente el trabajo trata sobre la metodología para desarrollo del software que es Un
proceso de software detallado y completo suele denominarse “Metodología”, también sus
características y los tipos de metodologías.
Análisis y Sistemas
20/05/2015
Por: Yeltsin Aldair Torres Recinos
Índice vinculado
Metodologías para el desarrollo del software..................................................................................................... 1
METODOLOGÍAS ESTRUCTURADAS.....................................................................................................................................3
METODOLOGÍAS ORIENTADAS A OBJETOS........................................................................................................................3
METODOLOGÍAS TRADICIONALES........................................................................................................................................3
METODOLOGÍAS ÁGILES ........................................................................................................................................................4
CARACTERISTICAS DESEABLESDE UNA METODOLOGIADE UNA METODOLOGIA .......................................................4
EVOLUCION ......................................................................................................................................................... 4
Los tipos de metodologías para el desarrollo del software son:......................................................................... 6
Ciclo de vida del software.....................................................................................................................................................6
Modelos de ciclo de vida .......................................................................................................................................................7
Modelo V .................................................................................................................................................... 7
Modelo en cascada..................................................................................................................................... 8
Modelo espiral............................................................................................................................................ 8
Método espiral .................................................................................................................................................... 9
METODOLOGÍA RUP.............................................................................................................................................................. 10
Principales características .................................................................................................................................................. 10
CICLO DE VIDA.........................................................................................................................................................................11
Fases del ciclo de vida del RUP:..........................................................................................................................................11
Disciplina de soporte RUP....................................................................................................................................................13
Elementos del RUP................................................................................................................................................................13
Artefactos................................................................................................................................................................................13
METODOLOGÍA SCRUM ...................................................................................................................................... 15
Características....................................................................................................................................................................... 15
METODOLOGIA XP ............................................................................................................................................. 17
Entendimiento........................................................................................................................................................................17
1. Interacción con el cliente............................................................................................................................... 19
2. Planificación del proyecto………………………………………………………………………………………………………………………………19
3.Diseño, desarrollo y pruebas …………………………………………………………..…………………………………………………..……20
Análisis y Sistemas
20/05/2015
1 Por: Yeltsin Aldair Torres Recinos
Metodologías para el desarrollo del software.
Un proceso de software detallado y completo suele denominarse “Metodología”. Las
metodologías se basan en una combinación de los modelos de proceso genéricos (cascada,
evolutivo, incremental, espiral entre otros). Adicionalmente una metodología debería definir
con precisión los artefactos, roles y actividades involucrados, junto con prácticas y técnicas
recomendadas, guías de adaptación de la metodología al proyecto, guías para uso de
herramientas de apoyo, etc. Habitualmente se utiliza el término “método” para referirse a
técnicas, notaciones y guías asociadas, que son aplicables a una (o algunas) actividades del
proceso de desarrollo, por ejemplo, suele hablarse de métodos de análisis y/o diseño.
La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la
diversidad de propuestas y diferencias en el grado de detalle, información disponible y
alcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las notaciones
utilizadas para especificar artefactos producidos en actividades de análisis y diseño,
podemos clasificar las metodologías en dos grupos: Metodologías Estructuradas y
Metodologías Orientadas a Objetos. Por otra parte, considerando su filosofía de desarrollo,
aquellas metodologías con mayor énfasis en la planificación y control del proyecto, en
especificación precisa de requisitos y modelado, reciben el apelativo de Metodologías
Tradicionales (o también denominadas Metodologías Pesadas, o Peso Pesado). Otras
metodologías, denominadas Metodologías Ágiles, están más orientadas a la generación de
código con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeños,
hacen especial hincapié en aspectos humanos asociados al trabajo en equipo e involucran
activamente al cliente en el proceso.
Se describe como el conjunto de herramientas, técnicas, procedimientos y soporte
documental para el diseño de Sistemas de información.
En Ingeniería de software cuando se habla de desarrollo de software se habla de desarrollo
de programas y por lo tanto se considera como una tarea de ingeniería, en el cuál se debe
ejecutar una serie de fases, etapas para obtener un programa que funcione de acuerdo con
métodos ya establecidos en otras disciplinas de ingeniería. Las actividades que los
ingenieros de software realizan se encuentran asociadas a un proceso de software donde
intervienen diferentes elementos (fases, actividades, producto, roles, agentes) que
permiten la definición del software a producir (producto), el desarrollo o el diseño del
software, la validación del software tanto lo interno (requerimientos específicos) como lo
externo (expectativas del cliente), y la evolución del software donde se modifica para
adaptarlo a los cambios.
Por otro lado, Sommerville (2002) define que “un método de ingeniería de software es un
enfoque estructurado para el desarrollo de software cuyo propósito es facilitar la
producción de software de alta calidad de una forma costeable”, cabe destacar que para
usar este enfoque se debe manejar conceptos fundamentales tales como; procesos,
métodos, tareas, procedimientos, técnicas, herramientas, productos, entre otros.
Particularmente, una metodología se basa en una combinación de los modelos de proceso
genéricos para obtener como beneficio un software que soluciones un problema.
Análisis y Sistemas
20/05/2015
2 Por: Yeltsin Aldair Torres Recinos
Adicionalmente una metodología debería definir con precisión los artefactos, roles y
actividades, junto con prácticas, técnicas recomendadas y guías de adaptación de la
metodología al proyecto. Sin embargo, la complejidad del proceso de creación de software
es netamente dependiente de la naturaleza del proyecto mismo, por lo que el escogimiento
de la metodología estará acorde al nivel de aporte del proyecto, ya sea pequeño, mediano o
de gran nivel.
Análisis y Sistemas
20/05/2015
3 Por: Yeltsin Aldair Torres Recinos
A continuación se revisan brevemente cada una de estas categorías de metodologías:
METODOLOGÍAS ESTRUCTURADAS
Los métodos estructurados comenzaron a desarrollarse a fines de los 70’s con la
Programación Estructurada, luego a mediados de los 70’s aparecieron técnicas para el
Diseño (por ejemplo: el diagrama de Estructura) primero y posteriormente para el Análisis
(por ejemplo: 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 estructuradas de ámbito gubernamental: MERISE (Francia),
MÉTRICA (España), SSADM (Reino Unido). Ejemplos de propuestas de métodos
estructurados en el ámbito académico: Gane & Sarson, Ward & Mellor, Yourdon & DeMarco
e Information Engineering.
METODOLOGÍAS ORIENTADAS A OBJETOS
Su historia va unida a la evolución de los lenguajes de programación orientada a objeto, los
más representativos: a fines de los 60’s SIMULA, a fines de los 70’s Smalltalk-80, la primera
versión de C++ por Bjarne Stroustrup en 1981 y actualmente Java o C# de Microsoft. A fines
de los 80’s comenzaron a consolidarse algunos métodos Orientadas a Objeto.
En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de
conseguir una unificación de sus métodos y notaciones, que posteriormente se reorienta a
un objetivo más modesto, para dar lugar al Unified Modeling Language (UML), la notación
Orientada a Objetos más popular en la actualidad.
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
Las metodologías no ágiles son aquellas que están guiadas por una fuerte planificación
durante todo el proceso de desarrollo; llamadas también metodologías tradicionales o
clásicas, donde 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. Aunque en el caso particular de RUP, por el especial énfasis que
presenta en cuanto a su adaptación a las condiciones del proyecto (mediante su
configuración previa a aplicarse), realizando una configuración adecuada, podría
considerarse Ágil.
Análisis y Sistemas
20/05/2015
4 Por: Yeltsin Aldair Torres Recinos
METODOLOGÍAS ÁGILES
Un proceso es ágil cuando el desarrollo de software es incremental (entregas pequeñas de
software, con ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntos
constantemente con una cercana comunicación), sencillo (el método en sí mismo es fácil de
aprender y modificar, bien documentado), y adaptable (permite realizar cambios de último
momento).
Entre las metodologías ágiles identificadas son:
 Extreme Programming
 Scrum
 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
CARACTERISTICAS DESEABLESDE UNA METODOLOGIADE UNA METODOLOGIA
 Existencia de reglas predefinidas
 Cobertura total del ciclo de desarrollo
 Verificaciones intermedias
 Planificación y control
 Comunicación efectiva
 Utilización sobre un abanico amplio de proyectos
 Fácil formación
 Herramientas CASE
 Actividades que mejoren el proceso de desarrollo
 Soporte al mantenimiento
 Soporte de la reutilización de software
EVOLUCION
Desde que se empezó a trabajar sobre el desarrollo de programas, se siguieron ciertos
métodos que permitían llevar a producir un buen proyecto, estas metodologías aplicadas
eran simples, solo se preocupaban por los procesos mas no por los datos, por lo tanto los
métodos eran desarrollados hacia los procesos. El modelo de procesos predominaba para
los años 60 y consistía en codificar y corregir (Code-and-Fix), si al terminar se descubría que
el diseño era incorrecto, la solución era desecharlo y volver a empezar 3
, este modelo
implementaba el código y luego se pensaba en los requisitos, diseño, validación y
mantenimiento. Los principales problemas del modelo de procesos son:
 Los arreglos se hacen costosos, después de tantas correcciones el código tenía una
mala estructura.
Análisis y Sistemas
20/05/2015
5 Por: Yeltsin Aldair Torres Recinos
 El software no se ajusta a las necesidades del usuario, por lo que es rechazado o su
reconstrucción es muy cara.
 El código es difícil de reparar por su pobre preparación para probar y modificar.
En la década de los setenta empezó a tomar la importancia de los datos, y para solucionar
sistemas complejos empezó el análisis por partes o etapas, se introducen la planeación y
administración. El modelo en cascada surge como respuesta al modelo de procesos, este
modelo tiene más disciplina y se basa en el análisis, diseño, pruebas y mantenimientos.
La década de los ochenta es la época marcada por las metodologías dirigida a datos cuya
importancia va tomando cuerpo en las organizaciones. Se empiezan a estudiar los objetos
en sí como unidades de información. Para los años 90 se quiere dar respuesta al entorno
siempre cambiante y en rápida evolución en que se han de desarrollar los programas
informáticos, lo cual da lugar a trabajar en ciclos cortos (como mini-proyectos) que
implementan una parte de las funcionalidades, pero sin perder el rumbo general del
proyecto global.
Por otra parte las metodologías de desarrollo comienzan a interesarse no sólo en lograr
que el proyecto sea puesto en funcionamiento sino en minimizar costos durante su
desarrollo y sobre todo durante su mantenimiento. Los nuevos métodos van buscando
minimizar riesgos y, puesto que los errores más perjudiciales se producen en los primeros
pasos, se comienza ya desde la fase más general del estudio por analizar los riesgos que
significa seguir con las siguientes fases del desarrollo.
Las metodologías más utilizadas a nivel mundial en orden cronológico:
 Década de los 70s
 Programación Estructurada Jackson desde 1975
Década de los 80s
 Structured Systems Analysis and Design Methodology (SSADM) desde 1980
 Structured Analysis and Design Technique (SADT) desde 1980
 Ingeniería de la Información (IE/IEM) desde 1981
Década de los 90s
 Rapid Application Development (RAD) desde 1991
 Programación Orientada a Objetos (OOP) a lo largo de la década de los 90's
 Virtual Finite State Machine (VFSM) desde 1990s
 Dynamic Systems Development Method desarrollado en UK desde 1995.
 Rational Unified Process (RUP) desde 1999
Año 2000 en adelante
 Extreme Programming (XP) desde 1999
 Enterprise Unified Process (EUP) extensiones RUP desde 2002
 Constructionist Design Methodology (CDM) desde 2004 por Kristinn R. Thórisson
 Agile Unified Process (AUP) desde 2005 por Scott Ambler
Análisis y Sistemas
20/05/2015
6 Por: Yeltsin Aldair Torres Recinos
Los tipos de metodologías para el desarrollo del software son:
 CICLO DE VIDA
El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado
ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las
tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en
número variable según el proyecto y en las que se hace un mayor o menor hincapié en las
distintas actividades. En la Figura muestra cómo varía el esfuerzo asociado a las disciplinas
según la fase en la que se encuentre el proyecto RUP.
Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la
comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la
eliminación de los riesgos críticos, y al establecimiento de una baseline (Línea Base) de la
arquitectura. Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de
modelado del negocio y de requisitos.
En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la
arquitectura, abarcan más los flujos de trabajo de requisitos, modelo de negocios
(refinamiento), análisis, diseño y una parte de implementación orientado a la baseline de la
arquitectura. En la fase de construcción, se lleva a cabo la construcción del producto por
medio de una serie de iteraciones. Para cada iteración se seleccionan algunos Casos de Uso,
se refinan su análisis y diseño y se procede a su implementación y pruebas. Se realiza una
pequeña cascada para cada ciclo. Se realizan iteraciones hasta que se termine la
implementación de la nueva versión del producto. En la fase de transición se pretende
garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios.
Como se puede observar en cada fase participan todas las disciplinas, pero dependiendo de
la fase el esfuerzo dedicado a una disciplina varía.
Ciclo de vida del software
El termino ciclo de vida del software describe el desarrollo de software desde la fase inicial
hasta la fase final. El propósito de este programa es definir las distintas fases intermedias
que se requieren para validar el desarrollo de la aplicación.
El ciclo de vida básico de un software consta de los siguientes requerimientos:
 Definición de objetos: define el resultado del proyecto y su papel en la estrategia
global.
 Análisis de los requisitos y su viabilidad: Recopilar, examinar y formular los requisitos
del cliente y examinar cualquier descripción que se pueda aplicar.
 Diseño general: Requisitos generales de la arquitectura de la aplicación.
Análisis y Sistemas
20/05/2015
7 Por: Yeltsin Aldair Torres Recinos
 Diseño en detalle: Definición precisa de cada subconjunto de la aplicación.
 Programación: Implementación de un lenguaje de programación para crear las
funciones definidas durante la etapa de diseño.
 Prueba de unidad: Prueba individual de cada subconjunto de la aplicación para
garantizar que se implementara de acuerdo con las especificaciones.
 Integración: Para garantizar los diferentes módulos se integren con la aplicación.
 Prueba beta o validación: Para garantizar que el software cumple con las
especificaciones originales.
 Documentación: Sirve para documentar información necesaria para los usuarios del
software y para desarrollos futuros.
 Implementación: Poner en producción.
 Mantenimiento: Para todos los procedimientos correctivos y las actualizaciones
secundarias del software (Mantenimiento continuo).
Modelos de ciclo de vida
Para facilitar una metodología común entre el cliente y la compañía de software, los
modelos de ciclo de vida se han actualizado para reflejar las etapas de desarrollo
involucradas, y la documentación requerida, de manera que cada etapa se valide antes de
continuar con la siguiente etapa.
Modelo V
El modelo de ciclo de vida V proviene del principio que establece que los procedimientos
utilizados para probar si la aplicación cumple las especificaciones ya deben haberse creado
en la fase de diseño.
Análisis y Sistemas
20/05/2015
8 Por: Yeltsin Aldair Torres Recinos
Modelo en cascada
El modelo de ciclo de vida en cascada comenzó a diseñarse en 1966 y termina alrededor de
1970. Se define como una secuencia de fases en la etapa final de cada una de ellas se reúne
la documentación para garantizar que cumple con las especificaciones y los requisitos antes
de pasar a la siguiente fase
Modelo espiral
El modelo espiral fue propuesto inicialmente por Barry Boehm. Es un modelo evolutivo que
conjuga la naturaleza iterativa del modelo MCP con los aspectos controlados y sistemáticos
del Modelo Cascada. Proporciona potencial para desarrollo rápido de versiones
incrementales. En el modelo Espiral el software se construye en una serie de versiones
incrementales. En las primeras iteraciones la versión incremental podría ser un modelo en
papel o bien un prototipo. En las últimas iteraciones se producen versiones cada vez más
completas del sistema diseñado.
Análisis y Sistemas
20/05/2015
9 Por: Yeltsin Aldair Torres Recinos
Método espiral
DESARROLLO EN ESPIRAL
Éste es un tipo de desarrollo evolutivo, las versiones de cada etapa van evolucionando,
madurando de acuerdo a cada iteración que se haga cabe recalcar que en cada iteración se
desarrollará todas las etapas en orden.
CARACTERÍSTICAS:
-Es ideal para crear productos con diferentes versiones mejoradas como se hace con el
software moderno de microcomputadoras.
- puede desarrollarse a través del ciclo de vida clásico o el de construcción de prototipos.
COMUNICACIÓN CON EL CLIENTE:
Aquí establecemos los requerimientos y objetivos que se quieren del sistema.
PLANIFICACIÓN
Seguidamente debemos estructurar nuestro trabajo, planificar tiempo, establecer metas,
etc.
ANÁLISIS DE RIESGOS
Se debe identificar los riesgos relacionados con el proyecto, todas aquellas eventualidades
que pueden ocurrir, y tratar de que estos riesgos no se den o en el caso de que lleguen a
pasar establecer acciones para resolverlas.
INGENIERÍA
Las tarea necesarias para construir la aplicación (la representación del sistema y
debidamente estructurada).
CONSTRUCCIÓN Y ADAPTACIÓN
Luego se debe construir el software, realizar las pruebas correspondientes y brindar
soporte al usuario.
EVALUACIÓN DEL CLIENTE
El cliente es quien debe dar la conformidad del avance y si el resultado del trabajo cumple
con las expectativas del usuario.
VENTAJAS
A medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan
mejor ante riesgos en cada uno de los niveles.
-Reduce los riesgos antes de que se conviertan en problemáticos.
Análisis y Sistemas
20/05/2015
10 Por: Yeltsin Aldair Torres Recinos
METODOLOGÍA RUP
Es una metodología cuyo fin es entregar un producto de software. Se estructura todos los
procesos y se mide la eficiencia de la organización.
Es un proceso de desarrollo de software el cual utiliza 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 es un conjunto de metodologías adaptables al contexto y necesidades de cada
organización.
Describe cómo aplicar enfoques para el desarrollo del software, llevando a cabo unos pasos
para su realización.
Se centra en la producción y mantenimiento de modelos del sistema.
Principales características
 Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y
cómo)
 Pretende implementar las mejores prácticas en Ingeniería de Software
 Desarrollo iterativo
 Administración de requisitos
 Uso de arquitectura basada en componentes
 Control de cambios
 Modelado visual del software
 Verificación de la calidad del software
Análisis y Sistemas
20/05/2015
11 Por: Yeltsin Aldair Torres Recinos
El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar
centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los
productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código
fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una
persona puede desempeñar distintos roles a lo largo del proceso).
CICLO DE VIDA
Esfuerzo en actividades según fase del proyecto
El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado
ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las
tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en
número variable según el proyecto y en las que se hace un mayor o menor hincapié en las
distintas actividades.
Fases del ciclo de vida del RUP:
1. Fase de 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.
2. Fase de 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
Análisis y Sistemas
20/05/2015
12 Por: Yeltsin Aldair Torres Recinos
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.
3. Fase de Desarrollo: El propósito de esta fase es completar la funcionalidad del sistema,
para ello se deben clarificar los requerimientos pendientes, administrar los cambios de
acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el
proyecto.
4. Fase de Cierre: 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.
La metodología RUP tiene 6 principios clave:
1. Adaptación del proceso: El proceso debe adaptarse a las características de la
organización para la que se está desarrollando el software.
2. Balancear prioridades: Debe encontrarse un balance que satisfaga a todos los inversores
del proyecto.
3. Colaboración entre equipos: Debe haber una comunicación fluida para coordinar
requerimientos, desarrollo, evaluaciones, planes, resultados, entre otros.
4. Demostrar valor iterativamente: Los proyectos se entregan, aunque sea de una forma
interna, en etapas iteradas. En cada iteración se evaluará la calidad y estabilidad del
producto y analizará la opinión y sugerencias de los inversores.
Análisis y Sistemas
20/05/2015
13 Por: Yeltsin Aldair Torres Recinos
5. Elevar el nivel de abstracción: Motivar el uso de de conceptos reutilizables.
6. Enfocarse en la calidad: La calidad del producto debe verificarse en cada aspecto de la
producción.
Disciplina de desarrollo de RUP
Determina las etapas a realizar durante el proyecto de creación del software.
 Ingeniería o modelado del negocio: Analizar y entender las necesidades del negocio
para el cual se está desarrollando el software.
 Requisitos: Proveer una base para estimar los costos y tiempo de desarrollo del
sistema.
 Análisis y diseño: Trasladar los requisitos analizados anteriormente a un sistema
automatizado y desarrollar una arquitectura para el sistema.
 Implementación: Crear software que se ajuste a la arquitectura diseñada y que tenga
el comportamiento deseado.
 Pruebas: Asegurarse de que el comportamiento requerido es correcto y que todo lo
solicitado está presente.
 Despliegue: Producir distribuciones del producto y distribuirlo a los usuarios.
Disciplina de soporte RUP
Determina la documentación que es necesaria realizar durante el proyecto.
 Configuración y administración del cambio: Guardar todas las versiones del proyecto.
 Administración del proyecto: Administrar los horarios y recursos que se deben de
emplear.
 Ambiente: Administrar el ambiente de desarrollo del software.
 Distribución: Hacer todo lo necesario para la salida del proyecto.
Elementos del RUP
 Actividades: Procesos que se han de realizar en cada etapa/iteración.
 Trabajadores: Personas involucradas en cada actividad del proyecto.
 Artefactos: Herramientas empleadas para el desarrollo del proyecto. Puede ser un
documento, un modelo, un elemento del modelo.
Artefactos
RUP en cada una de sus fases (pertenecientes a la estructura estática) realiza una serie de
artefactos que sirven para comprender mejor tanto el análisis como el diseño del sistema
(entre otros). Estos artefactos (entre otros) son los siguientes:
Análisis y Sistemas
20/05/2015
14 Por: Yeltsin Aldair Torres Recinos
Inicio:
 Documento Visión
 Especificación de Requerimientos
Elaboración:
 Diagramas de caso de uso
Construcción:
 Documento Arquitectura que trabaja con las siguientes vistas:
VISTA LOGICA:
 Diagrama de clases
 Modelo E-R (Si el sistema así lo requiere)
VISTA DE IMPLEMENTACION:
 Diagrama de Secuencia
 Diagrama de estados
 Diagrama de Colaboración
VISTA CONCEPTUAL
 Modelo de dominio
VISTA FISICA
 Mapa de comportamiento a nivel de har
Análisis y Sistemas
20/05/2015
15 Por: Yeltsin Aldair Torres Recinos
METODOLOGÍA SCRUM
Scrum es una metodología ágil de desarrollo, aunque surgió como modelo para el
desarrollo de productos tecnológicos, también se emplea en entornos que trabajan con
requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el
desarrollo de determinados sistemas de software.
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.
Scrum es una metodología ágil, y como tal:
 Es un modo de desarrollo de carácter adaptable más que predictivo.
 Orientado a las personas más que a los procesos.
 Emplea la estructura de desarrollo ágil: incremental basada en iteraciones y
revisiones.
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.
Estructura central de Scrum
Características
 Equipos auto dirigidos
 Utiliza reglas para crear un entorno ágil de administración de proyectos
 No prescribe prácticas específicas de ingeniería
 Los requerimientos se capturan como ítems de la lista Product Backlog.
 El producto se construye en una serie de Sprints de un mes de duración.
Análisis y Sistemas
20/05/2015
16 Por: Yeltsin Aldair Torres Recinos
Herramientas y Prácticas
Scrum no requiere ni provee prácticas de Ingeniería. En lugar de eso, especifica prácticas y
herramientas de gerencia que se aplican en sus distintas fases para evitar el caos originado
por la complejidad e imposibilidad de realizar predicciones.
Product Backlog List
Es una lista priorizada que define el trabajo que se va a realizar en el proyecto. Cuando un
proyecto comienza es muy difícil tener claro todos los requerimientos sobre el producto. Sin
embargo, suelen surgir los más importantes que casi siempre son más que suficientes para
un Sprint.
El objetivo es asegurar que el producto definido al terminar la lista es el más correcto, útil y
competitivo posible y para esto la lista debe acompañar los cambios en el entorno y el
producto.
Existe un rol asociado con esta lista y es el de Product Owner. Si alguien quiere realizar
cualquier modificación sobre la lista por ejemplo: agregar o incrementar la prioridad de sus
elementos tiene que convencer al Product Owner.
Sprints
Un Sprint es el procedimiento de adaptación de las cambiantes variables del entorno
(requerimientos, tiempo, recursos, conocimiento, tecnología). Son ciclos iterativos en los
cuales se desarrolla o mejora una funcionalidad para producir nuevos incrementos. Durante
un Sprint el producto es diseñado, codificado y probado. Y su arquitectura y diseño
evolucionan durante el desarrollo.
El objetivo de un Sprint debe ser expresado en pocas palabras para que sea fácil de recordar
y esté siempre presente en el equipo.
Burn down Chart
La burn down chart es una gráfica mostrada públicamente que mide la cantidad de
requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una
línea que conecte los puntos de todos los Sprints completados, podremos ver el progreso
del proyecto. Lo normal es que esta línea sea descendente (en casos en que todo va bien en
el sentido de que los requisitos están bien definidos desde el principio y no varían nunca)
hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay más
requisitos pendientes de ser completados en el Backlog). Si durante el proceso se añaden
nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos, y si
se modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos
tramos.
Sprint Backlog
Es el punto de entrada de cada Sprint. Es una lista que tiene los ítems de la Product Backlog
List que van a ser implementados en el siguiente Sprint.
Análisis y Sistemas
20/05/2015
17 Por: Yeltsin Aldair Torres Recinos
Los ítems son seleccionados por el Scrum Team, el Scrum Master y el Product Owner en la
Sprint Planning Meeting a partir de la priorización de los ítems y los objetivos que se
marcaron para ese Sprint. A partir de los objetivos a cumplir durante el Sprint el Scrum
Team determina que tareas debe desempeñar para cumplir el objetivo. De esto surge el
Sprint Backlog.
Stabilization Sprints
En estos Sprints el equipo se concentra en encontrar defectos, no en agregar funcionalidad.
Suelen aplicarse cuando se prepara un producto para el release. Son útiles cuando se están
realizando pruebas beta, se está introduciendo a un equipo en la metodología de Scrum o
cuando la calidad de un producto no alcanza los límites esperados.
No fueron definidos por Scrum pero han sido recomendados por su utilidad al aplicar esta
metodología.
Scrum of Scrums o MetaScrum
Los equipos de Scrum suelen tener entre 5 y 10 personas, sin embargo está metodología
ha sido aplicada en proyectos que involucran más de 600 personas. Esto ha sido llevado a
cabo dividiendo a los accionistas en equipos de pequeños de hasta 10 personas
aproximadamente. Y definiendo jerárquicamente personas que pertenecen a dos equipos,
es decir, además de su rol específico dentro de un equipo tienen el rol de enlace en un
equipo superior.
METODOLOGIA XP
Entregas pequeñas: colocan un sistema sencillo en producción rápidamente que se
actualiza de forma rápida y constante permitiendo que el verdadero valor de negocio del
producto sea evaluado en un ambiente real. Estas entregas no pueden pasar las 2 o 3
semanas como máximo.
Entendimiento
1. Diseño simple: se basa en la filosofía de que el mayor valor de negocio es entregado por
el programa más sencillo que cumpla los requerimientos. Simple Design se enfoca en
proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni más ni menos.
Este proceso permite eliminar redundancias y rejuvenecer los diseños obsoletos de forma
sencilla.
2. Metáfora: desarrollada por los programadores al inicio del proyecto, define una historia
de cómo funciona el sistema completo. XP estimula historias, que son breves descripciones
de un trabajo de un sistema en lugar de los tradicionales diagramas y modelos UML (Unified
Modeling Language). La metáfora expresa la visión evolutiva del proyecto que define el
alcance y propósito del sistema. Las tarjetas CRC (Clase, Responsabilidad y Colaboración)
también ayudarán al equipo a definir actividades durante el diseño del sistema. Cada tarjeta
Análisis y Sistemas
20/05/2015
18 Por: Yeltsin Aldair Torres Recinos
representa una clase en la programación orientada a objetos y define sus responsabilidades
(lo que ha de hacer) y las colaboraciones con las otras clases (cómo se comunica con ellas).
3. Propiedad colectiva del código: un código con propiedad compartida. Nadie es el
propietario de nada, todos son el propietario de todo. Este método difiere en mucho a los
métodos tradicionales en los que un simple programador posee un conjunto de código. Los
defensores de XP argumentan que mientras haya más gente trabajando en una pieza,
menos errores aparecerán.
4. Estándar de codificación: define la propiedad del código compartido así como las reglas
para escribir y documentar el código y la comunicación entre diferentes piezas de código
desarrolladas por diferentes equipos. Los programadores las han de seguir de tal manera
que el código en el sistema se vea como si hubiera estado escrito por una sola persona.
Bienestar del programador.
1. La semana de 40 horas: la programación extrema sostiene que los programadores
cansados escriben código de menor cualidad. Minimizar las horas extras y mantener los
programadores frescos, generará código de mayor calidad. Como dice Beck, está bien
trabajar tiempos extra cuando es necesario, pero no se ha de hacer durante dos semanas
seguidas.
PROCESO DE DESARROLLO
La programación extrema parte del caso habitual de una compañía que desarrolla software
normalmente a medida, en la que hay diferentes roles: un equipo de gestión (o diseño), uno
de desarrollo y los clientes finales. La relación entre el equipo de diseño, los que desarrollan
el software y clientes es totalmente diferente al que se ha producido en las metodologías
tradicionales, que se basaba en una fase de captura de los requisitos previa al desarrollo, y
de una fase de validación posterior al mismo.
Análisis y Sistemas
20/05/2015
19 Por: Yeltsin Aldair Torres Recinos
1. Interacción con el cliente.
En este tipo de programación el cliente pasa a ser parte implicada en el equipo de
desarrollo. Su importancia es máxima en el momento de tratar con los usuarios y en
efectuar las reuniones de planificación. Tiene un papel importante de interacción con el
equipo de programadores, sobre todo después de cada cambio, y de cada posible problema
localizado, mostrando las prioridades, expresando sus sensaciones... En este tipo de
programación existirán pruebas de aceptación de la programación que ayudarán a que su
labor sea lo más provechosa posible.
Al fin y al cabo, el cliente se encuentra mucho más cerca del proceso de desarrollo. Se
elimina la fase inicial de recopilación de requerimientos, y se permite que éstos se vayan
cogiendo a lo largo del proyecto, de una manera ordenada. De esta forma se posibilita que
el cliente pueda ir cambiando de opinión sobre la marcha, pero a cambio han de estar
siempre disponibles para solucionar las dudas del equipo de desarrollo.
En XP aparece un nuevo concepto llamado “Historia de usuario”. Se trata de una lista de
características que el cliente necesita que existan en el producto final. Estas constan de dos
fases:
o En la primera fase, el cliente describe con sus propias palabras las características y, es el
responsable del equipo, el encargado de informarlo de las dificultades técnicas de cada una
de ellas y de su coste. A consecuencia de este diálogo, el cliente deja por escrito un conjunto
de historias y las ordena en función de la prioridad que tiene para él. De esta manera ya es
posible definir unas fechas aproximadas para ellos.
En la segunda fase, el cliente cogerá las primeras historias a implementar y las dividirá en
trabajos a realizar. El cliente también participa, pero hay más peso por parte del equipo de
desarrolladores, esto dará como resultado una planificación más exacta. Este método se
repetirá para cada historia.
A diferencia de otras técnicas, como puede ser UML, en el caso de XP, se exige que sea el
cliente el encargado de escribir los documentos con las especificaciones de lo que
realmente quiere, como un documento de requisitos de usuario.
En esta fase, el equipo técnico será el 'encargado de catalogar las historias del cliente y
asignarles una duración. La norma es que cada historia de usuario tiene que poder ser
realizable en un espacio entre una y tres semanas de programación. Las que requieran
menos tiempo serán agrupadas, y las que necesiten más serán modificadas o divididas.
Finalmente decir que las historias de los usuarios serán escritas en tarjetas, lo que facilitará
que el cliente pueda especificar la importancia relativa entre las diferentes historias de
usuario, así como el trabajo de los programadores que podrán catalogarlas correctamente.
Este formato también es muy útil en el momento de las pruebas de aceptación.
2. PLANIFICACIÓN DEL PROYECTO
En este punto se tendrá que elaborar la planificación por etapas, donde se aplicarán
diferentes iteraciones. Para hacerlo será necesaria la existencia de reglas que se han de
seguir por las partes implicadas en el proyecto para que todas las partes tengan voz y se
sientan realmente partícipes de la decisión tomada.
Análisis y Sistemas
20/05/2015
20 Por: Yeltsin Aldair Torres Recinos
Las entregas se tienen que hacer cuanto antes mejor, y con cada iteración, el cliente ha de
recibir una nueva versión. Cuanto más tiempo se tarde en introducir una parte esencial,
menos tiempo se tendrá para trabajar con ella después. Se aconseja muchas entregas y
muy frecuentes. De esta manera un error en la parte inicial del sistema tiene más
posibilidades de detectarse rápidamente.
Una de las máximas a aplicar es, los cambios, no han de suponer más horas de
programación para el programador, ya que el que no se termina en un día, se deja para el
día siguiente.
Se ha de tener asumido que en el proceso de planificación habrán errores, es más, serán
comunes, y por esto esta metodología ya los tiene previstos, por lo tanto se establecerán
mecanismos de revisión. Cada tres o cinco iteraciones es normal revisar las historias de los
usuarios, y renegociar la planificación.
Cada iteración necesita también ser planificada, es lo que se llama planificación iterativa, en
la que se anotarán las historias de usuarios que se consideren esenciales y las que no han
pasado las pruebas de aceptación. Estas planificaciones también se harán en tarjetas, en las
que se escribirán los trabajos que durarán entre uno y tres días.
Es por esto que el diseño se puede clasificar como continuo. Añade agilidad al proceso de
desarrollo y evita que se mire demasiado hacia delante, desarrollando trabajos que aún no
han estado programados.
Este tipo de planificación en iteraciones y el diseño iterativo, hace que aparezca una práctica
que no existía en la programación tradicional. Se trata de las discusiones diarias informales,
para fomentar la comunicación, y para hacer que los desarrolladores tengan tiempo de
hablar de los problemas a los que se enfrentan y de ver cómo van con sus trabajos.
3. DISEÑO, DESARROLLO Y PRUEBAS
El desarrollo es la parte más importante en el proceso de la programación extrema. Todos
los trabajos tienen como objetivo que se programen lo más rápidamente posible, sin
interrupciones y en dirección correcta.
También es muy importante el diseño, y se establecen los mecanismos, para que éste sea
revisado y mejorado de manera continuada a lo largo del proyecto, según se van añadiendo
funcionalidades al mismo.
La clave del proceso de desarrollar XP es la comunicación. La mayoría de los problemas en
los proyectos son por falta de comunicación en el equipo.
En XP, aparece un nuevo concepto llamado Metáfora. Su principal objetivo es mejorar la
comunicación entre todos los integrantes del equipo, al crear una visión global y común de
lo que se quiere desarrollar. La metáfora tiene que ser expresada en términos conocidos
por los integrantes del equipo, por ejemplo comparando el sistema que se desarrollará con
alguna cosa de la vida real.
Análisis y Sistemas
20/05/2015
21 Por: Yeltsin Aldair Torres Recinos
Antes de empezar a codificar se tienen que hacer pruebas unitarias, es decir:
Cada vez que se quiere implementar una parte de código, en XP, se tiene que escribir una
prueba sencilla, y después escribir el código para que la pase. Una vez pasada se amplía y
se continúa. En XP hay una máxima que dice "Todo el código que puede fallar tiene que
tener una prueba".
Con estas normas se obtiene un código simple y funcional de manera bastante rápida. Por
esto es importante pasar las pruebas al 100%.
Respecto a la integración del soft, en XP se ha de hacer una integración continua, es decir,
cada vez se tienen que ir integrando pequeños fragmentos de código, para evitar que al
finalizar el proyecto se tenga que invertir grandes esfuerzos en la integración final. En todo
buen proyecto de XP, tendría que existir una versión al día integrada, de manera que los
cambios siempre se realicen en esta última versión.
Otra peculiaridad de XP es que cada programador puede trabajar en cualquier parte del
programa.
De esta manera se evita que haya partes "propietarias de cada programador". Por esto es
tan importante la integración diaria.
Para terminar, otra peculiaridad que tiene la XP. La de fomentar la programación en parejas,
es decir, hacer que los programadores no trabajen en solitario, sino que siempre estarán
con otra persona. Una pareja de programadores ha de compartir el teclado, el monitor y el
ratón. El principio fundamental de este hecho es realizar de manera continua y sin parar el
desarrollo de código. Las parejas tienen que ir cambiando de manera periódica, para hacer
que el conocimiento se difunda en el grupo. Está demostrado que de esta manera el trabajo
es más eficaz y también se consigue más y mejor código.
Análisis y Sistemas
20/05/2015
Por: Yeltsin Aldair Torres Recinos
Conclusiones
 Las metodologías se basan en una combinación de los modelos de proceso
genéricos (cascada, evolutivo, incremental, espiral entre otros).
 Los métodos estructurados comenzaron a desarrollarse a fines de los 70’s con la
Programación Estructurada, luego a mediados de los 70’s aparecieron técnicas para
el Diseño (por ejemplo: el diagrama de Estructura)
 El modelo espiral fue propuesto inicialmente por Barry Boehm. Es un modelo
evolutivo que conjuga la naturaleza iterativa del modelo MCP con los aspectos
controlados y sistemáticos del Modelo Cascada.
 Es una metodología RUP cuyo fin es entregar un producto de software. Se
estructura todos los procesos y se mide la eficiencia de la organización.
Análisis y Sistemas
20/05/2015
Por: Yeltsin Aldair Torres Recinos
E-grafía
 http://procesosdesoftware.wikispaces.com/METODOLOGIAS+PARA+DESARROLLO+
DE+SOFTWARE
 http://paradigmasiut.blogspot.com/2013/04/metodologia-de-desarrollo-de-
software.html
 http://html.rincondelvago.com/ciclo-de-vida-del-software.html
 http://procesosdesoftware.wikispaces.com/metodo+espiral
 http://procesosdesoftware.wikispaces.com/METODOLOGIA+RUP
 http://procesosdesoftware.wikispaces.com/METODOLOGIA+SCRUM
 http://procesosdesoftware.wikispaces.com/METODOLOGIA+XP

Más contenido relacionado

La actualidad más candente

Ciclo Vida del Software
Ciclo Vida del SoftwareCiclo Vida del Software
Ciclo Vida del Software
Wilfredo Mogollón
 
MODELO COCOMO (INGENIERA DE SOFTWARE)
MODELO COCOMO (INGENIERA DE SOFTWARE)MODELO COCOMO (INGENIERA DE SOFTWARE)
MODELO COCOMO (INGENIERA DE SOFTWARE)
Yadith Miranda Silva
 
Tecnicas de estimacion de software
Tecnicas de estimacion de softwareTecnicas de estimacion de software
Tecnicas de estimacion de software
Ades27
 
Modelo evolutivo
Modelo evolutivoModelo evolutivo
Modelo evolutivo
Barklyn Lsla
 
Metodologías de Desarrollo de Software Tradicionales y Emergentes
Metodologías de Desarrollo de Software Tradicionales y EmergentesMetodologías de Desarrollo de Software Tradicionales y Emergentes
Metodologías de Desarrollo de Software Tradicionales y Emergentes
Miguel Rodríguez
 
Metodologia rup
Metodologia rupMetodologia rup
Metodologia rup
mireya2022
 
Metodologías, metricas y modelo cocomo para el costo de un proyecto software
Metodologías, metricas y modelo cocomo para el costo de un proyecto softwareMetodologías, metricas y modelo cocomo para el costo de un proyecto software
Metodologías, metricas y modelo cocomo para el costo de un proyecto software
Andres Hoyos Mosquera
 
Metodología RUP
Metodología RUPMetodología RUP
Metodología RUP
Jorge Cortés Alvarez
 
Modelo De Desarrollo Evolutivo
Modelo De Desarrollo EvolutivoModelo De Desarrollo Evolutivo
Modelo De Desarrollo Evolutivo
camilosena89
 
Estimación de Proyectos de Software
Estimación de Proyectos de SoftwareEstimación de Proyectos de Software
Estimación de Proyectos de Software
Andrés Felipe Montoya Ríos
 
Gestión de proyectos de software - Subtema 3.1: Objetivo del proyecto
Gestión de proyectos de software - Subtema 3.1: Objetivo del proyectoGestión de proyectos de software - Subtema 3.1: Objetivo del proyecto
Gestión de proyectos de software - Subtema 3.1: Objetivo del proyecto
Jair Valenz
 
Enfoque estructurado y Enfoque OO - Ingenieria de software
Enfoque estructurado y Enfoque OO  - Ingenieria de softwareEnfoque estructurado y Enfoque OO  - Ingenieria de software
Enfoque estructurado y Enfoque OO - Ingenieria de software
Kola Real
 
Análisis estructurado
Análisis estructuradoAnálisis estructurado
Análisis estructurado
MSc Aldo Valdez Alvarado
 
Modelo incremental
Modelo incrementalModelo incremental
Modelo incremental
Avelino Felipe Policarpio
 
modelos del proceso del software
 modelos del proceso del software  modelos del proceso del software
modelos del proceso del software
Brihany Rossell
 
control de concurrencia
control de concurrenciacontrol de concurrencia
control de concurrencia
Jose Guadalupe Couoh Dzul
 
Metodologia XP
Metodologia XPMetodologia XP
Modelo de desarrollo de software
Modelo de desarrollo de softwareModelo de desarrollo de software
Modelo de desarrollo de software
Yaskelly Yedra
 
Metodologia orientada a objeto
Metodologia orientada a objetoMetodologia orientada a objeto
Metodologia orientada a objeto
Luis Eduardo Aponte
 
Proceso unificado de desarrollo de software
Proceso unificado de desarrollo de softwareProceso unificado de desarrollo de software
Proceso unificado de desarrollo de software
turlahackers
 

La actualidad más candente (20)

Ciclo Vida del Software
Ciclo Vida del SoftwareCiclo Vida del Software
Ciclo Vida del Software
 
MODELO COCOMO (INGENIERA DE SOFTWARE)
MODELO COCOMO (INGENIERA DE SOFTWARE)MODELO COCOMO (INGENIERA DE SOFTWARE)
MODELO COCOMO (INGENIERA DE SOFTWARE)
 
Tecnicas de estimacion de software
Tecnicas de estimacion de softwareTecnicas de estimacion de software
Tecnicas de estimacion de software
 
Modelo evolutivo
Modelo evolutivoModelo evolutivo
Modelo evolutivo
 
Metodologías de Desarrollo de Software Tradicionales y Emergentes
Metodologías de Desarrollo de Software Tradicionales y EmergentesMetodologías de Desarrollo de Software Tradicionales y Emergentes
Metodologías de Desarrollo de Software Tradicionales y Emergentes
 
Metodologia rup
Metodologia rupMetodologia rup
Metodologia rup
 
Metodologías, metricas y modelo cocomo para el costo de un proyecto software
Metodologías, metricas y modelo cocomo para el costo de un proyecto softwareMetodologías, metricas y modelo cocomo para el costo de un proyecto software
Metodologías, metricas y modelo cocomo para el costo de un proyecto software
 
Metodología RUP
Metodología RUPMetodología RUP
Metodología RUP
 
Modelo De Desarrollo Evolutivo
Modelo De Desarrollo EvolutivoModelo De Desarrollo Evolutivo
Modelo De Desarrollo Evolutivo
 
Estimación de Proyectos de Software
Estimación de Proyectos de SoftwareEstimación de Proyectos de Software
Estimación de Proyectos de Software
 
Gestión de proyectos de software - Subtema 3.1: Objetivo del proyecto
Gestión de proyectos de software - Subtema 3.1: Objetivo del proyectoGestión de proyectos de software - Subtema 3.1: Objetivo del proyecto
Gestión de proyectos de software - Subtema 3.1: Objetivo del proyecto
 
Enfoque estructurado y Enfoque OO - Ingenieria de software
Enfoque estructurado y Enfoque OO  - Ingenieria de softwareEnfoque estructurado y Enfoque OO  - Ingenieria de software
Enfoque estructurado y Enfoque OO - Ingenieria de software
 
Análisis estructurado
Análisis estructuradoAnálisis estructurado
Análisis estructurado
 
Modelo incremental
Modelo incrementalModelo incremental
Modelo incremental
 
modelos del proceso del software
 modelos del proceso del software  modelos del proceso del software
modelos del proceso del software
 
control de concurrencia
control de concurrenciacontrol de concurrencia
control de concurrencia
 
Metodologia XP
Metodologia XPMetodologia XP
Metodologia XP
 
Modelo de desarrollo de software
Modelo de desarrollo de softwareModelo de desarrollo de software
Modelo de desarrollo de software
 
Metodologia orientada a objeto
Metodologia orientada a objetoMetodologia orientada a objeto
Metodologia orientada a objeto
 
Proceso unificado de desarrollo de software
Proceso unificado de desarrollo de softwareProceso unificado de desarrollo de software
Proceso unificado de desarrollo de software
 

Destacado

Metodologías Ágiles para el Desarrollo de Software y Metodologias Para el de...
Metodologías Ágiles  para el Desarrollo de Software y Metodologias Para el de...Metodologías Ágiles  para el Desarrollo de Software y Metodologias Para el de...
Metodologías Ágiles para el Desarrollo de Software y Metodologias Para el de...
Joel Fernandez
 
Metodologia para el desarrollo de software
Metodologia para el desarrollo de softwareMetodologia para el desarrollo de software
Metodologia para el desarrollo de software
Carlos Zambrano
 
Metodologias de desarrollo
Metodologias de desarrolloMetodologias de desarrollo
Metodologias de desarrollo
Hermes Romero
 
Diseño de Sistemas
Diseño de SistemasDiseño de Sistemas
Diseño de Sistemas
JUANESTEFA
 
Analisis estructurado
Analisis estructuradoAnalisis estructurado
Analisis estructurado
kvillazon
 
Proyecto Farmacia
Proyecto FarmaciaProyecto Farmacia
Proyecto Farmacia
José Zambrano
 
Ejemplo plan de desarrollo de software rup
Ejemplo plan de desarrollo de software rupEjemplo plan de desarrollo de software rup
Ejemplo plan de desarrollo de software rup
Xochitl Saucedo Muñoz
 

Destacado (7)

Metodologías Ágiles para el Desarrollo de Software y Metodologias Para el de...
Metodologías Ágiles  para el Desarrollo de Software y Metodologias Para el de...Metodologías Ágiles  para el Desarrollo de Software y Metodologias Para el de...
Metodologías Ágiles para el Desarrollo de Software y Metodologias Para el de...
 
Metodologia para el desarrollo de software
Metodologia para el desarrollo de softwareMetodologia para el desarrollo de software
Metodologia para el desarrollo de software
 
Metodologias de desarrollo
Metodologias de desarrolloMetodologias de desarrollo
Metodologias de desarrollo
 
Diseño de Sistemas
Diseño de SistemasDiseño de Sistemas
Diseño de Sistemas
 
Analisis estructurado
Analisis estructuradoAnalisis estructurado
Analisis estructurado
 
Proyecto Farmacia
Proyecto FarmaciaProyecto Farmacia
Proyecto Farmacia
 
Ejemplo plan de desarrollo de software rup
Ejemplo plan de desarrollo de software rupEjemplo plan de desarrollo de software rup
Ejemplo plan de desarrollo de software rup
 

Similar a Metodologias para el desarrollo del software

4 Clase Metodologia De Desarrolo De Software
4 Clase Metodologia De Desarrolo De Software4 Clase Metodologia De Desarrolo De Software
4 Clase Metodologia De Desarrolo De Software
Julio Pari
 
¡Summit loxa ingenieria de software
¡Summit loxa ingenieria de software¡Summit loxa ingenieria de software
¡Summit loxa ingenieria de software
JorgeArmijosC
 
Metodologías para desarrollo de software
Metodologías para desarrollo de softwareMetodologías para desarrollo de software
Metodologías para desarrollo de software
Abner Garcia
 
Software libre 2 edit evaluacion
Software libre 2 edit evaluacionSoftware libre 2 edit evaluacion
Software libre 2 edit evaluacion
wilmer95
 
Ingenieria del Software
Ingenieria del SoftwareIngenieria del Software
Ingenieria del Software
Luis R Inciarte
 
4 1 personalizacion de metodologias
4 1 personalizacion de metodologias4 1 personalizacion de metodologias
4 1 personalizacion de metodologias
landeta_p
 
Metodología de desarrollo de softwaree
Metodología de desarrollo de softwareeMetodología de desarrollo de softwaree
Metodología de desarrollo de softwaree
Abner Garcia
 
Intoduccion A La Ingenieria Del Software
Intoduccion A La Ingenieria Del SoftwareIntoduccion A La Ingenieria Del Software
Intoduccion A La Ingenieria Del Software
guest9ad165
 
Introducción a los
Introducción a los Introducción a los
Introducción a los
Henry Yu
 
Metodologia y prototipo
Metodologia y prototipoMetodologia y prototipo
Metodologia y prototipo
Arturo Jimenez
 
Metodologias de Analisis y Diseno de Sistemas
Metodologias de Analisis y Diseno de SistemasMetodologias de Analisis y Diseno de Sistemas
Metodologias de Analisis y Diseno de Sistemas
Elvis Mendoza Sequera
 
C icie99-ingenieriasoftwareeducativo
C icie99-ingenieriasoftwareeducativoC icie99-ingenieriasoftwareeducativo
C icie99-ingenieriasoftwareeducativo
Henry Cambal
 
Clasificación de las metodologías de desarrollo de software
Clasificación de las metodologías de desarrollo de softwareClasificación de las metodologías de desarrollo de software
Clasificación de las metodologías de desarrollo de software
Eliset Gonzales Uceda
 
Lineas de productos de software y método watch
Lineas de productos de software y método watchLineas de productos de software y método watch
Lineas de productos de software y método watch
Yonathan Rodriguez
 
las metodologias de desarrolos de sistemas
las metodologias de desarrolos de sistemas las metodologias de desarrolos de sistemas
las metodologias de desarrolos de sistemas
Adriana Devera
 
Metodologias de procesos de software
Metodologias de procesos de softwareMetodologias de procesos de software
Metodologias de procesos de software
Rodrigo Villavicencio Castillo
 
Desarrollo estructurado
Desarrollo estructuradoDesarrollo estructurado
Desarrollo estructurado
waralivt
 
Desarrollo estructurado
Desarrollo estructuradoDesarrollo estructurado
Desarrollo estructurado
waralivt
 
Guia unidad ii fundamentacion de ingenieria del software
Guia unidad ii fundamentacion de ingenieria del softwareGuia unidad ii fundamentacion de ingenieria del software
Guia unidad ii fundamentacion de ingenieria del software
sullinsan
 
MoProsoft
MoProsoftMoProsoft

Similar a Metodologias para el desarrollo del software (20)

4 Clase Metodologia De Desarrolo De Software
4 Clase Metodologia De Desarrolo De Software4 Clase Metodologia De Desarrolo De Software
4 Clase Metodologia De Desarrolo De Software
 
¡Summit loxa ingenieria de software
¡Summit loxa ingenieria de software¡Summit loxa ingenieria de software
¡Summit loxa ingenieria de software
 
Metodologías para desarrollo de software
Metodologías para desarrollo de softwareMetodologías para desarrollo de software
Metodologías para desarrollo de software
 
Software libre 2 edit evaluacion
Software libre 2 edit evaluacionSoftware libre 2 edit evaluacion
Software libre 2 edit evaluacion
 
Ingenieria del Software
Ingenieria del SoftwareIngenieria del Software
Ingenieria del Software
 
4 1 personalizacion de metodologias
4 1 personalizacion de metodologias4 1 personalizacion de metodologias
4 1 personalizacion de metodologias
 
Metodología de desarrollo de softwaree
Metodología de desarrollo de softwareeMetodología de desarrollo de softwaree
Metodología de desarrollo de softwaree
 
Intoduccion A La Ingenieria Del Software
Intoduccion A La Ingenieria Del SoftwareIntoduccion A La Ingenieria Del Software
Intoduccion A La Ingenieria Del Software
 
Introducción a los
Introducción a los Introducción a los
Introducción a los
 
Metodologia y prototipo
Metodologia y prototipoMetodologia y prototipo
Metodologia y prototipo
 
Metodologias de Analisis y Diseno de Sistemas
Metodologias de Analisis y Diseno de SistemasMetodologias de Analisis y Diseno de Sistemas
Metodologias de Analisis y Diseno de Sistemas
 
C icie99-ingenieriasoftwareeducativo
C icie99-ingenieriasoftwareeducativoC icie99-ingenieriasoftwareeducativo
C icie99-ingenieriasoftwareeducativo
 
Clasificación de las metodologías de desarrollo de software
Clasificación de las metodologías de desarrollo de softwareClasificación de las metodologías de desarrollo de software
Clasificación de las metodologías de desarrollo de software
 
Lineas de productos de software y método watch
Lineas de productos de software y método watchLineas de productos de software y método watch
Lineas de productos de software y método watch
 
las metodologias de desarrolos de sistemas
las metodologias de desarrolos de sistemas las metodologias de desarrolos de sistemas
las metodologias de desarrolos de sistemas
 
Metodologias de procesos de software
Metodologias de procesos de softwareMetodologias de procesos de software
Metodologias de procesos de software
 
Desarrollo estructurado
Desarrollo estructuradoDesarrollo estructurado
Desarrollo estructurado
 
Desarrollo estructurado
Desarrollo estructuradoDesarrollo estructurado
Desarrollo estructurado
 
Guia unidad ii fundamentacion de ingenieria del software
Guia unidad ii fundamentacion de ingenieria del softwareGuia unidad ii fundamentacion de ingenieria del software
Guia unidad ii fundamentacion de ingenieria del software
 
MoProsoft
MoProsoftMoProsoft
MoProsoft
 

Último

Manual_Ensamblador_ing_sistemas computacionales.pdf
Manual_Ensamblador_ing_sistemas computacionales.pdfManual_Ensamblador_ing_sistemas computacionales.pdf
Manual_Ensamblador_ing_sistemas computacionales.pdf
alejandroalcantaraut
 
Integracion Integligencia Artificial Generativa en STELA
Integracion  Integligencia Artificial Generativa en STELAIntegracion  Integligencia Artificial Generativa en STELA
Integracion Integligencia Artificial Generativa en STELA
Guillermo Talento
 
Proteccion Electronica enfocado en la Guerra Electronica.pptx
Proteccion Electronica enfocado en la Guerra Electronica.pptxProteccion Electronica enfocado en la Guerra Electronica.pptx
Proteccion Electronica enfocado en la Guerra Electronica.pptx
eghurtadoc
 
Entrenamiento de introducción en Share Point (JateNX)
Entrenamiento de introducción en  Share Point (JateNX)Entrenamiento de introducción en  Share Point (JateNX)
Entrenamiento de introducción en Share Point (JateNX)
administracion997432
 
Projecto Loom - Structured Concurrency - JavaMexico - Julio 2024
Projecto Loom - Structured Concurrency - JavaMexico - Julio 2024Projecto Loom - Structured Concurrency - JavaMexico - Julio 2024
Projecto Loom - Structured Concurrency - JavaMexico - Julio 2024
Domingo Suarez Torres
 
Varias Consultas hana cloud inventarios
Varias Consultas hana cloud  inventariosVarias Consultas hana cloud  inventarios
Varias Consultas hana cloud inventarios
carloshernandez141319
 
Girls Call Guwahati 000XX00000 Provide Best And Top Girl Service And No1 in ...
 Girls Call Guwahati 000XX00000 Provide Best And Top Girl Service And No1 in ... Girls Call Guwahati 000XX00000 Provide Best And Top Girl Service And No1 in ...
Girls Call Guwahati 000XX00000 Provide Best And Top Girl Service And No1 in ...
rakeshsoni95123
 

Último (7)

Manual_Ensamblador_ing_sistemas computacionales.pdf
Manual_Ensamblador_ing_sistemas computacionales.pdfManual_Ensamblador_ing_sistemas computacionales.pdf
Manual_Ensamblador_ing_sistemas computacionales.pdf
 
Integracion Integligencia Artificial Generativa en STELA
Integracion  Integligencia Artificial Generativa en STELAIntegracion  Integligencia Artificial Generativa en STELA
Integracion Integligencia Artificial Generativa en STELA
 
Proteccion Electronica enfocado en la Guerra Electronica.pptx
Proteccion Electronica enfocado en la Guerra Electronica.pptxProteccion Electronica enfocado en la Guerra Electronica.pptx
Proteccion Electronica enfocado en la Guerra Electronica.pptx
 
Entrenamiento de introducción en Share Point (JateNX)
Entrenamiento de introducción en  Share Point (JateNX)Entrenamiento de introducción en  Share Point (JateNX)
Entrenamiento de introducción en Share Point (JateNX)
 
Projecto Loom - Structured Concurrency - JavaMexico - Julio 2024
Projecto Loom - Structured Concurrency - JavaMexico - Julio 2024Projecto Loom - Structured Concurrency - JavaMexico - Julio 2024
Projecto Loom - Structured Concurrency - JavaMexico - Julio 2024
 
Varias Consultas hana cloud inventarios
Varias Consultas hana cloud  inventariosVarias Consultas hana cloud  inventarios
Varias Consultas hana cloud inventarios
 
Girls Call Guwahati 000XX00000 Provide Best And Top Girl Service And No1 in ...
 Girls Call Guwahati 000XX00000 Provide Best And Top Girl Service And No1 in ... Girls Call Guwahati 000XX00000 Provide Best And Top Girl Service And No1 in ...
Girls Call Guwahati 000XX00000 Provide Best And Top Girl Service And No1 in ...
 

Metodologias para el desarrollo del software

  • 1. Análisis y Sistemas 20/05/2015 Por: Yeltsin Aldair Torres Recinos INSTITUTO PRIVADO TECNOLÒGICO SPENCER W. KIMBALL Bachiller industrial y perito en computación. 5to computación Análisis y sistemas Prof.: Álvaro Martínez Metodologías para el desarrollo del software. Yeltsin Aldair Torres Recinos Fecha de entrega: 20/05/2015
  • 2. Análisis y Sistemas 20/05/2015 Por: Yeltsin Aldair Torres Recinos Introducción El presente el trabajo trata sobre la metodología para desarrollo del software que es Un proceso de software detallado y completo suele denominarse “Metodología”, también sus características y los tipos de metodologías.
  • 3. Análisis y Sistemas 20/05/2015 Por: Yeltsin Aldair Torres Recinos Índice vinculado Metodologías para el desarrollo del software..................................................................................................... 1 METODOLOGÍAS ESTRUCTURADAS.....................................................................................................................................3 METODOLOGÍAS ORIENTADAS A OBJETOS........................................................................................................................3 METODOLOGÍAS TRADICIONALES........................................................................................................................................3 METODOLOGÍAS ÁGILES ........................................................................................................................................................4 CARACTERISTICAS DESEABLESDE UNA METODOLOGIADE UNA METODOLOGIA .......................................................4 EVOLUCION ......................................................................................................................................................... 4 Los tipos de metodologías para el desarrollo del software son:......................................................................... 6 Ciclo de vida del software.....................................................................................................................................................6 Modelos de ciclo de vida .......................................................................................................................................................7 Modelo V .................................................................................................................................................... 7 Modelo en cascada..................................................................................................................................... 8 Modelo espiral............................................................................................................................................ 8 Método espiral .................................................................................................................................................... 9 METODOLOGÍA RUP.............................................................................................................................................................. 10 Principales características .................................................................................................................................................. 10 CICLO DE VIDA.........................................................................................................................................................................11 Fases del ciclo de vida del RUP:..........................................................................................................................................11 Disciplina de soporte RUP....................................................................................................................................................13 Elementos del RUP................................................................................................................................................................13 Artefactos................................................................................................................................................................................13 METODOLOGÍA SCRUM ...................................................................................................................................... 15 Características....................................................................................................................................................................... 15 METODOLOGIA XP ............................................................................................................................................. 17 Entendimiento........................................................................................................................................................................17 1. Interacción con el cliente............................................................................................................................... 19 2. Planificación del proyecto………………………………………………………………………………………………………………………………19 3.Diseño, desarrollo y pruebas …………………………………………………………..…………………………………………………..……20
  • 4. Análisis y Sistemas 20/05/2015 1 Por: Yeltsin Aldair Torres Recinos Metodologías para el desarrollo del software. Un proceso de software detallado y completo suele denominarse “Metodología”. Las metodologías se basan en una combinación de los modelos de proceso genéricos (cascada, evolutivo, incremental, espiral entre otros). Adicionalmente una metodología debería definir con precisión los artefactos, roles y actividades involucrados, junto con prácticas y técnicas recomendadas, guías de adaptación de la metodología al proyecto, guías para uso de herramientas de apoyo, etc. Habitualmente se utiliza el término “método” para referirse a técnicas, notaciones y guías asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de métodos de análisis y/o diseño. La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la diversidad de propuestas y diferencias en el grado de detalle, información disponible y alcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las notaciones utilizadas para especificar artefactos producidos en actividades de análisis y diseño, podemos clasificar las metodologías en dos grupos: Metodologías Estructuradas y Metodologías Orientadas a Objetos. Por otra parte, considerando su filosofía de desarrollo, aquellas metodologías con mayor énfasis en la planificación y control del proyecto, en especificación precisa de requisitos y modelado, reciben el apelativo de Metodologías Tradicionales (o también denominadas Metodologías Pesadas, o Peso Pesado). Otras metodologías, denominadas Metodologías Ágiles, están más orientadas a la generación de código con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeños, hacen especial hincapié en aspectos humanos asociados al trabajo en equipo e involucran activamente al cliente en el proceso. Se describe como el conjunto de herramientas, técnicas, procedimientos y soporte documental para el diseño de Sistemas de información. En Ingeniería de software cuando se habla de desarrollo de software se habla de desarrollo de programas y por lo tanto se considera como una tarea de ingeniería, en el cuál se debe ejecutar una serie de fases, etapas para obtener un programa que funcione de acuerdo con métodos ya establecidos en otras disciplinas de ingeniería. Las actividades que los ingenieros de software realizan se encuentran asociadas a un proceso de software donde intervienen diferentes elementos (fases, actividades, producto, roles, agentes) que permiten la definición del software a producir (producto), el desarrollo o el diseño del software, la validación del software tanto lo interno (requerimientos específicos) como lo externo (expectativas del cliente), y la evolución del software donde se modifica para adaptarlo a los cambios. Por otro lado, Sommerville (2002) define que “un método de ingeniería de software es un enfoque estructurado para el desarrollo de software cuyo propósito es facilitar la producción de software de alta calidad de una forma costeable”, cabe destacar que para usar este enfoque se debe manejar conceptos fundamentales tales como; procesos, métodos, tareas, procedimientos, técnicas, herramientas, productos, entre otros. Particularmente, una metodología se basa en una combinación de los modelos de proceso genéricos para obtener como beneficio un software que soluciones un problema.
  • 5. Análisis y Sistemas 20/05/2015 2 Por: Yeltsin Aldair Torres Recinos Adicionalmente una metodología debería definir con precisión los artefactos, roles y actividades, junto con prácticas, técnicas recomendadas y guías de adaptación de la metodología al proyecto. Sin embargo, la complejidad del proceso de creación de software es netamente dependiente de la naturaleza del proyecto mismo, por lo que el escogimiento de la metodología estará acorde al nivel de aporte del proyecto, ya sea pequeño, mediano o de gran nivel.
  • 6. Análisis y Sistemas 20/05/2015 3 Por: Yeltsin Aldair Torres Recinos A continuación se revisan brevemente cada una de estas categorías de metodologías: METODOLOGÍAS ESTRUCTURADAS Los métodos estructurados comenzaron a desarrollarse a fines de los 70’s con la Programación Estructurada, luego a mediados de los 70’s aparecieron técnicas para el Diseño (por ejemplo: el diagrama de Estructura) primero y posteriormente para el Análisis (por ejemplo: 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 estructuradas de ámbito gubernamental: MERISE (Francia), MÉTRICA (España), SSADM (Reino Unido). Ejemplos de propuestas de métodos estructurados en el ámbito académico: Gane & Sarson, Ward & Mellor, Yourdon & DeMarco e Information Engineering. METODOLOGÍAS ORIENTADAS A OBJETOS Su historia va unida a la evolución de los lenguajes de programación orientada a objeto, los más representativos: a fines de los 60’s SIMULA, a fines de los 70’s Smalltalk-80, la primera versión de C++ por Bjarne Stroustrup en 1981 y actualmente Java o C# de Microsoft. A fines de los 80’s comenzaron a consolidarse algunos métodos Orientadas a Objeto. En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de conseguir una unificación de sus métodos y notaciones, que posteriormente se reorienta a un objetivo más modesto, para dar lugar al Unified Modeling Language (UML), la notación Orientada a Objetos más popular en la actualidad. 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 Las metodologías no ágiles son aquellas que están guiadas por una fuerte planificación durante todo el proceso de desarrollo; llamadas también metodologías tradicionales o clásicas, donde 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. Aunque en el caso particular de RUP, por el especial énfasis que presenta en cuanto a su adaptación a las condiciones del proyecto (mediante su configuración previa a aplicarse), realizando una configuración adecuada, podría considerarse Ágil.
  • 7. Análisis y Sistemas 20/05/2015 4 Por: Yeltsin Aldair Torres Recinos METODOLOGÍAS ÁGILES Un proceso es ágil cuando el desarrollo de software es incremental (entregas pequeñas de software, con ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntos constantemente con una cercana comunicación), sencillo (el método en sí mismo es fácil de aprender y modificar, bien documentado), y adaptable (permite realizar cambios de último momento). Entre las metodologías ágiles identificadas son:  Extreme Programming  Scrum  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 CARACTERISTICAS DESEABLESDE UNA METODOLOGIADE UNA METODOLOGIA  Existencia de reglas predefinidas  Cobertura total del ciclo de desarrollo  Verificaciones intermedias  Planificación y control  Comunicación efectiva  Utilización sobre un abanico amplio de proyectos  Fácil formación  Herramientas CASE  Actividades que mejoren el proceso de desarrollo  Soporte al mantenimiento  Soporte de la reutilización de software EVOLUCION Desde que se empezó a trabajar sobre el desarrollo de programas, se siguieron ciertos métodos que permitían llevar a producir un buen proyecto, estas metodologías aplicadas eran simples, solo se preocupaban por los procesos mas no por los datos, por lo tanto los métodos eran desarrollados hacia los procesos. El modelo de procesos predominaba para los años 60 y consistía en codificar y corregir (Code-and-Fix), si al terminar se descubría que el diseño era incorrecto, la solución era desecharlo y volver a empezar 3 , este modelo implementaba el código y luego se pensaba en los requisitos, diseño, validación y mantenimiento. Los principales problemas del modelo de procesos son:  Los arreglos se hacen costosos, después de tantas correcciones el código tenía una mala estructura.
  • 8. Análisis y Sistemas 20/05/2015 5 Por: Yeltsin Aldair Torres Recinos  El software no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstrucción es muy cara.  El código es difícil de reparar por su pobre preparación para probar y modificar. En la década de los setenta empezó a tomar la importancia de los datos, y para solucionar sistemas complejos empezó el análisis por partes o etapas, se introducen la planeación y administración. El modelo en cascada surge como respuesta al modelo de procesos, este modelo tiene más disciplina y se basa en el análisis, diseño, pruebas y mantenimientos. La década de los ochenta es la época marcada por las metodologías dirigida a datos cuya importancia va tomando cuerpo en las organizaciones. Se empiezan a estudiar los objetos en sí como unidades de información. Para los años 90 se quiere dar respuesta al entorno siempre cambiante y en rápida evolución en que se han de desarrollar los programas informáticos, lo cual da lugar a trabajar en ciclos cortos (como mini-proyectos) que implementan una parte de las funcionalidades, pero sin perder el rumbo general del proyecto global. Por otra parte las metodologías de desarrollo comienzan a interesarse no sólo en lograr que el proyecto sea puesto en funcionamiento sino en minimizar costos durante su desarrollo y sobre todo durante su mantenimiento. Los nuevos métodos van buscando minimizar riesgos y, puesto que los errores más perjudiciales se producen en los primeros pasos, se comienza ya desde la fase más general del estudio por analizar los riesgos que significa seguir con las siguientes fases del desarrollo. Las metodologías más utilizadas a nivel mundial en orden cronológico:  Década de los 70s  Programación Estructurada Jackson desde 1975 Década de los 80s  Structured Systems Analysis and Design Methodology (SSADM) desde 1980  Structured Analysis and Design Technique (SADT) desde 1980  Ingeniería de la Información (IE/IEM) desde 1981 Década de los 90s  Rapid Application Development (RAD) desde 1991  Programación Orientada a Objetos (OOP) a lo largo de la década de los 90's  Virtual Finite State Machine (VFSM) desde 1990s  Dynamic Systems Development Method desarrollado en UK desde 1995.  Rational Unified Process (RUP) desde 1999 Año 2000 en adelante  Extreme Programming (XP) desde 1999  Enterprise Unified Process (EUP) extensiones RUP desde 2002  Constructionist Design Methodology (CDM) desde 2004 por Kristinn R. Thórisson  Agile Unified Process (AUP) desde 2005 por Scott Ambler
  • 9. Análisis y Sistemas 20/05/2015 6 Por: Yeltsin Aldair Torres Recinos Los tipos de metodologías para el desarrollo del software son:  CICLO DE VIDA El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones. RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades. En la Figura muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto RUP. Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una baseline (Línea Base) de la arquitectura. Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de modelado del negocio y de requisitos. En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan más los flujos de trabajo de requisitos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la baseline de la arquitectura. En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones. Para cada iteración se seleccionan algunos Casos de Uso, se refinan su análisis y diseño y se procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan iteraciones hasta que se termine la implementación de la nueva versión del producto. En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios. Como se puede observar en cada fase participan todas las disciplinas, pero dependiendo de la fase el esfuerzo dedicado a una disciplina varía. Ciclo de vida del software El termino ciclo de vida del software describe el desarrollo de software desde la fase inicial hasta la fase final. El propósito de este programa es definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicación. El ciclo de vida básico de un software consta de los siguientes requerimientos:  Definición de objetos: define el resultado del proyecto y su papel en la estrategia global.  Análisis de los requisitos y su viabilidad: Recopilar, examinar y formular los requisitos del cliente y examinar cualquier descripción que se pueda aplicar.  Diseño general: Requisitos generales de la arquitectura de la aplicación.
  • 10. Análisis y Sistemas 20/05/2015 7 Por: Yeltsin Aldair Torres Recinos  Diseño en detalle: Definición precisa de cada subconjunto de la aplicación.  Programación: Implementación de un lenguaje de programación para crear las funciones definidas durante la etapa de diseño.  Prueba de unidad: Prueba individual de cada subconjunto de la aplicación para garantizar que se implementara de acuerdo con las especificaciones.  Integración: Para garantizar los diferentes módulos se integren con la aplicación.  Prueba beta o validación: Para garantizar que el software cumple con las especificaciones originales.  Documentación: Sirve para documentar información necesaria para los usuarios del software y para desarrollos futuros.  Implementación: Poner en producción.  Mantenimiento: Para todos los procedimientos correctivos y las actualizaciones secundarias del software (Mantenimiento continuo). Modelos de ciclo de vida Para facilitar una metodología común entre el cliente y la compañía de software, los modelos de ciclo de vida se han actualizado para reflejar las etapas de desarrollo involucradas, y la documentación requerida, de manera que cada etapa se valide antes de continuar con la siguiente etapa. Modelo V El modelo de ciclo de vida V proviene del principio que establece que los procedimientos utilizados para probar si la aplicación cumple las especificaciones ya deben haberse creado en la fase de diseño.
  • 11. Análisis y Sistemas 20/05/2015 8 Por: Yeltsin Aldair Torres Recinos Modelo en cascada El modelo de ciclo de vida en cascada comenzó a diseñarse en 1966 y termina alrededor de 1970. Se define como una secuencia de fases en la etapa final de cada una de ellas se reúne la documentación para garantizar que cumple con las especificaciones y los requisitos antes de pasar a la siguiente fase Modelo espiral El modelo espiral fue propuesto inicialmente por Barry Boehm. Es un modelo evolutivo que conjuga la naturaleza iterativa del modelo MCP con los aspectos controlados y sistemáticos del Modelo Cascada. Proporciona potencial para desarrollo rápido de versiones incrementales. En el modelo Espiral el software se construye en una serie de versiones incrementales. En las primeras iteraciones la versión incremental podría ser un modelo en papel o bien un prototipo. En las últimas iteraciones se producen versiones cada vez más completas del sistema diseñado.
  • 12. Análisis y Sistemas 20/05/2015 9 Por: Yeltsin Aldair Torres Recinos Método espiral DESARROLLO EN ESPIRAL Éste es un tipo de desarrollo evolutivo, las versiones de cada etapa van evolucionando, madurando de acuerdo a cada iteración que se haga cabe recalcar que en cada iteración se desarrollará todas las etapas en orden. CARACTERÍSTICAS: -Es ideal para crear productos con diferentes versiones mejoradas como se hace con el software moderno de microcomputadoras. - puede desarrollarse a través del ciclo de vida clásico o el de construcción de prototipos. COMUNICACIÓN CON EL CLIENTE: Aquí establecemos los requerimientos y objetivos que se quieren del sistema. PLANIFICACIÓN Seguidamente debemos estructurar nuestro trabajo, planificar tiempo, establecer metas, etc. ANÁLISIS DE RIESGOS Se debe identificar los riesgos relacionados con el proyecto, todas aquellas eventualidades que pueden ocurrir, y tratar de que estos riesgos no se den o en el caso de que lleguen a pasar establecer acciones para resolverlas. INGENIERÍA Las tarea necesarias para construir la aplicación (la representación del sistema y debidamente estructurada). CONSTRUCCIÓN Y ADAPTACIÓN Luego se debe construir el software, realizar las pruebas correspondientes y brindar soporte al usuario. EVALUACIÓN DEL CLIENTE El cliente es quien debe dar la conformidad del avance y si el resultado del trabajo cumple con las expectativas del usuario. VENTAJAS A medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles. -Reduce los riesgos antes de que se conviertan en problemáticos.
  • 13. Análisis y Sistemas 20/05/2015 10 Por: Yeltsin Aldair Torres Recinos METODOLOGÍA RUP Es una metodología cuyo fin es entregar un producto de software. Se estructura todos los procesos y se mide la eficiencia de la organización. Es un proceso de desarrollo de software el cual utiliza 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 es un conjunto de metodologías adaptables al contexto y necesidades de cada organización. Describe cómo aplicar enfoques para el desarrollo del software, llevando a cabo unos pasos para su realización. Se centra en la producción y mantenimiento de modelos del sistema. Principales características  Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)  Pretende implementar las mejores prácticas en Ingeniería de Software  Desarrollo iterativo  Administración de requisitos  Uso de arquitectura basada en componentes  Control de cambios  Modelado visual del software  Verificación de la calidad del software
  • 14. Análisis y Sistemas 20/05/2015 11 Por: Yeltsin Aldair Torres Recinos El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso). CICLO DE VIDA Esfuerzo en actividades según fase del proyecto El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones. RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades. Fases del ciclo de vida del RUP: 1. Fase de 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. 2. Fase de 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
  • 15. Análisis y Sistemas 20/05/2015 12 Por: Yeltsin Aldair Torres Recinos 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. 3. Fase de Desarrollo: El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requerimientos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto. 4. Fase de Cierre: 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. La metodología RUP tiene 6 principios clave: 1. Adaptación del proceso: El proceso debe adaptarse a las características de la organización para la que se está desarrollando el software. 2. Balancear prioridades: Debe encontrarse un balance que satisfaga a todos los inversores del proyecto. 3. Colaboración entre equipos: Debe haber una comunicación fluida para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados, entre otros. 4. Demostrar valor iterativamente: Los proyectos se entregan, aunque sea de una forma interna, en etapas iteradas. En cada iteración se evaluará la calidad y estabilidad del producto y analizará la opinión y sugerencias de los inversores.
  • 16. Análisis y Sistemas 20/05/2015 13 Por: Yeltsin Aldair Torres Recinos 5. Elevar el nivel de abstracción: Motivar el uso de de conceptos reutilizables. 6. Enfocarse en la calidad: La calidad del producto debe verificarse en cada aspecto de la producción. Disciplina de desarrollo de RUP Determina las etapas a realizar durante el proyecto de creación del software.  Ingeniería o modelado del negocio: Analizar y entender las necesidades del negocio para el cual se está desarrollando el software.  Requisitos: Proveer una base para estimar los costos y tiempo de desarrollo del sistema.  Análisis y diseño: Trasladar los requisitos analizados anteriormente a un sistema automatizado y desarrollar una arquitectura para el sistema.  Implementación: Crear software que se ajuste a la arquitectura diseñada y que tenga el comportamiento deseado.  Pruebas: Asegurarse de que el comportamiento requerido es correcto y que todo lo solicitado está presente.  Despliegue: Producir distribuciones del producto y distribuirlo a los usuarios. Disciplina de soporte RUP Determina la documentación que es necesaria realizar durante el proyecto.  Configuración y administración del cambio: Guardar todas las versiones del proyecto.  Administración del proyecto: Administrar los horarios y recursos que se deben de emplear.  Ambiente: Administrar el ambiente de desarrollo del software.  Distribución: Hacer todo lo necesario para la salida del proyecto. Elementos del RUP  Actividades: Procesos que se han de realizar en cada etapa/iteración.  Trabajadores: Personas involucradas en cada actividad del proyecto.  Artefactos: Herramientas empleadas para el desarrollo del proyecto. Puede ser un documento, un modelo, un elemento del modelo. Artefactos RUP en cada una de sus fases (pertenecientes a la estructura estática) realiza una serie de artefactos que sirven para comprender mejor tanto el análisis como el diseño del sistema (entre otros). Estos artefactos (entre otros) son los siguientes:
  • 17. Análisis y Sistemas 20/05/2015 14 Por: Yeltsin Aldair Torres Recinos Inicio:  Documento Visión  Especificación de Requerimientos Elaboración:  Diagramas de caso de uso Construcción:  Documento Arquitectura que trabaja con las siguientes vistas: VISTA LOGICA:  Diagrama de clases  Modelo E-R (Si el sistema así lo requiere) VISTA DE IMPLEMENTACION:  Diagrama de Secuencia  Diagrama de estados  Diagrama de Colaboración VISTA CONCEPTUAL  Modelo de dominio VISTA FISICA  Mapa de comportamiento a nivel de har
  • 18. Análisis y Sistemas 20/05/2015 15 Por: Yeltsin Aldair Torres Recinos METODOLOGÍA SCRUM Scrum es una metodología ágil de desarrollo, aunque surgió como modelo para el desarrollo de productos tecnológicos, también se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software. 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. Scrum es una metodología ágil, y como tal:  Es un modo de desarrollo de carácter adaptable más que predictivo.  Orientado a las personas más que a los procesos.  Emplea la estructura de desarrollo ágil: incremental basada en iteraciones y revisiones. 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. Estructura central de Scrum Características  Equipos auto dirigidos  Utiliza reglas para crear un entorno ágil de administración de proyectos  No prescribe prácticas específicas de ingeniería  Los requerimientos se capturan como ítems de la lista Product Backlog.  El producto se construye en una serie de Sprints de un mes de duración.
  • 19. Análisis y Sistemas 20/05/2015 16 Por: Yeltsin Aldair Torres Recinos Herramientas y Prácticas Scrum no requiere ni provee prácticas de Ingeniería. En lugar de eso, especifica prácticas y herramientas de gerencia que se aplican en sus distintas fases para evitar el caos originado por la complejidad e imposibilidad de realizar predicciones. Product Backlog List Es una lista priorizada que define el trabajo que se va a realizar en el proyecto. Cuando un proyecto comienza es muy difícil tener claro todos los requerimientos sobre el producto. Sin embargo, suelen surgir los más importantes que casi siempre son más que suficientes para un Sprint. El objetivo es asegurar que el producto definido al terminar la lista es el más correcto, útil y competitivo posible y para esto la lista debe acompañar los cambios en el entorno y el producto. Existe un rol asociado con esta lista y es el de Product Owner. Si alguien quiere realizar cualquier modificación sobre la lista por ejemplo: agregar o incrementar la prioridad de sus elementos tiene que convencer al Product Owner. Sprints Un Sprint es el procedimiento de adaptación de las cambiantes variables del entorno (requerimientos, tiempo, recursos, conocimiento, tecnología). Son ciclos iterativos en los cuales se desarrolla o mejora una funcionalidad para producir nuevos incrementos. Durante un Sprint el producto es diseñado, codificado y probado. Y su arquitectura y diseño evolucionan durante el desarrollo. El objetivo de un Sprint debe ser expresado en pocas palabras para que sea fácil de recordar y esté siempre presente en el equipo. Burn down Chart La burn down chart es una gráfica mostrada públicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta línea sea descendente (en casos en que todo va bien en el sentido de que los requisitos están bien definidos desde el principio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos tramos. Sprint Backlog Es el punto de entrada de cada Sprint. Es una lista que tiene los ítems de la Product Backlog List que van a ser implementados en el siguiente Sprint.
  • 20. Análisis y Sistemas 20/05/2015 17 Por: Yeltsin Aldair Torres Recinos Los ítems son seleccionados por el Scrum Team, el Scrum Master y el Product Owner en la Sprint Planning Meeting a partir de la priorización de los ítems y los objetivos que se marcaron para ese Sprint. A partir de los objetivos a cumplir durante el Sprint el Scrum Team determina que tareas debe desempeñar para cumplir el objetivo. De esto surge el Sprint Backlog. Stabilization Sprints En estos Sprints el equipo se concentra en encontrar defectos, no en agregar funcionalidad. Suelen aplicarse cuando se prepara un producto para el release. Son útiles cuando se están realizando pruebas beta, se está introduciendo a un equipo en la metodología de Scrum o cuando la calidad de un producto no alcanza los límites esperados. No fueron definidos por Scrum pero han sido recomendados por su utilidad al aplicar esta metodología. Scrum of Scrums o MetaScrum Los equipos de Scrum suelen tener entre 5 y 10 personas, sin embargo está metodología ha sido aplicada en proyectos que involucran más de 600 personas. Esto ha sido llevado a cabo dividiendo a los accionistas en equipos de pequeños de hasta 10 personas aproximadamente. Y definiendo jerárquicamente personas que pertenecen a dos equipos, es decir, además de su rol específico dentro de un equipo tienen el rol de enlace en un equipo superior. METODOLOGIA XP Entregas pequeñas: colocan un sistema sencillo en producción rápidamente que se actualiza de forma rápida y constante permitiendo que el verdadero valor de negocio del producto sea evaluado en un ambiente real. Estas entregas no pueden pasar las 2 o 3 semanas como máximo. Entendimiento 1. Diseño simple: se basa en la filosofía de que el mayor valor de negocio es entregado por el programa más sencillo que cumpla los requerimientos. Simple Design se enfoca en proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni más ni menos. Este proceso permite eliminar redundancias y rejuvenecer los diseños obsoletos de forma sencilla. 2. Metáfora: desarrollada por los programadores al inicio del proyecto, define una historia de cómo funciona el sistema completo. XP estimula historias, que son breves descripciones de un trabajo de un sistema en lugar de los tradicionales diagramas y modelos UML (Unified Modeling Language). La metáfora expresa la visión evolutiva del proyecto que define el alcance y propósito del sistema. Las tarjetas CRC (Clase, Responsabilidad y Colaboración) también ayudarán al equipo a definir actividades durante el diseño del sistema. Cada tarjeta
  • 21. Análisis y Sistemas 20/05/2015 18 Por: Yeltsin Aldair Torres Recinos representa una clase en la programación orientada a objetos y define sus responsabilidades (lo que ha de hacer) y las colaboraciones con las otras clases (cómo se comunica con ellas). 3. Propiedad colectiva del código: un código con propiedad compartida. Nadie es el propietario de nada, todos son el propietario de todo. Este método difiere en mucho a los métodos tradicionales en los que un simple programador posee un conjunto de código. Los defensores de XP argumentan que mientras haya más gente trabajando en una pieza, menos errores aparecerán. 4. Estándar de codificación: define la propiedad del código compartido así como las reglas para escribir y documentar el código y la comunicación entre diferentes piezas de código desarrolladas por diferentes equipos. Los programadores las han de seguir de tal manera que el código en el sistema se vea como si hubiera estado escrito por una sola persona. Bienestar del programador. 1. La semana de 40 horas: la programación extrema sostiene que los programadores cansados escriben código de menor cualidad. Minimizar las horas extras y mantener los programadores frescos, generará código de mayor calidad. Como dice Beck, está bien trabajar tiempos extra cuando es necesario, pero no se ha de hacer durante dos semanas seguidas. PROCESO DE DESARROLLO La programación extrema parte del caso habitual de una compañía que desarrolla software normalmente a medida, en la que hay diferentes roles: un equipo de gestión (o diseño), uno de desarrollo y los clientes finales. La relación entre el equipo de diseño, los que desarrollan el software y clientes es totalmente diferente al que se ha producido en las metodologías tradicionales, que se basaba en una fase de captura de los requisitos previa al desarrollo, y de una fase de validación posterior al mismo.
  • 22. Análisis y Sistemas 20/05/2015 19 Por: Yeltsin Aldair Torres Recinos 1. Interacción con el cliente. En este tipo de programación el cliente pasa a ser parte implicada en el equipo de desarrollo. Su importancia es máxima en el momento de tratar con los usuarios y en efectuar las reuniones de planificación. Tiene un papel importante de interacción con el equipo de programadores, sobre todo después de cada cambio, y de cada posible problema localizado, mostrando las prioridades, expresando sus sensaciones... En este tipo de programación existirán pruebas de aceptación de la programación que ayudarán a que su labor sea lo más provechosa posible. Al fin y al cabo, el cliente se encuentra mucho más cerca del proceso de desarrollo. Se elimina la fase inicial de recopilación de requerimientos, y se permite que éstos se vayan cogiendo a lo largo del proyecto, de una manera ordenada. De esta forma se posibilita que el cliente pueda ir cambiando de opinión sobre la marcha, pero a cambio han de estar siempre disponibles para solucionar las dudas del equipo de desarrollo. En XP aparece un nuevo concepto llamado “Historia de usuario”. Se trata de una lista de características que el cliente necesita que existan en el producto final. Estas constan de dos fases: o En la primera fase, el cliente describe con sus propias palabras las características y, es el responsable del equipo, el encargado de informarlo de las dificultades técnicas de cada una de ellas y de su coste. A consecuencia de este diálogo, el cliente deja por escrito un conjunto de historias y las ordena en función de la prioridad que tiene para él. De esta manera ya es posible definir unas fechas aproximadas para ellos. En la segunda fase, el cliente cogerá las primeras historias a implementar y las dividirá en trabajos a realizar. El cliente también participa, pero hay más peso por parte del equipo de desarrolladores, esto dará como resultado una planificación más exacta. Este método se repetirá para cada historia. A diferencia de otras técnicas, como puede ser UML, en el caso de XP, se exige que sea el cliente el encargado de escribir los documentos con las especificaciones de lo que realmente quiere, como un documento de requisitos de usuario. En esta fase, el equipo técnico será el 'encargado de catalogar las historias del cliente y asignarles una duración. La norma es que cada historia de usuario tiene que poder ser realizable en un espacio entre una y tres semanas de programación. Las que requieran menos tiempo serán agrupadas, y las que necesiten más serán modificadas o divididas. Finalmente decir que las historias de los usuarios serán escritas en tarjetas, lo que facilitará que el cliente pueda especificar la importancia relativa entre las diferentes historias de usuario, así como el trabajo de los programadores que podrán catalogarlas correctamente. Este formato también es muy útil en el momento de las pruebas de aceptación. 2. PLANIFICACIÓN DEL PROYECTO En este punto se tendrá que elaborar la planificación por etapas, donde se aplicarán diferentes iteraciones. Para hacerlo será necesaria la existencia de reglas que se han de seguir por las partes implicadas en el proyecto para que todas las partes tengan voz y se sientan realmente partícipes de la decisión tomada.
  • 23. Análisis y Sistemas 20/05/2015 20 Por: Yeltsin Aldair Torres Recinos Las entregas se tienen que hacer cuanto antes mejor, y con cada iteración, el cliente ha de recibir una nueva versión. Cuanto más tiempo se tarde en introducir una parte esencial, menos tiempo se tendrá para trabajar con ella después. Se aconseja muchas entregas y muy frecuentes. De esta manera un error en la parte inicial del sistema tiene más posibilidades de detectarse rápidamente. Una de las máximas a aplicar es, los cambios, no han de suponer más horas de programación para el programador, ya que el que no se termina en un día, se deja para el día siguiente. Se ha de tener asumido que en el proceso de planificación habrán errores, es más, serán comunes, y por esto esta metodología ya los tiene previstos, por lo tanto se establecerán mecanismos de revisión. Cada tres o cinco iteraciones es normal revisar las historias de los usuarios, y renegociar la planificación. Cada iteración necesita también ser planificada, es lo que se llama planificación iterativa, en la que se anotarán las historias de usuarios que se consideren esenciales y las que no han pasado las pruebas de aceptación. Estas planificaciones también se harán en tarjetas, en las que se escribirán los trabajos que durarán entre uno y tres días. Es por esto que el diseño se puede clasificar como continuo. Añade agilidad al proceso de desarrollo y evita que se mire demasiado hacia delante, desarrollando trabajos que aún no han estado programados. Este tipo de planificación en iteraciones y el diseño iterativo, hace que aparezca una práctica que no existía en la programación tradicional. Se trata de las discusiones diarias informales, para fomentar la comunicación, y para hacer que los desarrolladores tengan tiempo de hablar de los problemas a los que se enfrentan y de ver cómo van con sus trabajos. 3. DISEÑO, DESARROLLO Y PRUEBAS El desarrollo es la parte más importante en el proceso de la programación extrema. Todos los trabajos tienen como objetivo que se programen lo más rápidamente posible, sin interrupciones y en dirección correcta. También es muy importante el diseño, y se establecen los mecanismos, para que éste sea revisado y mejorado de manera continuada a lo largo del proyecto, según se van añadiendo funcionalidades al mismo. La clave del proceso de desarrollar XP es la comunicación. La mayoría de los problemas en los proyectos son por falta de comunicación en el equipo. En XP, aparece un nuevo concepto llamado Metáfora. Su principal objetivo es mejorar la comunicación entre todos los integrantes del equipo, al crear una visión global y común de lo que se quiere desarrollar. La metáfora tiene que ser expresada en términos conocidos por los integrantes del equipo, por ejemplo comparando el sistema que se desarrollará con alguna cosa de la vida real.
  • 24. Análisis y Sistemas 20/05/2015 21 Por: Yeltsin Aldair Torres Recinos Antes de empezar a codificar se tienen que hacer pruebas unitarias, es decir: Cada vez que se quiere implementar una parte de código, en XP, se tiene que escribir una prueba sencilla, y después escribir el código para que la pase. Una vez pasada se amplía y se continúa. En XP hay una máxima que dice "Todo el código que puede fallar tiene que tener una prueba". Con estas normas se obtiene un código simple y funcional de manera bastante rápida. Por esto es importante pasar las pruebas al 100%. Respecto a la integración del soft, en XP se ha de hacer una integración continua, es decir, cada vez se tienen que ir integrando pequeños fragmentos de código, para evitar que al finalizar el proyecto se tenga que invertir grandes esfuerzos en la integración final. En todo buen proyecto de XP, tendría que existir una versión al día integrada, de manera que los cambios siempre se realicen en esta última versión. Otra peculiaridad de XP es que cada programador puede trabajar en cualquier parte del programa. De esta manera se evita que haya partes "propietarias de cada programador". Por esto es tan importante la integración diaria. Para terminar, otra peculiaridad que tiene la XP. La de fomentar la programación en parejas, es decir, hacer que los programadores no trabajen en solitario, sino que siempre estarán con otra persona. Una pareja de programadores ha de compartir el teclado, el monitor y el ratón. El principio fundamental de este hecho es realizar de manera continua y sin parar el desarrollo de código. Las parejas tienen que ir cambiando de manera periódica, para hacer que el conocimiento se difunda en el grupo. Está demostrado que de esta manera el trabajo es más eficaz y también se consigue más y mejor código.
  • 25. Análisis y Sistemas 20/05/2015 Por: Yeltsin Aldair Torres Recinos Conclusiones  Las metodologías se basan en una combinación de los modelos de proceso genéricos (cascada, evolutivo, incremental, espiral entre otros).  Los métodos estructurados comenzaron a desarrollarse a fines de los 70’s con la Programación Estructurada, luego a mediados de los 70’s aparecieron técnicas para el Diseño (por ejemplo: el diagrama de Estructura)  El modelo espiral fue propuesto inicialmente por Barry Boehm. Es un modelo evolutivo que conjuga la naturaleza iterativa del modelo MCP con los aspectos controlados y sistemáticos del Modelo Cascada.  Es una metodología RUP cuyo fin es entregar un producto de software. Se estructura todos los procesos y se mide la eficiencia de la organización.
  • 26. Análisis y Sistemas 20/05/2015 Por: Yeltsin Aldair Torres Recinos E-grafía  http://procesosdesoftware.wikispaces.com/METODOLOGIAS+PARA+DESARROLLO+ DE+SOFTWARE  http://paradigmasiut.blogspot.com/2013/04/metodologia-de-desarrollo-de- software.html  http://html.rincondelvago.com/ciclo-de-vida-del-software.html  http://procesosdesoftware.wikispaces.com/metodo+espiral  http://procesosdesoftware.wikispaces.com/METODOLOGIA+RUP  http://procesosdesoftware.wikispaces.com/METODOLOGIA+SCRUM  http://procesosdesoftware.wikispaces.com/METODOLOGIA+XP