Sei sulla pagina 1di 5

lOMoARcPSD|3812628

Resumen Pressman Capitulo 3

Ingeniería en Software (Universidad Nacional de La Rioja)

StuDocu is not sponsored or endorsed by any college or university


Downloaded by Jesus Alejandro (razorjesus2610@gmail.com)
lOMoARcPSD|3812628

CAPITULO Nº 3

DESARROLLO AGIL

Cualquier proceso del sw ágil se caracteriza por la forma en la que aborda ciertas suposiciones claves
en los proyectos Sw:

1-Es difícil predecir que requerimientos de Sw quedaran y cuales cambiaran o como cambiaran, las
prioridades de los clientes a medida que avanza el proyecto.
2-En vs. Tipos de Sw el diseño y la construcción deben ejecutarse simultáneamente, pero es difícil
“predecir” cuanto diseño se necesita antes de usar la construcción para diseñarlo.
3-El análisis, diseño, construcción y pruebas no son predecibles ¿cómo crear entonces un proceso que
maneje lo impredecible? Un proceso ágil debe ser adaptable, pero para ello debe avanzar,
incrementarse y requiere retroalimentación c/ el cliente y en esto necesita un “prototipo operativo”.
Deben entregarse incrementos de Sw (prototipos ejecutables o porción de SO) en periodos cortos de
tiempo así la adaptación va junto c/ el cambio (impredecible). Este enfoque interactivo permite que el
cliente evalúe regularmente el incremento de Sw.

FACTORES HUMANOS

El desarrollo ágil se centra en las habilidades de las personas por la cual el proceso debe adaptare a las
personas y sus necesidades y no al revés. Un equipo ágil de Sw debe haber características claves que
deben compartir y son:
Competencia: incluye el talento innato, habilidades relacionadas c/ el Sw y el conocimiento Gral. del
proceso que el equipo eligió aplicar.
Enfoque común: todos los miembros del equipo ágil (aunque realicen distintas tareas o tengan
distintas habilidades).
Colaboración: crear información que ayude a los participantes a entender el trabajo del equipo.
Habilidad para tomar decisiones: tener autoridad para decidir sobre asuntos técnica y del proyecto.
Capacidad para resolver problemas difusos: el equipo debe aceptar que quizás el problema que
resuelven ahora tal vez no sea el que necesite resolver.
Confianza y respeto mutuo: son necesidades para crear un equipo “pegado” donde “su” tejido tan
fuerte hace que el todo es más que la suma de las partes.
Organización propia: el equipo ágil se organiza a si mimo para hacer el trabajo organiza el proceso que
mejor se adapte a su ambiente local, programa el trabajo para lograr del mejor modo la entrega del
incremento Sw.
VALORES XP
Beck define 5 valores fundamentales para todo trabajo realizado como parte de XP comunicación,
simplicidad, retroalimentación, valentía y respeto.
COMUNICACIÓN: XP enfatiza la estrecha colaboración pero informal (verbal) entre clientes y
desarrolladores, metáforas para comunicar conceptos importantes, la retroalimentación continúa y
evita la documentación voluminosa como medio de comunicación.
SIMPLICIDAD: xp restringe a los desarrolladores para que diseñen solo para necesidades inmediatas y
no para las futuras.

Downloaded by Jesus Alejandro (razorjesus2610@gmail.com)


lOMoARcPSD|3812628

Retroalimentación: se obtiene de 3 fuentes: el software implementado, el cliente y otros miembros del


equipo de software. XP usa la prueba unitaria como táctica principal de prueba.
VALENTIA: un término más apropiado sería disciplina. Un equipo XP ágil debe tener disciplina
(valentía) para diseñar para hoy y reconocer que los requerimientos futuros tal vez combinen mucho.
RESPETO: en un equipo agil debe haber respeto entre sus miembros, entre otros participantes, etc.

PROCESO XP

La programación extrema usa un enfoque orientado a objetos como paradigma de desarrollo, con
reglas y prácticas que ocurren en el contexto de 4 actividades estructurales: planeación, diseño,
codificación y pruebas.

PLANEACION: o juego de planeación, comienza escuchando, lo que lleva a crear “historias” (historias
del usuario) que describen las características del software que se va a elaborar. Cada historia es escrita
por el cliente y le asigna una prioridad o valor con base en el valor general de la función para el
negocio. Después los miembros del equipo XP evalúan cada historia y le asignan un costo mediado en
semanas de desarrollo. Si la historia requiere más de 3 semanas de desarrollo se pide al cliente que la
descomponga en historias más chicas asignándole un nuevo valor y costo.
Clientes y desarrolladores trabajan juntos para decidir cómo agrupar las historias en el siguiente
incremento de software que desarrollara el equipo XP. Una vez que se llega a un compromiso sobre la
entrega (fecha y otros aspectos del proyecto) el equipo XP ordena las historias que serán desarrolladas
en una de 3 formas:
1-Todas las historias se implementaran en pocas semanas.
2-Las historias con más valor entraran a la programación de actividades y se implementaran en primer
lugar.
3-Las historias con más riesgo formaran parte de la programación de actividades y se implementaran
en primer lugar.
Después de la primera entrega del proyecto (incremento del software) el equipo XP calcula la velocidad
de este. La velocidad del proyecto es el número de historias de los clientes implementado en la
primera entrega. La velocidad del proyecto se usa para:

1-Ayudar a estimar las fechas de entrega y programar las entregas posteriores.

2-Determinar si se ha hecho un gran compromiso para todas las historias durante el desarrollo del
proyecto. Si esto ocurre, se modifica el contenido de las entregas o se cambian las fechas de entrega
final.

DISEÑO: XP sigue le principio MS (Mantenerlo sencillo). Un diseño sencillo siempre se prefiere sobre
uno complejo. XP estimula el uso de la tarjeta CRC como mecanismo eficaz para pensar en el software
en un contexto orientado a objetos. Las tarjetas CRC (clase-responsabilidad-colaborador) identifican y
organizan las clases orientadas a objetos que son importantes para el incremento actual del software.
Estas tarjetas spon el único producto del trabajo de diseño que se genera para el proceso XP.

Downloaded by Jesus Alejandro (razorjesus2610@gmail.com)


lOMoARcPSD|3812628

CODIFICACION: Después que las historias han sido desarrolladas y se hizo el diseño preliminar, el
equipo no inicia la codificación sino que desarrolla pruebas unitarias a cada uno de las historias que se
incluirán en la entrega en curso. Luego de creada la prueba unitaria el desarrollador esta mejor
capacitado para centrarse en lo que debe implementarse para pasar la prueba. Una vez que el código
está terminado se le aplica una prueba unitaria con lo que se obtiene retroalimentación instantánea
para los desarrolladores. Un concepto clave en la codificación y del que más se habla en la XP es la
“programación por parejas”. XP recomienda que 2 personas trabajen juntos en una estación de trabajo
con el objeto de crear código para una historia. Esto da un mecanismo para la solución de problemas
en tiempo real. A medida que las parejas de programadores terminan su trabajo, el código que
desarrollan se integra con el trabajo de los demás.

PRUEBAS: la creación de pruebas unitarias antes de que comience la codificación es un elemento cave
del enfoque de XP. Las pruebas unitarias que se crean deben implementarse con el uso de una
estructura que permita automatizarlos.
Las pruebas de aceptación XP o “pruebas del cliente”, son especificadas por el cliente. Estas pruebas
se derivan de las historias de los usuarios que se han implementado como parte de la liberación del
SW.

XP INDUSTRIAL
La programación externa industrial (IXP) incorpora 6 prácticas diseñadas para garantizar que un
proyecto funcione c/ éxito para proyectos significativos dentro de una organización grande:
1) Evaluación de la factibilidad: antes de iniciar un proyecto IXP la organización debe hacer una
“evaluación de factibilidad” para averiguar si:
a) existe una ambiente apropiado de desarrollo que acepte IXP:
b) el equipo estará formado por los participante adecuados.
c) La organización tiene un programa de calidad que apoya la mejora continua.
d) La cultura organizacional apoyara los nuevos valores de un equipo ágil
2) Comunidad el Proyecto: en IXP los miembros de la comunidad y sus papeles debe definirse de
modo explícito, así como establecer los mecanismos para la comunicación y coordinación entre los
integrantes de la comunidad.
3) Calificación del proyecto: la calificación también analiza el contexto de proyecto para determinar
como complementa, extiende o remplaza sistemas o procesos existentes.
4) Adm. Orientada a pruebas: establecen destinos medibles y luego define los mecanismos para
determinar si se han alcanzado o no.
5) Retrospectivas: después de entregar un incremento el sw el equipo XP, realiza una revisión
técnica llamada “retrospectiva” que examinan temas eventos, etc. cuyo objetivo es mejorar e
proceso IXP
6) Aprendizaje continuo: los miembros del equipo Xp son invitados e incentivados a aprender
nuevos métodos y técnicas que conduzcan a una calidad más alta de producto. IXP modifica
algunas de las existentes en XP. El desarrollo impulsado por la historia DIH insiste en que las
historias de las pruebas de aceptación se escriban antes de generar una sola línea de código. El

Downloaded by Jesus Alejandro (razorjesus2610@gmail.com)


lOMoARcPSD|3812628

diseño implementado por el dominio DID es una mejora sobre el concepto de la “metáfora del
sistema” usado en XP: el DID sugiere la creación evolutiva de un modelo de dominio que
represente con exactitud como piensan los expertos del dominio en su materia.

DEBATE XP

Volatilidad de los requerimientos


Necesidades conflictivas del cliente
Requerimientos se expresan informalmente
Falta de un diseño formal

SCRUM

Los principios SCRUM se usan para guiar actividades de desarrollo dentro de un proceso de análisis que
incorpora las sgtes. Actividades estructurales: requerimientos, análisis, diseño, evolución y entrega.
Dentro de cada actividad estructural las tareas de trabajo ocurren c/ un patrón del proceso llamado
sprint.
Scrum acentúa el uso de un conjunto de patrones del proceso del Sw que han demostrado ser eficaces
en proyectos c/ plazos de entrega muy apretados, requerimientos cambiantes y negocios críticos. c/u
de estos patrones de proceso define un grupo de acciones de desarrollo que son 4:
1. Retraso: lista de prioridades de requerimientos o característica del proyecto que dan al cliente un
valor del negocio
2. Sprints: unidades de trabajo que se necesitan para alcanzar un requerimiento definido en el
retraso que debe ajustarse en una caja de tiempo “predefinida”.
3. Reuniones Scrum: reuniones breves (aprox.15mtos.) que el equipo Scrum efectúa a diario. Hay 3
ptas. claves que deben responder todos los miembros del equipo:
* ¿Qué hiciste desde la última reunión del equipo?
* ¿Qué obstáculos están encontrando?
¿Qué planeas hacer mientras llega la sgte reunión del equipo?

Maestro srum: líder del equipo, dirige la junta, evalúa las respuestas de cada persona: esta junta ayuda
al equipo a descubrir problemas potenciales tan pronto como sea posible.
4- Demostraciones preliminares: entregar el incremento de Sw al cliente de modo que las
funcionalidad que se hay implementado pueda demostrase al cliente y este pueda evaluarlo.

Downloaded by Jesus Alejandro (razorjesus2610@gmail.com)

Potrebbero piacerti anche