Universidad Santiago de Cali

Ingeniera de Software









Tema:
Modelos










Presentado por:
















Ao Lectivo
2014


Modelo Incremental

Introduccin:

El modelo incremental fue propuesto por Harlan Mills en el ao 1980. Surgi el enfoque
incremental de desarrollocomo una forma de reducir la repeticin del trabajo en el proceso
de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta
adquirirexperiencia con el sistema. Este modelo se conoce tambin bajo las siguientes
denominaciones:
Mtodo de las comparaciones limitadas sucesivas.
Ciencia de salir del paso.
Mtodo de atacar el problema por ramas.

El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la filosofa
interactiva de Construccin de Prototipos. Como se muestra en la Figura 1, el modelo
incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo
en el calendario. Cada secuencia lineal produce un incremento del software. El primer
incremento generalmente es un producto esencial denominado ncleo.

En una visin genrica, el proceso se divide en 4 partes:

Anlisis
Diseo
Cdigo
Prueba



Sin embargo, para la produccin del Software, se usa el principio de trabajo en cadena o
Pipeline. Con esto se mantiene al cliente en constante contacto con los resultados
obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al
final de cada incremento a fin de que el software se adapte mejor a sus necesidades
reales. El proceso se repite hasta que se elabora el producto completo. De esta forma el
tiempo de entrega se reduce considerablemente.

El Modelo Incremental es de naturaleza interactiva brindando al final de cada incremento
la entrega de un producto completamente operacional. Este modelo es particularmente til
cuando no se cuenta con una dotacin de personal suficiente. Los primeros pasos los
pueden realizar un grupo reducido de personas y en cada incremento se aadir
personal, de ser necesario. Por otro lado los incrementos se pueden planear para
gestionar riesgos tcnicos.


Durante el proceso se trata de llevar a cabo al proyecto en diferentes partes que al final
terminar siendo la solucin completa requerida por el cliente, pero stas partes no se
pueden realizar en cualquier orden, sino que dependen de lo que el cliente este
necesitando con ms urgencia, de los puntos ms importantes del proyecto, los
requerimientos ms bsicos, difciles y con mayor grado de riesgo, ya que estos se deben
hacer al comienzo, de manera que se disminuya la dificultad y el riesgo en cada versin.
De este modo podemos terminar una aplicacin ejecutable (primera versin) que podr
ser entregada al cliente para que ste pueda trabajar en ella y el programador pueda
considerar las recomendaciones que el cliente efecte para hacer mejoras en el producto.
Estas nuevas mejoras debern esperar a ser integradas en la siguiente versin junto con
los dems requerimientos que no fueron tomados en cuenta en la versin anterior.

El modelo incremental consiste en un desarrollo inicial de la arquitectura completa del
sistema, seguido de sucesivos incrementos funcionales. Cada incremento tiene su propio
ciclo de vida y se basa en el anterior, sin cambiar su funcionalidad ni sus interfaces. Una
vez entregado un incremento, no se realizan cambios sobre el mismo, sino nicamente
correccin de errores. Dado que la arquitectura completa se desarrolla en la etapa inicial,
es necesario conocer los requerimientos completos al comienzo del desarrollo.

Al iniciar del desarrollo, los clientes o los usuarios, identifican a grandes rasgos, las
funcionalidades que proporcionar el sistema. Se confecciona un bosquejo de requisitos
funcionales y ser el cliente quien se encarga de priorizar que funcionalidades son mas
importantes. Con las funcionalidades priorizadas, se puede confeccionar un plan de
incrementos, donde en cada incremento se indica un subconjunto de funcionalidades que
el sistema entregar. La asignacin de funcionalidades a los incrementos depende de la
prioridad dada a los requisitos. Finalizado el plan de incrementos, se puede comenzar con
el primer incremento.


Caractersticas:
Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta
frecuencia.
El usuario se involucra mas.
Dificil de evaluar el costo total.
Dificil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar
como un todo.
Requiere gestores experimentados.
Los errores en los requisitos se detectan tarde.
El resultado puede ser positivo.


Ventajas:
Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se
implementa la funcionalidad parcial.
Tambin provee un impacto ventajoso frente al cliente, que es la entrega temprana de
partes operativas del software.
El modelo proporciona todas las ventajas del modelo en Cascada realimentado,
reduciendo sus desventajas slo al mbito de cada incremento.
Resulta ms sencillo acomodar cambios al acotar el tamao de los incrementos.


Desventajas:
El modelo incremental no es recomendable para casos de sistemas de tiempo real, de
alto nivel de seguridad, de procesamiento distribuido y/o de alto ndice de riesgos.
Requiere de mucha planeacin, tanto administrativa como tcnica.
Requiere de metas claras para conocer el estado del proyecto.


Conclusin:

Un modelo incremental lleva a pensar en un desarrollo modular, con entregas parciales
del producto Software denominados "incrementos" del sistema, que son escogidos en
base a prioridades predefinidas de algn modo.
El modelo permite una implementacin con refinamientos sucesivos (ampliacin y/o
mejoras).
Con cada incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien
se mejora la versin previamente implementada del producto software.


Lxico Extendido del Lenguaje (LEL)

Nmero Smbolo Tipo
1 Anlisis Verbo
2 Analista Sujeto
3 Codificacin Verbo
4 Desarrollador Sujeto
5 Diseador Sujeto
6 Diseo Verbo
7 Entregar el incremento Verbo
8 Especificacin de requisitos Objeto
9 Incremento Objeto
10 Incremento rechazado Estado
11 Incremento validado Estado
12 Modelo de arquitectura de software Objeto
13 Modelo de diseo Objeto
14 Ncleo Objeto
15 Plan de incremento Objeto
16 Producto Objeto
17 Producto completo Estado
18 Producto incompleto Estado
19 Prueba Verbo
20 Prueba de aceptacin Verbo
21 Prueba de integracin Verbo
22 Prueba unitaria Verbo
23 Tester Sujeto

Modelo de Desarrollo Concurrente


El Modelo de Desarrollo Concurrente conocido adems como Ingeniera Concurrente
dado por Davis Sitaram, se puede representar en forma de esquema como una serie de
actividades tcnicas importantes, tareas y estados asociados a ellas.
Este modelo se utiliza a menudo como el paradigma de desarrollo de aplicaciones
cliente/servidor.
Provee una meta-descripcin del proceso del software. El modelo concurrente tiene la
capacidad de describir las mltiples actividades del software ocurriendo simultneamente.
La mayora de los modelos de procesos de desarrollo del software son dirigidos por el
tiempo; cuanto ms tarde sea, ms atrs se encontrar en el proceso de desarrollo. Un
modelo de proceso concurrente est dirigido por las necesidades del usuario, las
decisiones de la gestin y los resultados de las revisiones.
El modelo de proceso concurrente define una serie de acontecimientos que dispararn
transiciones de estado a estado para cada una de las actividades de la ingeniera del
software. Durante las primeras etapas del diseo, no se contempla una inconsistencia del
modelo de anlisis. Esto genera la correccin del modelo de anlisis de sucesos, que
disparar la actividad de anlisis del estado hecho al estado cambios en espera.

Esto genera la correccin del modelo de anlisis de sucesos, que disparar la actividad
de anlisis del estado hecho al estado cambios en espera. Es un modelo de tipo de red
donde todas las personas actan simultneamente o al mismo tiempo.
Un sistema cliente/servidor se compone de un conjunto de componentes funcionales.
Cuando se aplica a cliente/servidor, el modelo de proceso concurrente define actividades
en dos dimensiones:
1. Dimensin de sistemas.
2. Dimensin de componentes.
Los aspectos del nivel de sistema se afrontan mediante tres actividades: diseo,
ensamblaje y uso.
En realidad, el modelo de proceso concurrente es aplicable a todo tipo de desarrollo de
software y proporciona una imagen exacta del estado actual de un proyecto.
La concurrencia se logra de dos formas:
1. Las actividades de sistemas y de componentes ocurren simultneamente y pueden
modelarse con el enfoque orientado a objetos.
2. Una aplicacin cliente/servidor tpica se implementa con muchos componentes, cada
uno de los cuales se pueden disear y realizar concurrentemente.
Ventajas
Excelente para proyectos en los que se conforman grupos de trabajo independientes.
Proporciona una imagen exacta del estado actual de un proyecto.
Desventajas
Si no se dan las condiciones sealadas no es aplicable.
Si no existen grupos de trabajo no se puede trabajar en este mtodo





Modelo de Desarrollo Basado en Componentes
Un componente es una pieza de cdigo preelaborado que encapsula alguna funcionalidad
expuesta a travs de interfaces estndar. Es algo muy similar a lo que podemos observar
en el equipo de msica que tenemos en nuestra sala. Cada componente de aquel aparato
ha sido diseado para acoplarse perfectamente con sus pares, las conexiones son
estndar y el protocolo de comunicacin est ya preestablecido. Al unirse las partes,
obtenemos msica para nuestros odos.
El paradigma de ensamblar componentes y escribir cdigo para hacer que estos
componentes funcionen se conoce como Desarrollo de Software Basado en
Componentes.
Desarrollo basado en componentes
El modelo de desarrollo basado en componentes incorpora muchas de las caractersticas
del modelo espiral. Es evolutivo por naturaleza y exige un enfoque interactivo para la
creacin del software. Sin embargo, el modelo de desarrollo basado en componentes
configura aplicaciones desde componentes preparados de software (clases).
El modelo de desarrollo basado en componentes conduce ala reutilizacin del software, y
la reutilizacin proporciona beneficios a los ingenieros de software. Segn estudios de
reutilizacin, QSM Associates, Inc. Informa que el ensamblaje de componentes lleva a
una reduccin del 70 % del ciclo de desarrollo un 84% del coste del proyecto y un ndice
de productividad del 26.2. No hay duda que el ensamblaje de componentes proporciona
ventajas significativas para los ingenieros del software.
El proceso unificado de desarrollo de software representa un nmero de modelos de
desarrollo basado en componentes que han sido propuestos en la industria. El lenguaje
de modelado unificado define los componentes. Utilizando una combinacin del desarrollo
incremental e interactivo, el proceso unificado define la funcin del sistema aplicando un
enfoque basado en escenarios.
El desarrollo de software basado en componentes se ha convertido actualmente en uno
de los mecanismos ms efectivos para la construccin de grandes sistemas y
aplicaciones de software.
Una vez que la mayor parte de los aspectos funcionales de esta disciplina comienzan a
estar bien definidos, la atencin de la comunidad cientfica comienza a centrarse en los
aspectos extra funcionales y de calidad, como un paso hacia una verdadera ingeniera. En
este artculo se discuten precisamente los aspectos de calidad relativos a los
componentes software y a las aplicaciones que con ellos se construyen, con especial
nfasis en los estndares internacionales que los definen y regulan, y en los problemas
que se plantean en este tipo de entornos.
Beneficios del Desarrollo de Software Basado en Componentes
El uso de este paradigma posee algunas ventajas:
1. Reutilizacin del software. Nos lleva a alcanzar un mayor nivel de reutilizacin de
software.
2. Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de
los componentes antes de probar el conjunto completo de componentes ensamblados.
3. Simplifica el mantenimiento del sistema. Cuando existe un dbil acoplamiento entre
componentes, el desabollador es libre de actualizar y/o agregar componentes segn sea
necesario, sin afectar otras partes del sistema.
4. Mayor calidad. Dado que un componente puede ser construido y luego mejorado
continuamente por un experto u organizacin, la calidad de una aplicacin basada en
componentes mejorar con el paso del tiempo
La Notacin de Componentes
Un componente puede ser algo como un control Actives; tanto un componente de la
Interfaz de usuario como un servidor de reglas de negocio.
El Diagrama de Componentes
El diagrama de componentes muestra la relacin entre componentes de software, sus
dependencias, su comunicacin su ubicacin y otras condiciones.
Interfaces
Los componentes tambin pueden exponer las interfaces. Estas son los puntos visibles de
entrada o los servicios que un componente est ofreciendo y dejando disponibles a otros
componentes de software y clases. Tpicamente, un componente est compuesto por
numerosas clases y paquetes de clases internos. Tambin se puede crear a partir de una
coleccin de componentes ms pequeos.
Los componentes y los Nodos
Un diagrama de despliegue muestra el despliegue fsico del sistema en un ambiente de
produccin (o de prueba). Muestra dnde se ubican los componentes, en qu servidores,
mquinas o hardware. Puede representar los enlaces de redes.
Restricciones
Los componentes pueden restricciones asignadas que indican el entorno en el que
operan.
Las pre-condiciones especifican lo que debe ser verdadero antes de que un componente
pueda realizar alguna funcin; las post-condiciones indican lo que debe ser verdadero
despus de que un componente haya realizado algn trabajo y los invariantes especifican
lo que debe permanecer verdadero durante la vida del componente.
Tenemos la fortuna de presenciar el nacimiento de una nueva forma de hacer software,
que traer beneficios inmensos para todos. El desarrollo de software basado en
componentes desde siempre fue la idea revolucionaria que nos llev a pensar que s era
posible el construir software de calidad en corto tiempo y con la misma calidad que la
mayora de las industrias de nuestro tiempo. Al mirar hacia atrs, vemos los increbles
avances que hemos logrado en la comprensin de la forma correcta de reutilizar el
software y el conocimiento existente, y nos asombramos cada vez ms al darnos cuenta
de que este solo es el inicio.
El desarrollo de software basado de componentes se convirti en el pilar de la Revolucin
Industrial del Software y se proyecta hoy en da en diversas nuevas formas de hacer
software de calidad con los costos ms bajos del mercado y en tiempos que antes eran
impensables. Empresas como Microsoft entendieron el potencial de esta metodologa
hace aos y hoy nos ofrecen nuevas iniciativas y herramientas que buscan llevar al
proceso de construccin de software hacia el sitial privilegiado en el que debi colocarse
desde un principio.
Anlisis del riesgo
Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas
propuestas para reducir o eliminar los riesgos.
Planificar Revisamos todo lo hecho, evalundolo, y con ello decidimos si continuamos con
las fases siguientes y planificamos la prxima actividad.
Ventajas
El anlisis del riesgo se hace de forma explcita y clara. Une los mejores elementos de los
restantes modelos. - Reduce riesgos del proyecto - Incorpora objetivos de calidad -
Integra el desarrollo con el mantenimiento
Desventajas:
Genera mucho tiempo en el desarrollo del sistema - Modelo costoso Requiere
experiencia en la identificacin de riesgos
Inconvenientes
Genera mucho trabajo adicional. Cuando un sistema falla se pierde tiempo y coste
dentro de la empresa. Exige una cierta habilidad en los analistas (es bastante difcil).




Metodos Formales

Qu es un Mtodo Formal?
Definicin: "Mtodo formal es cualquier tcnica que trate la construccin y/o el anlisis de
modelos matemticos que contribuyen a la automatizacin del desarrollo de sistemas
informticos"
El papel de los mtodos formales en la Ingeniera del Software
Los mtodos formales se basan en el empleo de tcnicas, lenguajes y herramientas
definidos matemticamente para cumplir objetivos tales como facilitar el anlisis y
construccin de sistemas confiables independientemente de su complejidad, delatando
posibles inconsistencias o ambigedades que de otra forma podran pasar inadvertidas.
En los ltimos aos, la idea de que la formalizacin matemtica del SW es el enfoque ms
apropiado para conseguir mejorar su calidad va adquiriendo cada vez ms fuerza. Los
partidarios de los mtodos formales defienden que su empleo, a lo largo de todo el ciclo
de vida, facilita el desarrollo de especificaciones claras, concisas y no ambiguas, permite
el anlisis funcional de la especificacin y posibilita el desarrollo de implementaciones
correctas respecto a su especificacin. Sin embargo los detractores aseguran que el
empleo de mtodos formales supone un volumen de trabajo considerable, aumento en los
costes y tiempo de desarrollo y que debe quedar supeditado a herramientas que lo
automaticen.
Ventajas de los mtodos formales
Se comprende mejor el sistema.
La comunicacin con el cliente mejora ya que se dispone de una descripcin clara y no
ambigua de los requisitos del usuario.
El sistema se describe de manera ms precisa.
El sistema se asegura matemticamente que es correcto segn las especificaciones.
Mayor calidad software respecto al cumplimiento de las especificaciones.
Mayor productividad

Problemtica actual de los mtodos formales
La falta de madurez en la prctica de los mtodos formales es la causa de la imposibilidad
de utilizarlos a nivel industrial tal y como se utilizan otros mtodos de la Ingeniera del
Software. Algunas de estas causas son las siguientes:

El desarrollo de herramientas que apoyen la aplicacin de mtodos formales es
complicado y los programas resultantes son incmodos para los usuarios.
Los investigadores por lo general no conocen la realidad industrial.
Es escasa la colaboracin entre la industria y el mundo acadmico, que en ocasiones se
muestra demasiado dogmtico.
Se considera que la aplicacin de mtodos formales encarece los productos y ralentiza
su desarrollo.

Clasificacin de los mtodos formales
Se pueden encontrar multitud de mtodos y tcnicas formales con lo que los criterios de
clasificacin son bastante variados. La clasificacin ms comn se realiza en base al
modelo matemtico subyacente en cada mtodo, de esta manera podran clasificarse en:
Especificaciones basadas en lgica de primer orden y teora de conjuntos: permiten
especificar el sistema mediante un concepto formal de estados y operaciones sobre
estados. Los datos y relaciones/funciones se describen en detalle y sus propiedades se
expresan en lgica de primer orden. La semntica de los lenguajes est basada en la
teora de conjuntos. Los mtodos de este tipo ms conocidos son: Z, VDM y B.
Especificaciones algebraicas: proponen una descripcin de estructuras de datos
estableciendo tipos y operaciones sobre esos tipos.
Modelo de desarrollo web
Cualquier proyecto de software se inicia por alguna necesidad de negocio; la
necesidad de corregir una deficiencia en alguna aplicacin existente; la
necesidad de adaptar una aplicacin existente a un modelo de negocio
cambiante; la necesidad de extender funciones o la necesidad de crear un nuevo
producto o servicio. El curso de Diseo de software propone un estudio prctico,
amplio, terico - aplicado del proceso de desarrollo de software. Este curso es el
ltimo, en la secuencia de correlatividad.
Diseo y programacin de software
El desarrollo de sistemas y aplicaciones basados en web representan una secuencia de
acciones de ingeniera web que comienzan con la identificacin de las necesidades del
negocio, sigue hacia una descripcin de los objetivos de la WebApp, define las macro
caractersticas y funciones y finalmente se obtienen los requisitos que conducen hacia un
modelo de anlisis.
Cada punto del programa tendr un amplio desarrollo.
Software de aplicacin
En esta etapa se obtiene la mtrica apropiada para la representacin del software
y se analizan en base a directrices establecidas y/o a datos obtenidos con
anterioridad.
Software de linea de productos
Aplicaciones basadas en web
Cualquier proyecto de software se inicia por alguna necesidad de negocio; la necesidad
de corregir una deficiencia en alguna aplicacin existente; la necesidad de adaptar una
aplicacin existente a un modelo de negocio cambiante; la necesidad de extender
funciones o la necesidad de crear un nuevo producto o servicio.
Diseo de la interfaz de usuario
El diseo de la interfaz de usuario se concentra en tres reas:
1. Diseo de interfaces entre componentes de software
2. Diseo de interfaces entre el software y otros productores / consumidores de
informacin (no humanos)
3. Diseo de interfaces entre seres humanos y la computadora
Prueba de software
El software se prueba para descubrir errores cometidos inadvertidamente en el proceso
de desarrollo.
Tcnicas de pruebas
Depuracin de errores
Mtrica de software
Ingeniera web
Atributos de los sistemas y aplicaciones basados en red
Estratos de la ingeniera de aplicaciones web (WebApp)
El proceso de ingeniera web
Mejores prcticas en ingeniera web
Formulacin y planeamiento para ingeniera web
Formulacin de sistemas basados en web
Planeamiento de proyectos para ingeniera web
Equipos y conflictos de gestin
Medicin para ingeniera web y WebApp
Las peores prcticas para proyectos WebApp
Modelado de anlisis para aplicaciones web
Requisitos para el anlisis de las WebApp
El modelado de anlisis para WebApp
El modelo de contenido
El modelo de interaccin
El modelo funcional
El modelo de configuracin
Anlisis Relacin - Navegacin
Modelado de diseo para aplicaciones web
Temas de diseo para ingeniera web
Pirmide del diseo web
Diseo de la interfaz de WebApp
Diseo de navegacin
Diseo al nivel de componentes
Patrones de diseo hipermedia
Mtodos de diseo hipermedia orientado a objetos
Mtrica de diseo para las WebApp
Cmo probar aplicaciones web
Prueba de conceptos para WebApp
El proceso de prueba
Pruebas de las bases de datos
Prueba de la interfaz del usuario
Prueba al nivel de componentes
Pruebas de navegacin
Prueba de la configuracin
Pruebas de seguridad
Pruebas del desempeo
Pruebas de carga
Pruebas de tensin
Mtrica de proceso y proyecto
Mtricas en los dominios del proceso y el proyecto
Medicin del software
Integracin de las mtricas dentro del proceso de software
Mtricas para organizaciones pequeas
Establecimiento de un programa de mtricas de software
Estimacin para proyectos de software
El proceso de planificacin del proyecto
mbito del software y factibilidad
Recursos
Estimacin de proyectos de software
Tcnicas de descomposicin
La decisin desarrollar - comprar
Gestin de la calidad
Concepto de calidad
Garanta de la calidad del software
Revisiones del software
Fiabilidad del software
Los estndares de calidad ISO 9000






Qu es UML?
(Unified Modeling Language - Lenguaje Unificado de Modelado). UML es un popular
lenguaje de modelado de sistemas de software. Se trata de un lenguaje grfico para
construir, documentar, visualizar y especificar un sistema de software. Entre otras
palabras, UML se utiliza para definir un sistema de software.
Posee la riqueza suficiente como para crear un modelo del sistema, pudiendo modelar los
procesos de negocios, funciones, esquemas de bases de datos, expresiones de lenguajes
de programacin, etc. Para ello utiliza varios tipos diferentes de diagramas, por ejemplo,
en UML 2.0 hay 13 tipos de diagramas. Estos diagramas se pueden diferenciar en tres
categoras:
Diagramas de estructura:
Diagrama de clases
Diagrama de componentes
Diagrama de objetos
Diagrama de estructura compuesta (UML 2.0)
Diagrama de despliegue
Diagrama de paquetes

Diagramas de comportamiento:
Diagrama de actividades
Diagrama de casos de uso
Diagrama de estados

Diagramas de interaccin:
Diagrama de secuencia
Diagrama de comunicacin
Diagrama de tiempos (UML 2.0)
Diagrama de vista de interaccin (UML 2.0)

Algunos programas gratuitos para modelar en UML son:
ArgoUML, Dia, gModeler, MonoUML, StarUML, TCM, Umbrello Herramienta, UMLet.
UML es una herramienta importante para el desarrollo de modelos de programacion se
pueden crear varios diagramas dependiendo el tipo de modelo en el que se haya basado
y asi poder tener una gua grfica. Se podra decir que es como cuando un arquitecto crea
sus planos para una construccin, asi para desarrollar un software necesita un un plano
para saber la estructura de software que esta desarrollando
METODOLOGA RUP
El Proceso Unificado Racional, Rational Unified Process en ingls, y sus siglas RUP, es
un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado
UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y
documentacin de sistemas orientados a objetos. El RUP no es un sistema con pasos
firmemente establecidos, sino que trata de un conjunto de metodologas adaptables al
contexto y necesidades de cada organizacin, donde el software es organizado como una
coleccin de unidades atmicas llamados objetos, constituidos por datos y funciones, que
interactan entre s.
RUP es un proceso para el desarrollo de un proyecto de un software que define
claramente quien, cmo, cundo y qu debe hacerse en el proyecto
RUP como proceso de desarrollo
RUP es explcito en la definicin de software y su trazabilidad, es decir, contempla en
relacin causal de los programas creados desde los requerimientos hasta la
implementacin y pruebas.
RUP identifica claramente a los profesionales (actores) involucrados en el desarrollo del
software y sus responsabilidades en cada una de las actividades.
Fases de desarrollo del software:
Inicio
Elaboracin
Construccin
Transicin
RUP para el desarrollo de software moderno que junto con UML trata de mejorar el
desarrollo de software no solo con una serie de pasos establecidos si no combinando
varios modelos, esto dependiendo de las necesidades de la empresa que lo solicite.

Xp

INTRODUCCION

Es una metodologa gil centrada en potenciar las relaciones interpersonales como
clave para el xito en desarrollo de software, promoviendo el trabajo en equipo,
preocupndose por el aprendizaje de los desarrolladores, y propiciando un buen clima
de trabajo. XP se basa en realimentacin continua entre el cliente y el equipo de
desarrollo, comunicacin fluida entre todos los participantes, simplicidad en las
soluciones implementadas y coraje para enfrentar los cambios. XP se define como
especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes,
y donde existe un alto riesgo tcnico.

QU ES PROGRAMACIN EXTREMA O XP?

Metodologa liviana de desarrollo de software
Conjunto de practicas y reglas empleadas para desarrollar software
Basada en diferentes ideas acerca de cmo enfrentar ambientes muy cambiantes
Originada en el proyecto C3 para Chrysler
En vez de planificar, analizar y disear para el futuro distante, hacer todo esto un
poco cada vez, a travs de todo el proceso de desarrollo

OBJETIVOS.
Establecer las mejores prcticas de Ingeniera de Software en los desarrollo de
proyectos.
Mejorar la productividad de los proyectos.
Garantizar la Calidad del Software desarrollando, haciendo que este supere las
expectativas del cliente.

CONTEXTO XP
Cliente bien definido
Los requisitos pueden (y van a) cambiar
Grupo pequeo y muy integrado (mximo 12 personas
Equipo con formacin elevada y capacidad de aprender

CARACTERSTICAS XP
Metodologa basada en prueba y error
Fundamentada en Valores y Prcticas
Expresada en forma de 12 PrcticasConjunto completoSe soportan unas a otras
Son conocidas desde hace tiempo. La novedad es juntarlas

VALORES XP

Simplicidad XP propone el principio de hacer la cosa ms simple que pueda
funcionar, en relacin al proceso y la codificacin. Es mejor hacer hoy algo simple,
que hacerlo complicado y probablemente nunca usarlo maana.

Comunicacin Algunos problemas en los proyectos tienen origen en que alguien no
dijo algo importante en algn momento. XP hace casi imposible la falta de
comunicacin.

Realimentacin Retralimentacin concreta y frecuente del cliente, del equipo y de los
usuarios finales da una mayor oportunidad de dirigir el esfuerzo eficientemente.

Coraje El coraje (valor) existe en el contexto de los otros 3 valores.(si
funcionamejralo)

EL ESTILO XP

Esta orientada hacia quien produce y usa el software
Reduce el costo del cambio en todas las etapas del ciclo de vida del sistema.
Combina las que han demostrado ser las mejores practicas para desarrollar software,
y las lleva al extremo.

PRCTICAS BSICAS DE LA PROGRAMACIN EXTREMA

Para que todo esto funcione, la programacin extrema se basa en doce "prcticas
bsicas" que deben seguirse al pie de la letra. Dichas prcticas estn definidas (en
perfecto ingls) en www.xprogramming.com/xpmag/whatisxp.htm. Aqu tienes un
pequeo resumen de ellas.

Equipo completo: Forman parte del equipo todas las personas que tienen algo que
ver con el proyecto, incluido el cliente y el responsable del proyecto.

Planificacin: Se hacen las historias de usuario y se planifica en qu orden se van a
hacer y las mini-versiones. La planificacin se revisa continuamente.

Test del cliente: El cliente, con la ayuda de los desarrolladores, propone sus propias
pruebas para validar las mini-versiones.

Versiones pequeas: Las mini-versiones deben ser lo suficientemente pequeas
como para poder hacer una cada pocas semanas. Deben ser versiones que ofrezcan
algo til al usuario final y no trozos de cdigo que no pueda ver funcionando.

Diseo simple: Hacer siempre lo mnimo imprescindible de la forma ms sencilla
posible. Mantener siempre sencillo el cdigo.

Pareja de programadores: Los programadores trabajan por parejas (dos delante del
mismo ordenador) y se intercambian las parejas con frecuencia (un cambio diario).

Desarrollo guiado por las pruebas automticas: Se deben realizar programas de
prueba automtica y deben ejecutarse con mucha frecuencia. Cuantas ms pruebas
se hagan, mejor.

Integracin continua: Deben tenerse siempre un ejecutable del proyecto que
funcione y en cuanto se tenga una nueva pequea funcionalidad, debe recompilarse y
probarse. Es un error mantener una versin congelada dos meses mientras se hacen
mejoras y luego integrarlas todas de golpe. Cuando falle algo, no se sabe qu es lo
que falla de todo lo que hemos metido.

El cdigo es de todos: Cualquiera puede y debe tocar y conocer cualquier parte del
cdigo. Para eso se hacen las pruebas automticas.

Normas de codificacin: Debe haber un estilo comn de codificacin (no importa
cual), de forma que parezca que ha sido realizado por una nica persona.

Metforas: Hay que buscar unas frases o nombres que definan cmo funcionan las
distintas partes del programa, de forma que slo con los nombres se pueda uno hacer
una idea de qu es lo que hace cada parte del programa. Un ejemplo claro es el
"recolector de basura" de java. Ayuda a que todos los programadores (y el cliente)
sepan de qu estamos hablando y que no haya mal entendidos.

Ritmo sostenible: Se debe trabajar a un ritmo que se pueda mantener
indefinidamente. Esto quiere decir que no debe haber das muertos en que no se sabe
qu hacer y que no se deben hacer un exceso de horas otros das. Al tener claro
semana a semana lo que debe hacerse, hay que trabajar duro en ello para conseguir
el objetivo cercano de terminar una historia de usuario o mini-versin.

MANEJO COLECTIVO DEL CDIGO
VENTAJAS Y DESVENTAJAS DE EXTREME PROGRAMMING

Ventajas:
Programacin organizada.
Menor taza de errores.
Satisfaccin del programador.

Desventajas:
Es recomendable emplearlo solo en proyectos a corto plazo.
Altas comisiones en caso de fallar.

CONCLUSIONES
Apostolado de metodologas exitosas
Aporte de la experiencia prctica a los modelos tericos
Enfoque de conjunto de prcticas como rompecabezas
Tecnologa en expansin
Importancia de revisitar las metodologas desde la experiencia prctica