Open Up - Fase de Elaboracion

OPEN UP U P – FASE FASE DE ELABORACIÓN

ITERACIÓN: ELABORAR ITERACIÓN [1..N] La mayoría de las actividades durante una iteración típica en la fase de elaboración suceden en paralelo. En esencia, los principales objetivos de Elaboración están relacionados con una mejor comprensión de los requisitos, la creación y el establecimiento de una línea de base de la arquitectura para el sistema, y mitigar los riesgos de alta prioridad. La siguiente tabla resume los objetivos de la fase de elaboración y qué actividades aborda cada objetivo:

ITERACIÓN: ELABORAR ITERACIÓN [1..N] La siguiente tabla resume los objetivos de la fase de elaboración y qué actividades aborda cada objetivo: OBJETIVOS DE FASE

ACTIVIDADES QUE ABORDA CADA OBJETIVO

Obtener una comprensión más detallada de los requisitos

Identifcar y Refne Requisitos

Diseñar, implementar, validar, y defnir la línea base de la arquitectura

Desarrollar la Arquitectura Desarrollar Incremento Incremento de la Solución Solución de rueba

!iti"ar los ries"os esenciales, y producir #oras e$actas y costo estimado

lanifcar y "estionar iteración

ESTRUCTURA DE LA DIVISIÓN DEL TRABAJO Esta plantilla iteración define las actividades y los roles asociados y productos de trabajo! reali"adas en una iteración típica en la fase de elaboración.

ESTRUCTURA DE LA DIVISIÓN DEL TRABAJO #lujo de $rabajo

ACTIVIDAD: PLANEAR Y MANEJAR LA ITERACIÓN %nicia la iteración y permiten a los miembros del equipo enrolarse a las tareas de desarrollo. &onitorear y comunicar el estado del proyecto a los interesados e'ternos.  %dentificar y manejar e'cepciones y problemas.

ACTIVIDAD: PLANEAR Y MANEJAR LA ITERACIÓN DESCRIPCIÓN Esta actividad se lleva a cabo durante todo el ciclo de vida del proyecto. El objetivo de esta actividad es identificar riesgos y problemas lo suficientemente temprano para que pueden ser mitigados, establecer las metas para la iteración, y para apoyar al equipo de desarrollo para alcan"ar estos objetivos. El director del proyecto y el equipo lan"an la iteración. La priori"ación de trabajo para una iteración dada toma lugar. El director del proyecto, las partes interesadas y los miembros del equipo están de acuerdo en lo que se supone sera desarrollado durante esa iteración.

ACTIVIDAD: PLANEAR Y MANEJAR LA ITERACIÓN DESCRIPCIÓN Los miembros del equipo se asignan a los elementos de trabajo que van a desarrollar en esa iteración. (ada miembro del equipo descompone los elementos de trabajo en tareas de desarrollo y estima el esfuer"o. Esto proporciona una estimación más precisa de la cantidad de tiempo que se utili"ara, y de lo que puede lograrse de manera realista, en una iteración dada.

ACTIVIDAD: PLANEAR Y MANEJAR LA ITERACIÓN DESCRIPCIÓN (onforme la iteración se ejecuta, el equipo se re)ne regularmente para informar del estado del trabajo reali"ado, el trabajo a *acer a continuación, y problemas que bloquean el progreso. En algunos proyectos, esta comprobación de estado se produce en las reuniones diarias, lo que permite una comprensión más precisa de cómo el trabajo en la iteración está progresando. +i es necesario, el equipo *ace correcciones para lograr lo que se *abía previsto. La idea general es que los riesgos y los problemas son identificados y gestionados a través de la iteración, y todo el mundo conoce el estado del proyecto en tiempo y forma.

ACTIVIDAD: PLANEAR Y MANEJAR LA ITERACIÓN DESCRIPCIÓN urante las evaluaciones de la iteración, el criterio clave para el é'ito es demostrar que la funcionalidad planeada se *a implementado. Las lecciones aprendidas son capturadas con el fin de modificar el proyecto o mejorar el proceso. +i el final de iteración coincide con el final de fase, comprobar que se *an cumplido los objetivos para esa fase.

ACTIVIDAD: PLANEAR Y MANEJAR LA ITERACIÓN ESTRUCTURA DE LA DIVISIÓN DE TRABAJO - lanear la %teración. - reparar el Entorno. - &anejar la %teración. - Esquema de lan de espliegue. - Evaluar /esultados.

TAREA: PLAN DE ITERACIÓN lanificar el alcance y las responsabilidades de una sola iteración.

PROPÓSITO El propósito de esta tarea es identificar el siguiente incremento de capacidad del sistema, y crear un plan detallador para lograr esa capacidad dentro de una sola iteración.

TAREA: PLAN DE ITERACIÓN DESCRIPCIÓN urante la planificación del proyecto, se identifican las iteraciones, pero las estimaciones tienen una incertidumbre aceptable debido a la falta de detalle en el inicio del proyecto.  Esta tarea se repite para cada iteración dentro de una liberación reléase!. Esto permite al equipo aumentar la precisión de las estimaciones para una iteración, a medida que se conoce más detalle a lo largo del proyecto.  0seg)rese de que el equipo se compromete en una cantidad ra"onable de trabajo para la iteración, con base en el desempe1o del equipo de iteraciones anteriores.

TAREA: PLAN DE ITERACIÓN PASOS: - riori"ar la Lista de %tems de $rabajo. - efinir los objetivos de la iteración. - %dentificar y revisar los riesgos - (omprometer trabajo para la iteración. - efinir criterios de evaluación - /efinar la definición del proyecto y el alcance

ACTIVIDAD: IDENTIFIAR Y REFINAR REQUERIMIENTOS etalla un conjunto de requisitos uno o más casos de uso, requerimientos de escenarios o de todo el sistema!.

ACTIVIDAD: IDENTIFIAR Y REFINAR REQUERIMIENTOS DESCRIPCIÓN Esta actividad describe las tareas que se reali"an para obtener, especificar, anali"ar y validar un subconjunto de los requisitos del sistema antes de la implementación y verificación. Esto no implica que todos los requisitos se detallan antes de comen"ar la implementación. &ás bien, esta actividad se reali"a a lo largo del ciclo de vida con las partes interesadas y con todo el equipo de desarrollo2 colaborando para asegurar que un conjunto claro, consistente, correcto, verificable y viable de los requisitos está disponible, seg)n sea necesario, para manejar la implementación y verificación.

ACTIVIDAD: IDENTIFIAR Y REFINAR REQUERIMIENTOS DESCRIPCIÓN urante el Inicio, la atención se centra en la obtención de un acuerdo sobre el problema a resolver, la recopilación de las necesidades de las partes interesadas, y la captura de las características de alto nivel del sistema.

ACTIVIDAD: IDENTIFIAR Y REFINAR REQUERIMIENTOS DESCRIPCIÓN urante la Elaboración, el foco se despla"a a la definición de la solución. Esta consiste en la b)squeda de esos requerimientos que tienen el mayor valor para las partes interesadas, que son particularmente desafiantes o de riesgo, o que son de gran importancia arquitectónica.  0 continuación se describen los requisitos que se priori"an, a través de la lista de elementos de trabajo, para su implementación en las iteraciones iniciales! con el suficiente detalle para validar el entendimiento de los requerimientos por parte del equipo de desarrollo, para asegurar la concurrencia con las partes interesadas, y para permitir el comien"o del desarrollo de soft3are. ara cada uno de estos requisitos, definir los casos de prueba asociados para garanti"ar que los requerimientos son verificables, y proporcionar la orientación necesaria para la verificación y validación.

ACTIVIDAD: IDENTIFIAR Y REFINAR REQUERIMIENTOS DESCRIPCIÓN urante la Construcción, el foco se perfeccionamiento de la definición del sistema.

despla"a

*acia

el

Esto consiste en detallar los requisitos restantes y casos de prueba asociados como sea necesario para manejar la implementación y verificación, y la gestión de cambio de requerimientos.

ACTIVIDAD: IDENTIFIAR Y REFINAR REQUERIMIENTOS ESTRUCTURA DE LA DIVISIÓN DE TRABAJO - %dentificar y elinear /equerimientos. - etallar Escenarios de (asos de 4so - etallar /equerimientos que abarcan todo el +istema - (rear (asos de rueba

TAREA: IDENTIFICAR Y DELINEAR REQUERIMIENTOS Esta tarea describe cómo identificar y delinear los requisitos para el sistema de modo que el alcance del trabajo se puede determinar.

PROPÓSITO El propósito de esta tarea es identificar y capturar los requisitos funcionales y no funcionales para el sistema. Estos requisitos constituyen la base de la comunicación y el acuerdo entre las partes interesadas y el equipo de desarrollo en lo que el sistema debe *acer para satisfacer las necesidades de las partes interesadas. El objetivo es comprender los requisitos en un alto nivel de modo que el ámbito de trabajo inicial se puede determinar. #uturos análisis serán llevados a cabo para detallar estos requerimientos antes de su implementación.

TAREA: IDENTIFICAR Y DELINEAR REQUERIMIENTOS

TAREA: IDENTIFICAR Y DELINEAR REQUERIMIENTOS PASOS - 5btener información. - %dentificar y capturar términos del dominio. - %dentificar los tipos de requerimientos relevantes al sistema. - %dentificar y capturar casos de uso y escenarios. - %dentificar y capturar requerimientos que abarcan todo el sistema. - Lograr la concurrencia. - %dentificar y capturar (asos de 4so y 0ctores en un &odelo de (asos de 4so.

TAREA: DETALLA ESCENARIOS DE CASOS DE USO Esta tarea describe como detallar escenarios de casos de uso para el sistema.

PROPÓSITO El propósito de esta tarea es describir escenarios de casos de uso en suficiente detalle para validar la comprensión de los requerimientos, para garanti"ar la concurrencia con las e'pectativas de las partes interesadas, y para permitir el comien"o del desarrollo de soft3are.

TAREA: DETALLA ESCENARIOS DE CASOS DE USO

TAREA: DETALLA ESCENARIOS DE CASOS DE USO PASOS - etallar casos de uso y escenarios - etallar el glosario de términos. - Lograr la concurrencia. -  0ctuali"ar el &odelo de (asos de 4so.

(56+%E/0(%56E+ (L07E+ ara evitar el re trabajo innecesario, sólo los escenarios de casos de uso que están programados para su implementación en el corto pla"o en la siguiente iteración o dos! deben ser detalladas. 6o todos los escenarios de casos de uso requieren detalle.

TAREA: DETALLAR REQUERIMIENTOS QUE ABARCAN TODA LA APLICACIÓN

Esta tarea detalla uno o más requerimientos que no se aplican a un caso de uso específico.

PROPÓSITO El propósito de esta tarea es describir uno o más requisitos de todo el sistema con suficiente detalle para validar la comprensión de los requerimientos, para garanti"ar la concurrencia con las e'pectativas de las partes interesadas, y para permitir el inicio del desarrollo del soft3are.

TAREA: DETALLAR REQUERIMIENTOS QUE ABARCAN TODA LA APLICACIÓN

TAREA: DETALLAR REQUERIMIENTOS QUE ABARCAN TODA LA APLICACIÓN

0+5+: etalllar requerimientso que abarcan todo el sistema. etallara glosario de términos Lograr concurrencia.

CONSIDERACIONES CLAVES ara evitar re trabajo innecesario, sólo aquellos requerimientos que están programados para su implementación en el corto pla"o en la siguiente iteración o dos! deben ser detallados.

TAREA: CREAR CASOS DE PRUEBA esarrollar casos de prueba y datos de prueba para testear los requerimientos.

PROPÓSITO ara lograr un entendimiento compartido de las condiciones específicas que la solución debe cumplir.

TAREA: CREAR CASOS DE PRUEBA

TAREA: CREAR CASOS DE PRUEBA PASOS - /evisar los requerimientos a ser testeados. - %dentificar (asos de rueba relevantes. - elinear los (asos de rueba. - %dentificar las necesidades de datos de prueba - (ompartir y evaluar los (asos de rueba.

TAREA: CREAR CASOS DE PRUEBA CONSIDERACIONES CLAVE esarrollar casos de prueba en paralelo con los requerimientos para que los analistas y los sta8e*olders pueden ponerse de acuerdo con las condiciones específicas de satisfacción para cada requerimiento. Los casos de prueba act)an como criterios de aceptación mediante la ampliación de la intención del sistema a través de escenarios reales de uso. $*e test cases act as acceptance criteria by e'panding on t*e intent of t*e system t*roug* actual scenarios of use! Esto permite a los miembros del equipo medir el progreso en términos de pasar casos de prueba.

DESARROLLAR LA ARQUITECTURA esarrollar los requisitos de gran importancia arquitectónica priori"ados para esta iteración.

DESARROLLAR LA ARQUITECTURA DESCRIPCIÓN Esta actividad refina la arquitectura inicial de alto nivel en el soft3are de trabajo. El objetivo es producir soft3are estable que aborde adecuadamente los riesgos técnicos en su alcance. El arquitecto y desarrolladores trabajan juntos para: - /efinar el boceto inicial de la arquitectura en los elementos de dise1o concretos. -  0segurar que las decisiones de arquitectura son capturadas y comunicadas adecuadamente -  0segurar que el equipo tiene suficiente información para *acer posible el soft3are a desarrollar  -  0segurar que los requisitos que fueron priori"ados para la presente iteración se abordan adecuadamente en el soft3are

DESARROLLAR LA ARQUITECTURA DESCRIPCIÓN En un proyecto iterativo, el equipo no debe tratar de desarrollar la arquitectura de todo el proyecto en una sola pasada. &ás bien, deben centrarse en el cumplimiento de los requisitos en ámbito para la iteración actual, mientras se toma de decisiones en el conte'to del proyecto más amplio.

DESARROLLAR LA ARQUITECTURA DESGLOSE DE ELEMENTOS - esarrollar +olución %ncremental. - /efinar la 0rquitectura.

ACTIVIDAD: DESARROLLAR SOLUCIÓN INCREMENTAL ise1ar, implementar, probar e integrar la solución para un requerimiento dentro de un conte'to dado.

PROPÓSITO - ara los desarrolladores: ara crear una solución para el elemento de trabajo para los que son responsables - ara los administradores de proyectos: ara tener una forma de dar seguimiento al estado del proyecto basada en metas.

ACTIVIDAD: DESARROLLAR SOLUCIÓN INCREMENTAL DESCRIPCIÓN Intr!"##$%n Ejecute esta actividad como una forma de llevar a cabo la planificación y ejecución basada en objetivos. El trabajo es asumido por los desarrolladores, y al progreso del trabajo se reali"a un seguimiento basado en las metas alcan"adas usando el código fuente dise1ado, testeado en desarrollo, e integrado.

ACTIVIDAD: DESARROLLAR SOLUCIÓN INCREMENTAL DESCRIPCIÓN Cnt&'t !& ( )"& *& &*t+ !&*,rr((,n! 4n conte'to se puede especificar cuando se asigna un requerimiento a desarrollar, especificando la amplitud del requerimiento a desarrollar en una iteración. El desarrollo puede enfocarse en una capa como la interfa" de usuario, la lógica de negocio, o el acceso de base de datos!, en un componente, y así sucesivamente.

ACTIVIDAD: DESARROLLAR SOLUCIÓN INCREMENTAL DESCRIPCIÓN Cnt&'t !& ( )"& *& &*t+ !&*,rr((,n! +i se especifica un conte'to o no, la responsabilidad de los desarrolladores es crear un dise1o y la implementación para este requerimiento. El desarrollador también escribe y reali"a pruebas de desarrollo contra la implementación para asegurarse de que funciona como está dise1ada, tanto como una unidad así como integran en el código base.

ACTIVIDAD: DESARROLLAR SOLUCIÓN INCREMENTAL DESCRIPCIÓN V$*$%n -&n&r,( !& ("/ !& tr,0,/ Los cambios típicos requieren un poco de esfuer"o en el dise1o de la solución antes de pasar a la implementación, incluso si es sólo un ejercicio mental que resulta en ning)n producto de trabajo a largo pla"o. El dise1o de los cambios triviales para la implementación e'istentepara, por ejemplo, soportar alg)n requerimiento! podría ser evidente en el conte'to de la arquitectura y el dise1o e'istente.

ACTIVIDAD: DESARROLLAR SOLUCIÓN INCREMENTAL DESCRIPCIÓN V$*$%n -&n&r,( !& ("/ !& tr,0,/ 4na ve" que la organi"ación de la solución técnica es claro, definir pruebas para desarrolladores que comprobar la aplicación. Este enfoque basado en pruebas asegura que las consideraciones de dise1o *an *ec*o ocurrido antes de que se codifica la solución. Las pruebas se reali"an en la delantera y, si no, definir claramente los criterios para determinar si la aplicación funciona como está previsto.

ACTIVIDAD: DESARROLLAR SOLUCIÓN INCREMENTAL DESCRIPCIÓN V$*$%n -&n&r,( !& ("/ !& tr,0,/ 4na ve" que la organi"ación de la solución técnica es clara, definir pruebas de desarrollo que comprueben la implementación. Este enfoque basado en pruebas asegura que las consideraciones de dise1o efectivamente *an tomado lugar antes de que se codifique la solución. Las pruebas se reali"an adelante, y si fallan, se deben definir claramente los criterios para determinar si la implementación funciona como está previsto.

ACTIVIDAD: DESARROLLAR SOLUCIÓN INCREMENTAL DESCRIPCIÓN V$*$%n -&n&r,( !& ("/ !& tr,0,/ Las pruebas fallidas conducen a una implementación de la solución, al término de los cuales se ejecuta las pruebas de nuevo. Este bucle más interno de implementación y pruebas de desarrollo se repite *asta que pasen las pruebas. asar las pruebas no significa necesariamente que la solución es adecuada y de alta calidad. Es adecuada para revisar el dise1o en este punto. Ese camino vuelve de nuevo a través del proceso, ya que cualquier cambio en el dise1o podrían afectar las pruebas de desarrollo y la implementación.

ACTIVIDAD: DESARROLLAR SOLUCIÓN INCREMENTAL DESCRIPCIÓN V$*$%n -&n&r,( !& ("/ !& tr,0,/ 4na ve" que las pruebas pasan y el dise1o de la solución es apropiado, *ay un posible loopbac8 adicional. Lo mejor es mantener los bucles internos de dise1o evolutivo, basado en pruebas, lo más ajustado posible. Empe"ar con una solución de dise1o a peque1a escala para una parte del elemento de trabajo, definir una o dos pruebas para la implementación de esta parte de la solución, pasar la prueba, verificar la calidad, y luego continuar en una prueba de primera manera *asta que la parte del dise1o está trabajando. Luego, en el bucle más e'terno de la actividad, volver al elemento de trabajo y dise1ar otro peda"o para acercarse a su finali"ación.

ACTIVIDAD: DESARROLLAR SOLUCIÓN INCREMENTAL FLUJO DE TRABAJO

ACTIVIDAD: DESARROLLAR SOLUCIÓN INCREMENTAL %7%+%96 EL $/00;5 -

ise1ar la solución %mplementar ruebas de esarrollo %mplementar la +olución Ejecutar ruebas de esarrollo %ntegrar y (onstruir la 0plicación (reate  (reate uild!. uild !.

TAREA: DISEAR LA SOLUCIÓN %dentificar los elementos y dise1ar las interacciones, el comportamiento, las relaciones, y los datos necesarios para reali"ar algunas funcionalidad. /eproducir el dise1o visualmente para ayudar a resolver el problema y comunicar la solución.

PROPÓSITO El propósito de esta tarea es describir los elementos del sistema para que soporte el comportamiento requerido, son de alta calidad y se acoplan dentro de la arquitectura.

TAREA: DISEAR LA SOLUCIÓN

TAREA: DISEAR LA SOLUCIÓN DESCRIPCIÓN PRINCIPAL Esta tarea es sobre dise1ar parte del sistema, no todo el sistema. +e debe aplicar sobre la base de un peque1o subconjunto de requerimientos. Los requisitos que conducen el dise1o podrían ser requerimientos funcionales basados en escenarios, requerimientos no funcionales, o una combinación.

TAREA: DISEAR LA SOLUCIÓN DESCRIPCIÓN PRINCIPAL Esta tarea se puede aplicar en un conte'to específico, como los elementos de acceso de base de datos requeridos por alg)n escenario. En este caso la tarea se podría aplicar de nuevo más adelante para *acer frente a un conte'to diferente en los mismos requerimientos. $enga en cuenta que para construir en realidad alguna funcionalidad de valor para los usuarios, todos los conte'tos típicamente necesitan ser dise1ados e implementados. or ejemplo, para utili"ar realmente cierta capacidad del sistema, tendrán que *aber sido dise1ados e implementados todos su conte'tos como la interfa" de usuario, reglas de negocio, acceso a base de datos, etc.

TAREA: DISEAR LA SOLUCIÓN DESCRIPCIÓN PRINCIPAL or co*esión y completitud, esta tarea se describe como un paso de e'tremo a e'tremo de dise1o de un escenario de uso del sistema. En la práctica, esta tarea será revisada tantas veces cuando el dise1o se consideró por primera ve", las porciones son implementadas, más dise1o se reali"a en base a lo aprendido, etc. La aplicación más saludable de esta tarea es que está estrec*amente apro'imada a la implementación.

TAREA: DISEAR LA SOLUCIÓN DESCRIPCIÓN PRINCIPAL +i esta tarea se está reali"ando en un elemento arquitectónico significativo los resultados de este dise1o deben ser referenciados por la Arquitectura Técnica.

TAREA: DISEAR LA SOLUCIÓN PASOS -

Entender los detalles del requerimiento Entender la arquitectura %dentificar elementos de dise1o eterminar como los elementos colaboran para reali"ar el escenario /efinar decisiones de dise1o. ise1o interno para elementos grandes o complejos! (omunicar el dise1o Evaluar el dise1o

TAREA: DISEAR LA SOLUCIÓN CONSIDERACIONES CLAVES (ada paso en esta tarea puede causar la revisión de todos los pasos anteriores a la lu" de la nueva información y decisiones. or ejemplo, mientras se determina cómo los elementos colaboran se podría encontrar un *ueco en los requerimientos que *ace volver al principio después de colaborar con el analista, o al evaluar el dise1o el que lo revisa podría se1alar que un elemento reutili"able que se está utili"ando no funciona como se esperaba lo que podría causar la identificación nuevos elementos para tomar su lugar.

TAREA: DISEAR LA SOLUCIÓN CONSIDERACIONES CLAVES (onsidere la arquitectura mientras se ejecuta esta tarea. $odo el trabajo de dise1o se debe con respecto a la arquitectura dentro de la cual e'iste el dise1o. or otra parte, ciertos elementos de dise1o serán considerados de gran importancia arquitectónica2 estos elementos requerirán actuali"aciones en la arquitectura. Esta tarea se aplicara en numerosas ocasiones. El dise1o se reali"a mejor en peque1os tro"os.

TAREA: DISEAR LA SOLUCIÓN CONSIDERACIONES CLAVES %ncluso cuando se inicia el dise1o para un proyecto particular, se espera que *abrá frame3or8s e'istentes y elementos reutili"ables. (ada paso de esta tarea debe prestar atención al dise1o ya e'istente y a la implementación e'istente, utili"ando elementos e'istentes cuando sea posible y emulando o mejorando los elementos e'istentes como sea apropiado mientras se dise1a esta parte de la solución.  0plicar patrones a lo largo de esta tarea. atrones representan dise1os probados y su uso promueve la calidad y consistencia a través del dise1o.

TAREA: IMPLEMENTAR TESTS DE DESARROLLO %mplementar una o más pruebas que permitan la validación elementos de implementación individuales a través de la ejecución.

PROPÓSITO repararse para validar un elemento de implemetnacion por ejemplo, una operación, una clase, un procedimiento almacenado! a través de pruebas unitarias. El resultado es una o mas pruebas de desarrollo nuevas.

TAREA: IMPLEMENTAR TESTS DE DESARROLLO

TAREA: IMPLEMENTAR TESTS DE DESARROLLO DESCR2PCIÓN PRINCIPAL Las pruebas de desarrollo son diferentes de otras formas de pruebas en que se basan en el comportamiento esperado de unidades de código en lugar de basarse directamente en los requisitos del sistema. Es mejor *acer esto en una escala peque1a, muc*o más peque1a que el código base completo a ser escrito por un desarrollador en el transcurso de una iteración. Esto se puede *acer para una sola operación, un campo a1adido a una interfa" de usuario, un procedimiento almacenado, etc.  0 medida que el código base se construye de forma incremental, nuevas pruebas serán escritas y las pruebas e'istentes podrían revisarse para probar el comportamiento adicional.

TAREA: IMPLEMENTAR TESTS DE DESARROLLO PASOS - /efinar el alcance e identificar el tests! - Escribir la configuración de la pruebasetup test! - efinir los resultados esperados - Escribir la lógica del test. - efinir la respuesta del test. - Escribir el código de limpie"a. - robar el test.

TAREA: IMPLEMENTAR TESTS DE DESARROLLO CONSIDERACIONES CLAVE . $rabajar en pares con los miembros del equipo con *abilidades de testing en todas las etapas de esta tarea para ganar penetración en consideraciones de prueba y de calidad. El ?$rabajo del royecto roject @or8!A se utili"a implícitamente en las tareas de implementación para manejar que requerimientos o requerimientos de cambio van a ser reali"ado en este código.

TAREA: IMPLEMENTAR TESTS DE DESARROLLO ALTERNATIVAS (ontar con pruebas de aceptación para validar el soft3are. Esto probablemente consumirá muc*o tiempo, será tarde, y no es tan efica" como las pruebas de desarrollo en la identificación de los errores bugs! y encontrar su ubicación en el código.

TAREA: IMPLEMENTAR LA SOLUCIÓN %mplementar código fuente para proporcionar nueva funcionalidad o corregir errores.

PROPÓSITO El propósito de esta tarea es producir una implementación para parte de la solución tal como una clase o componente!, o para fijar uno o más defectos. El resultado es típicamente código fuente nuevo o modificado, el cual *ace referencia a la aplicación.

TAREA: IMPLEMENTAR LA SOLUCIÓN

TAREA: IMPLEMENTAR LA SOLUCIÓN DESCRIPCIÓN PRINCIPAL 4sualmente, esta tarea se enfoca en un elemento de implementación específico, tal como una clase o componente, pero no necesariamente tiene que serlo. 4na porción del dise1o se implementa mediante la reali"ación de esta tarea.

TAREA: IMPLEMENTAR LA SOLUCIÓN DESCRIPCIÓN PRINCIPAL Esta tarea se puede llevar a cabo cualquier n)mero de veces durante una iteración. e *ec*o, es mejor *acer esta tarea con el menor alcance posible para estrec*ar el la"o entre ella y las tareas relacionadas involucrando pruebas de desarrollo y consideraciones de dise1o.

TAREA: IMPLEMENTAR LA SOLUCIÓN PASOS DETERMINAR UNA ESTRATEGIA eterminar una estrategia basada en el dise1o de soft3are y pruebas de desarrollador para saber cómo se va a implementar la solución. Las opciones fundamentales son: