Diferencia entre metodología xp extreme programming y estilo moprosoft

6
ASIGNATURA ADMINISTRACION DE PROYECTOS INFORMATICOS TEMA DE INVESTIGACION DIFERENCIAS ENTRE MOPROSOFT Y MEWTODOLOGIA XP ESTREME PROGRAMMING CATEDRATICO ING. RICHARD RAMIREZ

Transcript of Diferencia entre metodología xp extreme programming y estilo moprosoft

ASIGNATURA

ADMINISTRACION DE PROYECTOSINFORMATICOS

TEMA DE INVESTIGACION

DIFERENCIAS ENTRE MOPROSOFT YMEWTODOLOGIA XP ESTREME

PROGRAMMING

CATEDRATICO

ING. RICHARD RAMIREZ

DIFERENCIA ENTRE METODOLOGÍA XP EXTREME PROGRAMMING Y ESTILOMOPROSOFT

Estructuras de ambas metodología

Los procesos de MOPROSOFT abarcan las responsabilidades asociadas a la estructura de una organización que son:la Alta Dirección, Gestión y Operación.Las prácticas de planeación, seguimiento y evaluación se incluyeron en todos los procesos de gestión y administración.(Representado por la tabla No. 1 y No. 2)

Los Valores originales de la programación extrema son: simplicidad, comunicación, retroalimentación (feedback) ycoraje. Un quinto valor, respeto, fue añadido en la segunda edición de Extreme Programming Explained. (Representadopor la tabla No. 3)

Diferencias entre ambas metodologías

METODOLOGIA XP EXTREMEPROGRAMMING MOPROSOFT

Ventajas Desventajas Ventajas Desventajas

ProgramaciónOrganizada

Es recomendableemplearlo solo en

proyectos a corto plazoBasada en normas ISO Evaluaciones formales

constantes

Mejor código Reduce número departicipantes en proyecto

Facilita la comprensióndel modelo

No es practico ni fácilde usar

Múltiplesdesarrolladores

contribuyen al diseño

Conseguir su implantaciónen un equipo es

algo que puede resultardificultoso

Simplifica la relaciónentre el modelo de

procesos y laorganización

Capacidadorganizacional de

gestión de proyectos

Propiedad Colectivadel código

El equipo no estáacostumbrado a este tipo

de técnicas

Cuenta únicamente con9 procesos evitando lafragmentación que se

presenta en otrosmodelos

Capacidadorganizacional de

gestión de proyectos

Menor tasa de errores Altas comisiones en casode fallar

Capacidadorganizacional de gestión

de procesos

No es comprensiblepara los modelos ISO

9000:2000

Satisfacción delProgramador

Capacidadorganizacional de gestión

de proyectos

Mejora de procesosorientado al objetivo del

negocio

Características

MOPROSOFT METODOLOGIA XP

Las categorías de procesoscorresponden a niveles organizacionalesde administración

Desarrollo iterativo e incremental

Procesos integrados y relacionados Pruebas unitarias continuas

Foco en producto y su capitalización Programación en parejas

Capacidad organizacional de gestión deprocesos

Corrección de todos los errores

Capacidad organizacional de gestión deproyectos

Refactorización del código

Alineación con objetivos de negocio Propiedad del código compartida

Conclusiones

El propósito de MoProSoft es apoyar a las organizaciones en la estandarización de sus prácticas, en la evaluación de suefectividad y en la integración de la mejora continua. Los procesos abarcan las responsabilidades asociadas a laestructura de una organización que son: la Alta Dirección, Gestión y Operación, fue desarrollada por la AMCIS (emitidacomo norma por el NYCE. Es un sistema de gestión de la calidad de los procesos de desarrollo y mantenimiento desoftware para las PYMES.)

• Mejora la calidad del software producido por la empresa que adopta el modelo.

• Eleva la capacidad de las organizaciones para ofrecer servicios con calidad y alcanzar niveles internacionalesde competitividad.

• Integra todos los procesos de la organización y mantiene la alineación con los objetivos estratégicos.

• Inicia el camino a la adopción de los modelos ISO 9000 o CMMI.

• Sirve para implantar un programa de mejora continua.

• Permite reconocer a las organizaciones mexicanas por su nivel de madurez de procesos.

• Facilita la selección de proveedores.

• Permite obtener acceso a las prácticas de ingeniería de software de clase mundial.

Mientras que la metodología XP Extreme programming es una metodología de desarrollo ligero que se basa en laadaptabilidad de cualquier cambio como medio para aumentar las posibilidades de éxito de un proyecto. La metodologíaXP pretende evitar retrasos en la planificación, sistemas deteriorados y tasa de defectos, requisitos mal comprendidos ycambios de negocio con falsa riqueza, cambio de personal. Sus objetivos radican en satisfacer al cliente y potenciar eltrabajo en grupo, contiene cuatro variables importantes que son costo, tiempo, calidad y ámbito.

El propósito del método de evaluación de procesos EvalProSoft para la industria de software, es otorgar a laorganización solicitante, un perfil del nivel de capacidad de los procesos implantados en la organización y un nivel demadurez de capacidades

Criterios Empleados

MOPROSOFT

Se han aplicado los siguientes criterios para la elaboración de este modelo de procesos:

La estructura de procesos resultante debe ser acorde a la estructura generalmente empleada por lasorganizaciones de la industria del software (alta dirección, gestión y operación)

La alta dirección tiene un papel importante a través de la planificación estratégica. Debe actuar como promotordel buen funcionamiento de la organización a través de su implicación en la revisión y mejora continua delmodelo.

El modelo considera a la gestión como proveedora de recursos, procesos y proyectos; así como responsable dela vigilancia del cumplimiento de los objetivos estratégicos de la organización.

El modelo considera a la operación como ejecutora de los proyectos de desarrollo y mantenimiento de software.

El modelo integra con claridad y consistencia los elementos indispensables para la definición de los procesos ylas relaciones entre ellos.

Moprosoft se basa en los modelos de procesos ISO 9001:2000, en las áreas de procesos de los niveles 2 y 3de CMM-SW: CMM-SW v.1.1., en el marco general ISO/IEC15504 y en prácticas y conceptos de PMBOKYSWEBOK.

METODOLOGIA XP EXTREME PROGRAMMING

Las características fundamentales del método son:

Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.

Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Seaconseja escribir el código de la prueba antes de la codificación. Véase, por ejemplo, las herramientas deprueba JUnit orientada a Java, DUnit orientada a Delphi y NUnit para la plataforma.NET. Estas dos últimasinspiradas en JUnit.

Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en unmismo puesto. Se supone que la mayor calidad del código escrito de esta manera -el código es revisado ydiscutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.

Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un representantedel cliente trabaje junto al equipo de desarrollo.

Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.

Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad ymantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorizaciónno se ha introducido ningún fallo.

Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en gruposde trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte delproyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.

Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadirfuncionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tenerun poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.

La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta másfácil identificar qué se debe y qué no se debe hacer. Cuanto más simple es el sistema, menos tendrá quecomunicar sobre éste, lo que lleva a una comunicación más completa, especialmente si se puede reducir elequipo de programadores.

ANEXOS

BIBLIOGRAFIA

Beck, Kent. Smalltalk Best Practice Patterns. Upper SaddleRiver, N.J.: Prentice Hall, 1997.

Fowler, Martin. Refactoring: Improving the Design of ExistingCode.Addison-Wesley.

http://www.esp.uem.es/jccortizo/xp.pdf http://www.extremeprogramming.org