Está en la página 1de 7

SOFTWARE ENGINEERING A PRACTITIONER'S APPROACH

Metodologas Agiles Flujo de Proceso

3 DE MAYO DE 2013
UNIVERSIDAD PRIVADA CESAR VALLEJP DIESTRA LOYOLA LUIS MARTN

FLUJO DE PROCESO Para un pequeo proyecto de software solicitado por una persona (en una ubicacin remota), con requisitos simples y directos, la actividad de comunicacin puede abarcar ms que una llamada de telfono con el actor adecuado. Por lo tanto, la nica accin necesaria es la conversacin telefnica, y las tareas de trabajo (el conjunto de tareas) que esta accin abarca son: 1. Ponerse en contacto con las partes interesadas a travs del telfono. 2. Analizar las necesidades y tomar notas. 3. Organizar notas en una breve declaracin escrita de requisitos. 4. E-mail a los interesados para su revisin y aprobacin. Si el proyecto es mucho ms complejo, con muchos actores, cada uno con un conjunto diferente de (veces conflictivos) requisitos, la actividad de comunicacin podra tener seis acciones diferentes (descrito en el Captulo 5): creacin, obtencin, elaboracin, la negociacin, la especificacin, y validacin. Cada una de estas acciones de ingeniera de software tendra muchas tareas de trabajo y una serie de productos de trabajo distintos.

La identificacin de un conjunto de tareas Haciendo referencia de nuevo a la Figura 2.1, cada accin de ingeniera de software (por ejemplo, la elicitacin, una accin asociada con la actividad de comunicacin) puede ser representado por un nmero de diferentes conjuntos de tareas-cada una coleccin de tareas de ingeniera de software de trabajo, productos de trabajo relacionados, puntos de aseguramiento de la calidad y los hitos del proyecto. Usted debe elegir un conjunto de tareas que mejor se adapte a las necesidades del proyecto y las caractersticas de su equipo. Esto implica que una accin de la ingeniera de software se puede adaptar a las necesidades especficas del proyecto de software y las caractersticas del equipo de proyecto.

Set de tareas Un conjunto tarea define el trabajo real que hacer para llevar a cabo los objetivos de un software ingeniera de accin. Por ejemplo, la elicitacin (ms comnmente llamado "la recogida de requisitos") es una tanta accin de ingeniera de software que se produce durante la actividad de comunicacin. El objetivo de los requisitos reunin es entender lo que las diversas partes interesadas quieren desde el software que se va a construir. Para un pequeo proyecto relativamente simple, la tarea fijada para recogida de requisitos podra tener este aspecto: 1. Haga una lista de las partes interesadas en el proyecto. 2. Invita a todas las partes interesadas a una reunin informal.

3. Pida a cada parte interesada para hacer una lista de las caractersticas y funciones necesarias. 4. Analizar las necesidades y crear una lista final. 5. Dar prioridad a las necesidades. 6. Tenga en cuenta las reas de incertidumbre.

Para un proyecto de software ms grande, ms complejo, un se requerira conjunto de tareas rente. Podra abarcar las siguientes tareas: 1. Haga una lista de las partes interesadas en el proyecto. 2. Entrevistar a cada actor por separado para determinar general deseos y necesidades. 3. Cree una lista preliminar de las funciones y caractersticas sobre la base de aportaciones de los interesados. 4. Programar una aplicacin con las facilitadas reuniones de especificacin. 5. Llevar a cabo reuniones. 6. Elaborar escenarios de usuarios informales como parte de cada reunin. 7. Afinar escenarios de usuario basados en las partes interesadas retroalimentacin. 8. Cree una lista revisada de los requisitos de los interesados. 9. Utilizar tcnicas de despliegue de la funcin de calidad para priorizar las necesidades. 10. Requisitos de paquetes para que puedan ser entregados incrementalmente. 11. Nota limitaciones y restricciones que se pondrn en el sistema. 12. Discuta los mtodos para validar el sistema.

Ambas tareas establece lograr "la recogida de requisitos," pero son muy diferentes en su profundidad y formalidad. La equipo de software elige el conjunto de tareas que le permita alcanzar el objetivo de cada accin y aun as mantener la calidad y agilidad.

Proceso de Patrones Cada equipo de software se encuentra con problemas mientras se mueve a travs del proceso de software. Sera til si soluciones probadas para estos problemas eran fcilmente disponibles para el equipo para que los problemas puedan ser abordados y resueltos rpidamente. Un patrn de proceso se describe un problema relacionado con el proceso que se encontr durante el trabajo de ingeniera de software, identifica el entorno en el que se ha encontrado con el problema, y sugiere una o ms soluciones probadas para el problema. Dicho en trminos ms generales, un modelo de proceso que proporciona una plantilla de un mtodo consistente para describir la solucin de problemas en el contexto del proceso de software. Mediante la combinacin de patrones, un equipo de software puede resolver los problemas y construir un proceso que mejor se adapte a las necesidades de un proyecto.

Los patrones se pueden definir en cualquier nivel de abstraccin. En algunos casos, un patrn puede ser usado para describir un problema (y la solucin) asociado con un modelo de proceso completa (por ejemplo, creacin de prototipos). En otras situaciones, los patrones se pueden usar para describir un problema (y la solucin) asociada con una actividad de marco (por ejemplo, planificacin) o una accin dentro de un marco de actividad (por ejemplo, la estimacin de proyecto). Ambler ha propuesto un modelo para describir un patrn de proceso: Nombre del patrn. El patrn se le da un nombre significativo que describe que en el contexto del proceso de software. Fuerzas. El entorno en el que se encuentra el patrn y los problemas que hacen que el problema visible y pueden afectar a su solucin. Tipo. Se especifica el tipo de patrn. Ambler sugiere tres tipos: 1. Etapa-patrn, define un problema asociado con una actividad de marco para el proceso. Desde una actividad marco abarca varias acciones y tareas, un patrn etapa incorpora mltiples patrones de tareas (ver a continuacin) que son relevantes para la etapa (actividad framework). 2. Tarea patrn, define un problema asociado con una accin de la ingeniera de software o tarea de trabajo y relevante para la prctica de ingeniera de software con xito. 3. Fase de patrones, definir la secuencia de actividades marco que se produce dentro del proceso, aun cuando el flujo global de las actividades es iterativo en la naturaleza. Un ejemplo de un modelo de fase puede ser de prototipos o SpiralModel. Contexto inicial. Describe las condiciones en las que se aplica la pauta. Antes del inicio del patrn: (1) Qu actividades organizativas o equipo relacionado que ya se han producido? (2) Cul es el estado de la entrada para el proceso? (3) Qu informacin existe ya la ingeniera de software o proyecto de informacin? Por ejemplo, el modelo de planificacin (un patrn etapa) requiere que (1) los clientes y los ingenieros de software han establecido una comunicacin colaborativa, (2) la finalizacin con xito de una serie de pautas de trabajo [especificar] para el patrn de comunicacin se ha producido, y (3) el alcance del proyecto, los requisitos bsicos de negocios y restricciones del proyecto son conocidos. Problema. El problema especfico a ser resuelto por el patrn. Solucin. Describe cmo implementar el patrn de xito. Esta seccin describe cmo el estado inicial del proceso (que existe antes de que se implementa el patrn) se modifica como consecuencia de la iniciacin de la pauta. Tambin describe cmo la informacin de ingeniera de software o la informacin del proyecto que est disponible antes del inicio de la pauta es transformada como consecuencia de la ejecucin exitosa del patrn.

Resultando Contexto. Describe las condiciones que darn lugar una vez que el modelo ha sido implementado con xito. Al completar el patrn: (1) Qu organizacin o las actividades relacionadas con el equipo debe haber ocurrido? (2) Cul es el estado de salida para el proceso? (3) Qu informacin de ingeniera de software o la informacin del proyecto se ha desarrollado? Patrones relacionados. Proporcionar una lista de todos los patrones de procesos que estn directamente relacionados con ste. Esto puede ser representado como una jerarqua o en alguna otra forma de diagrama. Usos y ejemplos conocidos. Indique los casos especficos en que el patrn es aplicable. Por ejemplo, la comunicacin es obligatoria en el comienzo de cada proyecto de software, se recomienda en todo el proyecto de software, y es obligatoria una vez que la actividad de despliegue est en marcha.

Patrones de procesos proporcionan un mecanismo eficaz para hacer frente a los problemas asociados a cualquier proceso software. Los patrones le permiten desarrollar una descripcin del proceso jerrquico que comienza en un alto nivel de abstraccin (un patrn de fase). La descripcin se refina a continuacin, en un conjunto de patrones de etapa que describen las actividades de marco y se refina de nuevo de una manera jerrquica en los patrones de trabajo ms detallados para cada patrn de fase. Una vez patrones de procesos han sido desarrollados, que pueden ser reutilizados para la definicin de proceso es que las variantes-, un modelo de proceso personalizado puede ser definido por un equipo de software utilizando los patrones como bloques de construccin para el modelo de proceso.

DESARROLLO GIL El desarrollo gil puede proporcionar importantes beneficios, pero no es aplicable a todos los proyectos, todos los productos, todas las personas, y todas las situaciones. Tampoco es la anttesis de la prctica de la ingeniera de software slido y se puede aplicar como una filosofa primordial para todos los trabajos de software. En la economa moderna, a menudo es difcil o imposible predecir cmo un sistema basado en computadoras (por ejemplo, una aplicacin basada en Web) que evolucionar con el tiempo. Las condiciones del mercado cambian rpidamente, el usuario final debe evolucionar, y las nuevas amenazas competitivas surgen sin previo aviso. En muchos casos, usted no ser capaz de definir los requisitos plenamente antes de que comience el proyecto. Debe ser lo suficientemente gil para responder a un entorno empresarial fluido. Una de las caractersticas ms atractivas del enfoque gil es su capacidad para reducir los costos del cambio en todo el proceso de software. Significa esto que el reconocimiento de los desafos

planteados por la realidad actual hace que se descarte valiosos principios de ingeniera de software, conceptos, mtodos y herramientas? Por supuesto que no! Como todas las disciplinas de la ingeniera, ingeniera de software contina evolucionando. Se puede adaptar fcilmente para cumplir con los desafos planteados por la demanda de agilidad. En un libro que invita a la reflexin sobre el desarrollo gil de software, Alistair Cockburn argumenta que los modelos de procesos normativos introducidos en el captulo 2 tienen un gran defecto: se olvidan de las debilidades de la gente que construye programas informticos. Los ingenieros de software no son robots. Presentan una gran variacin en los estilos de trabajo, las diferencias significativas en el nivel de habilidad, la creatividad, el orden, la coherencia y la espontaneidad. Algunos comunicarse en forma escrita, otros no lo hacen. Cockburn argumenta que los modelos de procesos pueden "hacer frente a las debilidades comunes de las personas con [ya sea] disciplina o tolerancia", y que la mayora de los modelos de procesos prescriptivos elegir disciplina. l dice: "Porque la coherencia en la accin es una debilidad humana, metodologas de alta disciplina son frgiles." Si los modelos de proceso deben trabajar, deben proporcionar un mecanismo realista para fomentar la disciplina que es necesario, o deben ser caracterizados de una manera que muestra "tolerancia" a la gente que hace el trabajo de ingeniera de software. Invariablemente, las prcticas tolerantes son ms fciles para la gente de software para que ponga en prctica, pero (como admite Cockburn) pueden ser menos productivos. Como casi todo en la vida, hay que considerar las compensaciones. QU ES AGILIDAD? Qu es exactamente la agilidad en el contexto del trabajo de ingeniera de software? Ivar Jacobson ofrece una discusin til: Agility ha convertido en palabra de moda de hoy en da cuando se describe un proceso de software moderno. Todo el mundo es gil. Un equipo gil es un equipo gil capaz de responder adecuadamente a los cambios. El cambio es lo que el desarrollo de software tiene mucho que ver. Los cambios en el software que se est construyendo, los cambios en los miembros del equipo, los cambios ya las nuevas tecnologas, los cambios de todo tipo que puedan tener un impacto en el producto que construyen o el proyecto que crea el producto. Apoyo a los cambios deben ser incorporados en todo lo que hacemos en software, algo que abrazar porque es el corazn y el alma de software. Un equipo gil reconoce que el software es desarrollado por personas que trabajan en equipo y que las habilidades de estas personas, su capacidad de colaboracin es la base para el xito del proyecto. En opinin de Jacobson, la omnipresencia de cambio es el principal impulsor de la agilidad. Los ingenieros de software tienen que ser rpido en sus pies para que puedan adaptarse a los rpidos cambios que Jacobson describe. Pero la agilidad es ms que una respuesta eficaz al cambio. Tambin abarca la filosofa expuesta en el manifiesto se seal al comienzo de este captulo.

Anima a las estructuras y actitudes que hacen que la comunicacin (entre los miembros del equipo, entre tecnlogos y empresarios, entre los ingenieros de software y sus directivos) ms fcil del equipo. Se hace hincapi en la entrega rpida de software operativo y de-enfatiza la importancia de los productos de trabajo intermedios (que no siempre es una buena cosa), sino que adopta el cliente como parte del equipo de desarrollo y trabaja para eliminar el "nosotros y ellos" actitud que sigue impregnan muchos proyectos de software, sino que reconoce que la planificacin en un mundo incierto tiene sus lmites y que un plan de proyecto debe ser flexible. Agilidad se puede aplicar a cualquier proceso de software. Sin embargo, para lograr esto, es esencial que el proceso de ser diseado de una manera que permite que el equipo de proyecto para adaptar las tareas y para racionalizar ellos, llevar a cabo la planificacin de una manera que entiende la fluidez de un enfoque de desarrollo gil, eliminar todos pero el ms productos de trabajo esenciales y mantenerlos magra, y hacer hincapi en una estrategia de entrega incremental que consigue software de trabajo al cliente tan pronto como sea posible para el tipo de producto y el entorno operativo. Agilidad y el costo de cambio La sabidura convencional en el desarrollo de software (apoyada por dcadas de experiencia) es que el coste del cambio aumenta no linealmente como un proyecto progresa. Es relativamente fcil para dar cabida a un cambio cuando un equipo de software est reuniendo los requisitos de (a principios de un proyecto). Un escenario de uso podra tener que ser modificado, una lista de funciones podr ser prorrogada, o una hoja de especificaciones se puede editar. Los costos de hacer este trabajo son mnimos, y el tiempo requerido