DIAGRAMA DE CLASES

INTRODUCCIÓN Y OBJETIVO DE LA CLASE

La clase de la fecha  12 de Enero del 2015 se retroalimento nuevamente que era un diagrama de caso de uso por parte de la docente con la ayuda de una presentación realizada en power Point, El objetivo de la clase era compartir mediante una exposición que era un diagrama de clases.

Un diagrama de clases consiste en diseñar la estructura del sistema es decir las relaciones y otros aspectos que hacen que la aplicación funcione. El diagrama de clase está compuesto por tres partes, Nombre de la clase, atributos  y métodos.

MARCO TEÓRICO

En la ingeniería de software, un diagrama de clases en el Lenguaje Unificado de Modelado (UML) es un tipo de diagrama de estructura estática que describe la estructura de un sistema mostrando clases del sistema, sus atributos, operaciones (o métodos), y las relaciones entre los objetos. El diagrama de clases es el principal elemento de modelado orientado a objetos. Se utiliza tanto para el modelado conceptual general de la sistemática de la aplicación, y para el modelado detallado traducción de los modelos en el código de programación. Los diagramas de clases también se pueden usar para el modelado de datos.  (Scott & Ambler. 2009)  Las clases en un diagrama de clases representan los dos principales objetos, las interacciones en la aplicación y las clases que se programen (Unified Modeling Language. 2010)

VISIBILIDAD

 

+	Publica
–	Privada
#	Protegida
/	Derivada
~	Nombre de Espacios

Asociación

Una asociación representa una familia de enlaces. Una asociación binaria (con dos extremos) suele representarse como una línea. Una asociación puede vincular cualquier número de clases. Una asociación con tres enlaces se llama una asociación ternaria. Una asociación puede ser nombrado, y los extremos de una asociación puede ser adornado con nombres de roles, indicadores de propiedad, la multiplicidad, la visibilidad y otras propiedades.

Agregación

La agregación es una variante, la  agregación es más específica que la asociación. Es una asociación que representa a-toda parte o de parte de la relación. Como un tipo de asociación, una agregación puede ser nombrada y tienen las mismas relaciones que una asociación. Sin embargo, una agregación no puede suponer más de dos clases; debe ser una asociación binaria.

Composición

Por lo general tiene una fuerte dependencia del ciclo de vida entre las instancias de la clase de contenedor y las instancias de la clase contenidos (en): si se destruye el contenedor, normalmente cada instancia que contiene se destruye también. (Tenga en cuenta que, donde sea permitido, una parte se puede quitar de un material compuesto antes de eliminar el material compuesto, y por lo tanto no se eliminará como parte del material compuesto.)

CONCLUSIÓN

El diagrama en conclusión describe la forma de como fluye la información entre entidades u objetos. El diagrama de clases  es estático no crece ni varia en cuestiones de modelo en acción.

La clase compartida la fecha indicada en este blog , compartió la idea y socialización de una forma dinámica.

 REFERENCIAS

 Scott W. Ambler (2009) UML 2 Class Diagrams. Webdoc 2003-2009. Accessed Dec 2, 2009

UML Reference Card.  Associates, 2007, retrieved 12 March 2011.

OMG Unified Modeling Language (OMG UML) Superstructure, Version 2.3: May 2010. Retrieved 23 September 2010.

Pressman, R., Ingeniería de software, un enfoque práctico, sexta edición. Editorial McGrawHill, México, año 2010  (Libro digital). Capítulo 1

DIAGRAMA DE CASOS DE USOS

INTRODUCCIÓN Y OBJETIVO DE LA CLASE

En la  clase de la fecha Diciembre 1 del 2014 se resumió por parte de un orador los conceptos de modelados y se profundizo un poco más acerca del tema diagrama de caso de Uso.

Los diagramas de caso de uso enfocan un contexto dirigido a que los clientes entiendan el flujo de información del software, es decir dichos diagramas no expresan nada técnico sino todo lo contrario trata de explicar con formas y figuras como funciona la aplicación. El objetivo de dicha sesión de clases fue compartir mediante unas diapositivas q era un diagrama de caso de uso

MARCO TEÓRICO

Un diagrama de casos de uso en su forma más simple es una representación de la interacción de un usuario con el sistema y que representa las especificaciones de un caso de uso (Kawabata & Kasah. 2007). Un diagrama de casos de uso puede representar a los diferentes tipos de usuarios de un sistema y el caso ya menudo se acompaña de otros tipos de diagramas también (Gemino & Parker. 2009) (Jacobson; etall, 1992) (McLaughlin, etall. 2006).

Son útiles para las presentaciones a la gestión y / o interesados en el proyecto, sino para el desarrollo real se encuentra que los casos de uso ofrecen considerablemente más valor porque describen las necesidades reales. La siguiente figura describe un diagrama de caso de uso.

Un caso de uso describe una secuencia de acciones que proporcionan algo de valor medible para un actor y se dibuja como una elipse horizontal.

Actores.

Un actor es una persona, organización o sistema externo que desempeña un papel en una o más interacciones con el sistema. Los actores se dibujan como figuras de un muñeco.

Asociaciones.

Las asociaciones entre actores y casos de uso se indican en el uso de diagramas de casos por líneas continuas. Existe una asociación siempre que un actor está involucrado con una interacción descrita por un caso de uso.

Cajas de contorno del sistema (opcional).

Usted puede dibujar un rectángulo alrededor de los casos de uso, llamada caja de frontera del sistema, a indica el alcance de su sistema. Cualquier cosa dentro de la caja representa la funcionalidad que está en alcance y nada fuera de la caja no es.

Paquetes (opcional).

Los paquetes son construcciones UML que permiten organizar los elementos del modelo (como los casos de uso) en grupos. Los paquetes se representan como carpetas de archivos y pueden ser utilizados en cualquiera de los diagramas UML, incluyendo tanto los diagramas de casos de uso y diagramas de clases. Utilizo paquetes sólo cuando mis diagramas se convierten en difícil de manejar, que por lo general implica que no se pueden imprimir en una sola página, para organizar un diagrama grande en otros más pequeños.

DONDE UTILIZAR DIAGRAMAS DE CASOS?

Como ya hemos comentado, hay cinco diagramas en UML para modelar visión dinámica de un sistema. Ahora todos y cada modelo tiene un propósito específico para utilizarlo. En realidad estos propósitos específicos son diferentes ángulos de un sistema en funcionamiento. Así que para entender la dinámica de un sistema que tenemos que utilizar diferentes tipos de diagramas. Utilice el diagrama de casos es uno de ellos y su objetivo específico es reunir los requisitos del sistema y los actores. Los diagramas de casos determinan los hechos de un sistema y sus flujos. Pero diagrama de casos de uso no describe cómo se implementan. Utilice el diagrama de casos puede ser imaginado como un cuadro negro donde se conoce sólo la entrada, la salida y la función de la caja de negro. Estos diagramas se usan a un nivel muy alto de diseño. Entonces este diseño de alto nivel se refina y otra vez para obtener una imagen completa y práctica del sistema. Un caso de uso bien estructurado también describe la condición previa, condición post, excepciones. Y estos elementos adicionales se utilizan para hacer los casos de prueba cuando se realiza la prueba. Aunque los casos de uso no son un buen candidato para la ingeniería directa e inversa, pero todavía se utilizan de una manera diferente leve de hacer ingeniería directa e inversa. Y lo mismo es cierto para la ingeniería inversa. Todavía utilice diagrama de casos se utiliza de manera diferente para que sea un candidato para la ingeniería inversa

Así que los siguientes son los lugares donde se utilizan los diagramas de casos de uso:

• Análisis de requerimientos y diseño de alto nivel.
• Modelar el contexto de un sistema
• La ingeniería inversa.
• Ingeniería directa 

 

CONCLUSIÓN

En conclusión un diagrama de caso de uso es conjunto de elementos fáciles e interactivos que permite explicar de forma clara al cliente cómo será el flujo de información del producto que adquirirá.

Por otro punto de vista se hace referencia a que los métodos para la construcción de un diagrama de caso de uso se basan en tomar de una forma correcta los requerimientos a desarrollar. Además en cuanto respecta a la socialización del tema en general se considera que se  cumplió con las expectativas de enseñanza esperada por parte de la docente.

 REFERENCIAS

Gemino, A; Parker, D. 2009.  «Use case diagrams in support of use case modeling: Deriving understanding from the picture», Journal of Database Management, Vol 20

Jacobson, I; Christerson M;  Jonsson P; Övergaard G. 1992. Object-Oriented Software Engineering – A Use Case Driven Approach, Addison-Wesley. ISBN-13: 078-5342544350

Kawabata, R; Kasah, K. 2007. «Systems Analysis for Collaborative System by Use Case Diagram», Journal of Integrated Design & Process Science, Vol 11, Pags 13-27.

McLaughlin, B; Pollice, G;  West, D. 2006. Head First Object Oriented Analysis and Design, O’Reilly Media, Inc.

Ambler, W. 2014. Diagramas de Caso de Uso. Consultado 1 de enero 2015. Formato HTML. Diposnible en: http://www.agilemodeling.com/artifacts/useCaseDiagram.htm

PROCESO UNIFICADO ÁGIL

INTRODUCCIÓN Y OBJETIVO DE LA CLASE

El día 17 de noviembre del 2014 se planteó en clase una investigación rápida y una demostración de lo aprendido mediante la socialización por parte de los alumnos todo lo investigado, es decir que aquel día se  realizó una metodología de enseñanza bastante practica que en lo personal me permitió asumir que los compañeros de clases guardaran de forma permanente  el conocimiento socializado por ellos mismos.

En este entrada el blog les mencionare acerca del  proceso unificado ágil que es el tema que me toco investigar y compartir en clases.

MARCO TEÓRICO

Agile Unified Process (AUP) es una versión simplificada del Rational Unified Process (RUP) desarrollado por Scott Ambler (Waters. 2008). Se describe un simple, fácil de entender enfoque para el desarrollo de software de aplicaciones de negocio utilizando técnicas y conceptos ágiles y aún así se mantiene fiel a el RUP. El AUP se aplica técnicas ágiles incluyendo el desarrollo guiado por pruebas (TDD), Agile Modeling (AM), la gestión del cambio ágil, y refactorización de base de datos para mejorar la productividad.

En 2011 el PUA representó uno por ciento de todas las Metodologías Ágiles utilizados(State of Agile Development. 2011).En 2012, la AUP fue reemplazado por Disciplinado Agile Entrega (DAD). Desde entonces el trabajo ha dejado de evolucionar PUA. Es una versión simplificada del Rational Unified Process (RUP). En él se describe un simple, fácil de entender enfoque para el desarrollo de software de aplicaciones de negocio utilizando técnicas y conceptos ágiles y aun así se mantiene fiel a la RUP. He tratado de mantener el Agile UP tan simple como sea posible, tanto en su planteamiento como en su descripción. Las descripciones son simples y al punto, con enlaces a los detalles (en la web) si usted las quiere. El enfoque se aplica técnicas ágiles incluyen el desarrollo de pruebas (TDD), Agile Model Driven Desarrollo (AMDD), gestión del cambio ágil, y refactorización de base de datos para mejorar su productividad.

 

La Figura 1 muestra el ciclo de vida de la PUA. Lo primero que notarás es que las disciplinas han cambiado. En primer lugar, la disciplina Modelo abarca disciplinas modelado de negocio, requisitos y Análisis y Diseño de la PUA. Modelo es una parte importante de la política de uso aceptable, como se puede ver, pero no domina el proceso – usted desea permanecer ágil mediante la creación de modelos y documentos que son lo suficientemente apenas bueno. En segundo lugar, la configuración y la disciplina de Gestión del Cambio es ahora la disciplina Gestión de la Configuración. En el desarrollo ágil de sus actividades de gestión del cambio son típicamente parte de sus esfuerzos de gestión de requisitos, lo cual es parte de la disciplina del modelo.

 

ITERATIVO:

Disciplinas se llevan a cabo de manera sistemática, la definición de las actividades que realizan los miembros del equipo de desarrollo para construir, validar y desplegar software de trabajo que responda a las necesidades de sus grupos de interés. Las disciplinas son:

 

MODELO. El objetivo de esta disciplina es entender el negocio de la organización, el dominio del problema siendo abordado por el proyecto, y para identificar una solución viable para hacer frente al dominio del problema.

IMPLEMENTACIÓN. El objetivo de esta disciplina es transformar su modelo (s) en código ejecutable y para llevar a cabo un nivel básico de las pruebas, en las pruebas de unidad en particular.

Test. El objetivo de esta disciplina es llevar a cabo una evaluación objetiva para garantizar la calidad. Esto incluye encontrar defectos, validar que el sistema funciona tal como fue diseñado, y verificar que se cumplen los requisitos.

DESPLIEGUE. El objetivo de esta disciplina es planificar para la entrega del sistema y ejecutar el plan para que el sistema disponible para los usuarios finales.

GESTIÓN DE CONFIGURACIÓN . El objetivo de esta disciplina es para administrar el acceso a sus artefactos del proyecto. Esto incluye no sólo el seguimiento de versiones de artefactos en el tiempo, sino también el control y la gestión de los cambios a los mismos.

GESTIÓN DE PROYECTOS. El objetivo de esta disciplina es dirigir las actividades que lleva a cabo el proyecto. Esto incluye los riesgos de gestión y dirección de personas (la asignación de tareas, seguimiento del progreso, etc.), y la coordinación con las personas y los sistemas fuera del alcance del proyecto para asegurarse de que está entregado a tiempo y dentro del presupuesto.

AMBIENTE. El objetivo de esta disciplina es apoyar el resto del esfuerzo por garantizar que el proceso adecuado, orientación (normas y directrices) y herramientas (hardware, software, etc.) están disponibles para el equipo, según sea necesario.

¿Si usted adopta la PUA?

Si quieres algo en entre XP y RUP tradicional, un proceso que es ágil aún explícitamente incluye actividades y artefactos que usted está acostumbrado, entonces es probable que la AUP. Muchas organizaciones son recelosos de XP, ya que parece ser demasiado clara: XP no muestra explícitamente cómo crear algunos de los artefactos que la administración quiere ver. Esta es una actitud lamentable porque XP es un gran proceso. En el otro extremo del espectro se encuentra RUP, que la gestión parece que me encanta, pero los desarrolladores parece receloso de debido a la gran cantidad de artefactos. Esto también es lamentable porque el RUP tiene mucho que ofrecer, y se puede reducir a algo bastante útil (que es exactamente lo que IBM Rational se lo recomienda). Las tierras AUP entre los dos, la adopción de muchas de las técnicas ágiles de XP y otros procesos ágiles aún conserva algo de la formalidad de la RUP(Universidad Union Bolivariana. 2015 )

CONCLUSIÓN

En cuanto respecta a PUA o proceso unificado agil puede concluirse que es el conjunto de metodologías agiles que permiten una optimización adecuada a un proyecto de software que se puede apreciar en conceptos matemáticos sobre un eje en un plano cartesiano. En cuanto respecta a la metodología de clase puedo concluir con una felicitación a la docente por tener esa magnífica idea de enseñanza.

 

 REFERENCIAS

Waters, J. 2008. Agile lands role in games and business software. The Register. Retrieved 2009-08-03.

State of Agile Development Survey Results, 2011. VersionOne. Formato HTML. Disponible en: http://www.versionone.com/state_of_agile_development_survey/2011/

Pressman, R., Ingeniería de software, un enfoque práctico, sexta edición. Editorial McGrawHill, México, año 2010  (Libro digital). Capítulo 3

Universidad Unión Bolivariana. 2015. Proceso Unificado Ágil  .Consultado 14 de Feb. Disponible en: http://ingenieriadesoftware.mex.tl/63758_AUP.html

DESARROLLO ÁGIL

INTRODUCCIÓN Y OBJETIVO DE LA CLASE

La  clase de la fecha 10 de Noviembre   del 2014 se basó  en reforzar la clase anterior acerca de los ciclos de vida del software   y entrar de lleno al capítulo de tres de Roger Pressman que consiste en desarrollo ágil.

El desarrollo ágil combina la filosofía y líneas de desarrollo permitiendo así un desenlace que proporciona a los desarrolladores de soluciones una práctica experiencia de desarrollo de software.

MARCO TEÓRICO

Desarrollo ágil de software es un conjunto de métodos de desarrollo de software en el que las necesidades y soluciones evolucionan a través de la colaboración entre la auto-organización, equipos multifuncionales. Promueve la planificación adaptativa, desarrollo evolutivo, parto prematuro, la mejora continua, y anima a la respuesta rápida y flexible a los cambios.El Manifiesto de Agile Software Development, (Beck. 2001)también conocido como el Manifiesto Ágil, que por primera vez estableció los conceptos subyacentes de desarrollo ágil, introdujo el término en 2001.

Métodos de desarrollo de software incrementales se remontan a 1957(Gerald &  Basili. 2003). En 1974, EA Edmonds escribió un artículo que introdujo un proceso de desarrollo de software de adaptación(Edmonds. 1974) (Edmonds. 1970) . Al mismo tiempo y de forma independiente, los mismos métodos fueron desarrollados y desplegados por el New York Teléfono Sistemas Centro de Desarrollo de la Sociedad bajo la dirección de Dan Gielan. A principios de la década de 1970, Tom Gilb comenzó a publicar los conceptos de Gestión de Proyectos Evolutiva (EVO), que ha evolucionado hasta convertirse en Ingeniería competitiva(Larman. 2004) Durante mediados y finales de 1970, Gielan disertó ampliamente en todo los EE.UU. en esta metodología, sus prácticas, y sus beneficios.

Los llamados métodos de desarrollo de software ágil ligeros desarrollado a mediados de la década de 1990 como reacción a los métodos cascada orientada peso pesado, que los críticos llaman fuertemente regulada, regimentada, microadministrado y otra incremental.

Los defensores de los métodos ágiles ligeros sostienen que están regresando a las prácticas de desarrollo que estaban presentes temprano en la historia del software.

Las primeras implementaciones de los métodos ágiles incluyen Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), adaptación de desarrollo de software, Feature Driven Development (1997), y los sistemas dinámicos Método de Desarrollo (DSDM) (1995). Éstos ahora se conocen colectivamente como el desarrollo ágil, después del Manifiesto Ágil fue publicado en 2001(Gerald &  Basili. 2003)

¿Por qué una metodología ágil?

El desarrollo ágil ofrece oportunidades para evaluar la dirección en todo el ciclo de vida de desarrollo. Esto se logra a través de cadencias regulares de trabajo, conocidos como Sprints o iteraciones, al final del cual los equipos deben presentar un incremento de producto potencialmente entregable. Al concentrarse en la repetición de los ciclos de trabajo abreviados, así como el producto funcional con ellos se obtienen, la metodología ágil es descrito como «iterativo» y «gradual». En cascada, los equipos de desarrollo sólo tienen una oportunidad de obtener cada aspecto de un derecho proyecto. En un paradigma ágil, cada aspecto del desarrollo – requerimientos, diseño, etc – se revisa continuamente. Cuando un equipo se detiene y re-evalúa la dirección de un proyecto cada dos semanas, no hay tiempo para dirigirlo en otra dirección.

Este enfoque de «inspeccionar-y-adaptar» al desarrollo reduce en gran medida los costes y el tiempo de desarrollo de mercado. Debido a que los equipos pueden desarrollar software al mismo tiempo que están reuniendo los requisitos, «parálisis por análisis» es menos probable que impida a un equipo de avanzar. Y debido a que el ciclo de trabajo de un equipo se limita a dos semanas, los interesados tienen oportunidades recurrentes para calibrar lanzamientos para el éxito en el mundo real. El desarrollo ágil ayuda a las empresas a construir el producto adecuado. En lugar de comprometerse a comercializar una pieza de software que no se ha escrito aún, ágil permite a los equipos a replantear continuamente su liberación para optimizar su valor a lo largo del desarrollo, que les permite ser lo más competitivos posible en el mercado. El desarrollo ágil conserva crítica importancia en el mercado de un producto y asegura el trabajo de un equipo de no terminar en un estante, nunca lanzó.

 

CONCLUSIÓN

 

El desarrollo agile es una forma nueva de hacer software por ello nace la idea de concluir en dos aspectos tanto de la forma técnica y la forma potencial de alcance en cuanto respecta a la planificación y desarrollo de un proyecto.

En el aspecto técnico se enfoca en la adaptación de código y documentación en el proceso y en cuanto respecta a los aspectos de planificación  se basa en un enfoque de adaptación.

 

 REFERENCIAS

 Beck, K. 2001. «Manifesto for Agile Software Development». Agile Alliance. Retrieved 14 June 2010.Disponible en línea: http://www.agilemanifesto.org/

Gerald, M;  Basili, V. 2003. «Iterative and Incremental Development: A Brief History». Computer 36 (6): 47–56.doi:10.1109/MC.2003.1204375. ISSN 0018-9162

Edmonds, E. 1974. «A Process for the Development of Software for Nontechnical Users as an Adaptive System». General Systems 19: 215–18.

Note by Edmonds: I presented these ideas in London in 1970 and first submitted the paper to the Journal Computer Aided Design. It was rejected with the comment «If you don’t know what you are going to do before you start you shouldn’t start»! Only then did I submit it to General Systems.

Larman, C. 2004. Agile and Iterative Development: A Manager’s Guide. Addison-Wesley. p. 27. ISBN 978-0-13-111155-4.

PROGRAMACIÓN ORIENTADA A ASPECTOS

INTRODUCCIÓN Y OBJETIVO DE LA CLASE

En la  clase de la fecha 3 de Noviembre   del 2014 se marcó como objetivo comprender las metodologías avanzadas de desarrollo de software.

En esta entrada al blog analizaremos un poco acerca de la Programación Orientada a Aspectos, trataremos de socializar que la POA se basa en desarrollo a un alto nivel, es decir que separan el código por módulos o acciones de usuario. En resumen lo que se trata de explicar es que la POA permite agrupar un número de acciones a  un solo módulo de desarrollo.

MARCO TEÓRICO

En informática, la programación orientada a aspectos (POA) es un paradigma de programación que tiene como objetivo aumentar la modularidad al permitir la separación de los temas transversales. POA constituye una base para el desarrollo de software orientado a aspectos (Ramnivas. 2003). Incluye métodos y herramientas que apoyan la modularización de las preocupaciones a nivel del código fuente de programación, mientras que «el desarrollo de software orientado a aspectos» se refiere a una disciplina de la ingeniería en general (Raghu. 2009)

Programación orientada a aspectos implica romper la lógica del programa en partes distintas (llamados preocupaciones, áreas cohesivas de la funcionalidad) (Siobhán & Baniassad . 2005). Casi todos los paradigmas de programación soportan un cierto nivel de agrupación y la encapsulación de las preocupaciones en entidades separadas, independientes proporcionando abstracciones (por ejemplo, funciones, procedimientos, módulos, clases, métodos) que se puede utilizar para la aplicación, abstrayendo y componer estas preocupaciones. Algunas preocupaciones «atraviesan» múltiples abstracciones en un programa, y desafían estas formas de aplicación. Estas preocupaciones son llamadas temas transversales.

Registro ejemplifica una preocupación transversal debido a una estrategia de registro afecta necesariamente a cada parte del sistema conectado. Inicio de sesión de ese modo tronzar, todas las clases y los métodos registrados.

POA  tiene varios antecedentes directos A1 y A2. (Kiczazles, etall. 1997) de reflexión y meta objeto protocolos, programación orientada a objeto, Composición Filtros y programación adaptativa (Holzinger. 2011)

Gregor Kiczales y sus colegas en el Xerox PARC desarrollaron el concepto explícito de AOP, y siguió con la extensión AspectJ AOP a Java. La Transacción de   Server Microsoft es considerado como la primera aplicación importante de poa seguido por Enterprise JavaBean (Fiman etall. 2004 )( Renaud, etall. 2005)

 

CONCLUSIÓN

En conclusión la idea de la programación orientada a aspectos  es modularizar acciones. En otra perspectiva  la POA es la inclusión de herramientas que ayudan a lograr una modularización como tal.

En cuanto respecta a la clase impartida concluyo que fue muy teórica y no tuvo ninguna tipo de práctica pero eso factor no la hace inservible por lo contrario le hace un plus a que el estudiante investigue   por sí mismo una aplicación práctica para este tema.

 

REFERENCIAS

Kiczales, G.; Lamping, J.; Mendhekar, A.; Maeda, C.; Lopes, C.; Loingtier, J. M.; Irwin, J. (1997). Aspect-oriented programming. ECOOP’97. Proceedings of the 11th European Conference on Object-Oriented Programming. LNCS 1241: 220–242. :10.1007/BFb0053381. ISBN 3-540-63089-9

Holzinger, Andreas; M. Brugger, W. Slany (2011). Applying Aspect Oriented Programming (AOP) in Usability Engineering processes: On the example of Tracking Usage Information for Remote Usability Testing. In: Marca, D. A., Shishkov, B. & Sinderen, M. v. (Eds.) Proceedings of the 8th International Conference on electronic Business and Telecommunications. Sevilla, 53-56.

Filman, R; Tzilla, E; Siobhán, C  y Mehmet, A. 2004. Aspect-Oriented Software Development. ISBN0-321-21976-7

Renaud, P; Seinturier, L y  Retaillé, J. 2005. Foundations of AOP for J2EE Development.ISBN1-59059-507-6

Ramnivas, L. 2003. AspectJ in Action: Practical Aspect-Oriented Programming. ISBN 1-930110-93-6.

Ivar, J. 2005. Aspect-Oriented Software Development with Use Cases.ISBN0-321-26888-1

Siobhán, C; Baniassad , E 2005. Aspect-Oriented Analysis and Design: The Theme Approach. ISBN<0-321-24674-8

Raghu, Y. 2009. Aspect Oriented Software Development: An Approach to Composing UML Design Models. ISBN 3-639-12084-1

SCRUM

INTRODUCCIÓN Y OBJETIVO DE LA CLASE

 En esta entrada al blog se analizara una metodología de desarrollo avanzada dicha metodología fue investigada con un conjunto de metodologías más en clases. El día 24 de octubre del 2014 se terminaba de concluir un capítulo del libro de Roger Pressman acerca del ciclo de vida del software mediante una retroalimentación del tema por parte de la Docente y se adentró el mismo día a un conjunto de metodologías como lo mencione  al principio de la  redacción.

Analizaremos la metodología de desarrollo SCRUM que no  es más que otro concepto de trabajar en equipo para conseguir un objetivo común dependiendo el rol que tengas

MARCO TEÓRICO

Scrum es un marco de desarrollo ágil de software iterativo e incremental para la gestión de desarrollo de productos. Se define «una estrategia flexible, holístico de desarrollo de productos, donde un equipo de desarrollo trabaja como una unidad para alcanzar un objetivo común», desafía las suposiciones del «enfoque tradicional, secuencial» para el desarrollo de productos, y permite a los equipos de auto-organizarse, fomentando co física -ubicación o estrecha colaboración en línea de todos los miembros del equipo, así como la comunicación diaria cara a cara entre todos los miembros del equipo y disciplinas en el proyecto.

Scrum se definió por primera vez como «una estrategia flexible, holístico de desarrollo de productos, donde un equipo de desarrollo trabaja como una unidad para alcanzar un objetivo común», en oposición a un «enfoque tradicional, secuencial» en 1986 por Hirotaka Takeuchi y Nonaka Ikujiro en el «Nuevo Nuevo Desarrollo de Producto Juego «. ( Harvard Business. 1996) Takeuchi y Nonaka tarde argumentaron en» El conocimiento creación de empresa » (Oxford University. 1995) Que es una forma de» creación de conocimiento organizacional, especialmente bueno en lograr la innovación continua, incremental y espiral «( Hirotaka & Ikujiro. 1986)

Los autores describen un nuevo enfoque para el desarrollo de productos comerciales que aumentaría la velocidad y la flexibilidad, basada en estudios de caso de las empresas manufactureras en las industrias, fotocopiadora e impresora de automóviles. Ellos llamaron a este enfoque holístico o el rugby, ya que todo el proceso es realizado por un equipo multi-funcional a través de múltiples fases superpuestas, donde el equipo de «trata de ir a la distancia como una unidad, pasando el balón hacia atrás y adelante». (En el rugby, un scrum se refiere a una formación estanco lleno de los jugadores con la cabeza gacha que intentan obtener la posesión del balón (Sutherland. 2004))

Roles

Las funciones principales son aquellos comprometidos con el proyecto en el proceso de Scrum-ellos son los que producen el producto (objetivo del proyecto). Representan el equipo de scrum. Aunque otras funciones pueden encontrarse en proyectos reales, Scrum no define ningún roles de equipo distintos de los descritos a continuación.

Dueño del Producto

El propietario del producto representa los grupos de interés y es la voz del cliente. Él o ella es responsable de asegurar que el equipo ofrece un valor para el negocio. El Product Owner escribe (o tiene el equipo de escritura) artículos centrados en el cliente (típicamente historias de usuario), ocupa y les da prioridad, y los agrega a la cartera de productos. Equipos de Scrum deben tener un dueño del producto, y si bien también pueden ser un miembro del equipo de desarrollo, este papel no debe ser combinada con la del Scrum Master.A medida que la cara del equipo a las partes interesadas, las siguientes son algunas de las tareas de comunicación del dueño del producto para los grupos de interés:

Equipo de Desarrollo

El equipo de desarrollo es responsable de entregar incrementos potencialmente entregables (PSI) del producto al final de cada Sprint (el objetivo del Sprint). Un equipo se compone de 3-9 personas con capacidades multifuncionales que hacen el trabajo real (analizar, diseñar, desarrollar, probar la comunicación técnica, documento, etc.). El equipo de desarrollo de Scrum es auto-organización, a pesar de que puede haber algún nivel de interfaz con las oficinas de gestión de proyectos (PMO).

Scrum Master

Scrum es facilitado por un Scrum Master, que es responsable de la eliminación de los obstáculos a la capacidad del equipo para entregar los objetivos y entregables del producto. El Scrum Master no es un jefe de equipo o jefe de proyecto tradicional, sino que actúa como un amortiguador entre el equipo y cualquier influencia de distracción. El Scrum Master garantiza que el proceso Scrum se utiliza como es debido. El Scrum Master es el ejecutor de las reglas de Scrum, a menudo preside las reuniones clave, y desafía al equipo a mejorar. El papel también ha sido mencionado como un siervo-líder para reforzar estas perspectivas duales.

EVENTOS

Sprint

El proceso de Scrum  un  sprint (o iteración) es la unidad básica de desarrollo de Scrum. La carrera es un esfuerzo «timeboxed»; es decir, que se limita a una duración específica. La duración se fijará por adelantado para cada sprint y es normalmente entre una semana y un mes, aunque dos semanas es típico.

Cada carrera se inicia con una reunión de planificación. El objetivo es definir un sprint backlog donde las tareas para el sprint se identifican y un compromiso estimado para el objetivo del Sprint se hace. Cada carrera se terminó por una reunión de revisión y retrospectiva del sprint, en la que se revisa el progreso y muestra a los interesados y la mejora de las lecciones para los próximos sprints están identificados.

Reuniones

Reunión de planificación de Sprint

Al comienzo del ciclo de sprint (cada 7-30 días), una «reunión de planificación de Sprint» se lleva a cabo las selecciones:

Preparar la Pila de Sprint que detalla el tiempo que tomará para hacer ese trabajo, con todo el equipo

Identificar y comunicar la cantidad de trabajo es probable que se realice durante el sprint actual

Límite de ocho horas de tiempo para un sprint de 30 días (es decir, dos horas por semana de duración)

(Primeras cuatro horas) equipo completo (Dev.Team, Scrum Master, propietario del producto): diálogo para la priorización de la Pila de Producto

(Segundo período de cuatro horas) Equipo de Desarrollo: hash a cabo un plan para el Sprint, lo que resulta en la Pila de Sprint

Reunión scrum diario

Una reunión scrum diario en la sala de computación. Esta ubicación centralizada ayuda al arranque del equipo en el tiempo.Cada día durante el sprint, una reunión de comunicación del equipo del proyecto se produce. Esto se llama el scrum diario (reunión) (o «stand-up de encuentro») y cuenta con directrices específicas:

Todos los miembros del equipo de desarrollo vienen preparados con las versiones de la reunión.

La reunión comienza precisamente en el tiempo, incluso si algunos miembros del equipo de desarrollo se están perdiendo.

La reunión debe ocurrir en el mismo lugar ya la misma hora todos los días.

La longitud reunión se establece (timeboxed) a 15 minutos.

Todos son bienvenidos, pero normalmente sólo las funciones básicas hablan.

Durante la reunión, cada miembro del equipo responde a tres preguntas:

¿Qué hice ayer que ayudó a que el equipo de desarrollo de cumplir con el objetivo del Sprint?

¿Qué voy a hacer hoy para ayudar al equipo de desarrollo de cumplir con el objetivo del Sprint?

¿Me veo ningún impedimento que yo o el Equipo de Desarrollo impide cumplir con el objetivo del Sprint?

Cualquier impedimento / obstáculo identificado en esta reunión está documentado por el Scrum Master y trabajó hacia la resolución fuera de esta reunión. No hay discusiones detalladas deberán pasar en esta reunión.

 

EXTENSIONES

Refinamiento cartera (grooming)

Refinamiento Cartera es el proceso continuo de revisión elementos del backlog del producto y la comprobación de que se priorizan adecuadamente y se prepararon de una manera que hace que sean claras y ejecutables para los equipos una vez que entran sprints a través de la actividad de planificación del sprint. Refinamiento Cartera no es una práctica fundamental Scrum pero ha sido adoptado como una forma de gestionar la calidad de los elementos del backlog que entran en una carrera de velocidad.

 

SCRUM DE SCRUMS

El Scrum de Scrums (reunión) es una técnica para escalar Scrum para varios equipos que trabajan en el mismo producto, permitiendo a los equipos para discutir su trabajo, centrándose en la forma de coordinar la entrega de software sobre todo en áreas de superposición y la integración. En función de la cadencia (sincronización) de la Scrum de Scrums, el scrum diario correspondiente a cada equipo de scrum termina mediante la designación de un miembro como un embajador para participar en la reunión más amplia con los embajadores de otros equipos. Dependiendo del contexto, los embajadores pueden ser contribuyentes técnicos o Scrum Master de cada equipo.

El orden del día será como un Scrum Diario, con las siguientes cuatro preguntas:

¿Qué ha hecho su equipo desde que nos reunimos por última vez?

¿Cuál será su equipo de hacer antes de que nos encontremos de nuevo?

¿Hay algo más lento su equipo abajo o conseguir en su camino?

¿Está usted a punto de poner algo en el camino del otro equipo?

Se espera que la resolución de los impedimentos para centrarse en los desafíos de la coordinación entre los equipos, y puede implicar aceptar interfaces entre los equipos, la negociación de los límites de responsabilidad, etc.

CONCLUSIÓN

La metodología scrum es una muy buena metodología para trabajar en equipo desde cualquier perspectiva, es decir ya sea desde los requerimientos del producto hasta el despliegue.

En cuanto respecta a la metodología utilizada en clase se puede concluir que la presentación y detalle de SCRUM como tal fue excelente debido a los ejemplos que  ayudaran a los estudiantes subir el nivel en el análisis de software.

 REFERENCIAS

Harvard Business. 1986. New Product Development Game. 86116:137–146. Retrieved March 12, 2013.

Oxford University. 1995. The Knowledge Creating Company. p. 3.ISBN 9780199762330. Retrieved March 12, 2013.

Hirotaka, T; Ikujiro, N. 1986. «The New Product Development Game» (PDF). Harvard Business Review. Retrieved June 9, 2010.

Sutherland, J. 2004. «Agile Development: Lessons learned from the first Scrum».Retrieved September 26, 2008.

Sutherland, J; Schwaber, K. 1995. Business object design and implementation: OOPSLA ’95 workshop proceedings. The University of Michigan. p. 118.ISBN 3-540-76096-2.

Schwaber, K; Beedle, M. 2002. Agile software development with Scrum. Prentice Hall. ISBN 0-13-067634-9.

Schwaber, K. 2004. Agile Project Management with Scrum.Microsoft Press. ISBN 978-0-7356-1993-7.

 

MODELO CASCADA

INTRODUCCIÓN Y OBJETIVO DE LA CLASE

La clase de la fecha Octubre    13     del 2014 se retroalimento todo lo que había suscitado el semestre anterior con  enfoque breve.

Se notó la importancia de recordar argumentos teóricos de los ciclos de vidas de software tanto así que el  objeto de clase se logró alcanzar cuando los integrantes del curso compartieron ideas de lo aprendido, dando así un dinamismo. La Docente argumentaba cosas que en cierto modo solo no existían en la mente de los estudiantes.

Por otro lado en esta entrada del blog se analizara el modelo en cascada como un ciclo de vida descriptivo.

MARCO TEÓRICO

 Nació o se aplicó primeramente en industrias  de la manufactura.

Es decir fue diseñado para elaborar Hardware pero también aplicaba al software (Benington. 1983 ). La primera presentación como un método avanzado de programación para computadoras digitales la hizo el autor antes citado   Benington (Navy Mathematical Computing Advisory Panel. 1956)

Modelo.

• Requerimientos “Considerado el paso más importante“
• Diseño “Componentes, Modulo , interfaces .. otros ”
• Construcción “Consiste en la construcción del Producto”
• Integración “Compilación de módulos de forma global”
• Test “Prueba y error etapa de test en algunos casos”
• Instalación “Etapa de implementación si está bien testeado”
• Mantenimiento “Etapa consecuente a mantener la App”

El modelo de cascada sostiene que uno debe pasar a una fase sólo cuando su fase anterior se revisa y verifica. Varios modelos cascada modificados (incluyendo modelo final de Royce), sin embargo, pueden incluir pequeñas variaciones o importantes en este proceso (Royce. 2014)

 Argumentos.

La construcción de software en un tiempo dedicado puede llevar a una mejor economía en etapas posteriores. Se tienen que definir bien los requerimientos para obtener mejores resultados tanto en lo económico como optimización de tiempo (McConnell. 1996). Una característica del modelo en cascada es que un 20-40% del modelo se consume para las dos primeras fases, 30- 40% se consume en la codificación y el resto dedicado al ensayo de la aplicación (Oxagile. 2014)

 Ventajas  del Modelo Cascada

• No se pasa a otra etapa si no está cumplida la actual
• Una gran cantidad de énfasis en la documentación
• El método de cascada también es bien conocido entre los desarrolladores de software por lo que es fácil de usar. Es más fácil desarrollar una variedad de software a través de este método en el corto espacio de tiempo.

Desventajas del Modelo Cascada 

• Existen variaciones del cliente que el cascada no puede asumir si ya ha pasado una etapa.
• Se pierde una gran cantidad de tiempo.
• Las pruebas se dan bastante tarde en el proceso de desarrollo
• La documentación para proyectos pequeños es pesada

Modificados Modelos Cascada

Debido a las diversas desventajas muchas otras versiones modificadas de este modelo también se han presentado algunas de las cuales se mencionan a continuación:

• Modelo Royce

Aunque no está documentado como el «Modelo Cascada,» Winston W. Royce se le atribuye la primera descripción formal de lo que  se conoce como el Modelo Cascada en 1970. En su definición original, el modelo consistió en los siguientes pasos: especificación de requisitos, diseño, construcción (o codificación en términos de hoy), integración, pruebas y depuración, instalación y mantenimiento.

• Sashimi Modelo

Sashimi es una verdadera versión modificada del modelo de la cascada. Las fases son algo el mismo que en el modelo de cascada; sólo que esta vez las fases se solapan entre sí que presentan muchas ventajas. Por ejemplo, el tiempo no será en vano, porque antes de la Fase I se completaría, Fase II ya estaría en marcha. Por otra parte, ya que se superponen, por lo que uno puede volver al paso anterior, si lo desea.

• Aorta Ciclo de Vida Modelo

La diferencia en este modelo es que se basan mucho en la retroalimentación que viene de otras fases antes de progresar a la siguiente.

• V Cascada Modelo

Apoya la cascada Modelo V en un programa de desarrollo de software lineal que destaca en el desarrollo equilibrado más que cualquier otra cosa

  

CONCLUSIÓN

El modelo en Cascada es un método clásico de desarrollo de software orientando a proyectos que tengan bien definidos sus requerimientos y que no sean entregados en tiempo corto. Si se analiza el modelo en cascada se enfoca puntos importantes, uno de esos puntos es que este método nació para para la construcción de hardware  y que con el pasar el tiempo se acoplo al desarrollo de software, otro punto es que cuenta con algunas desventajas que han querido ser modificadas por alguno modelos mencionados anteriormente en la documentación.

En definitiva el objeto de estudio supongo  que se logró  conseguir.

 REFERENCIAS

Benington, D. 1983. «Production of Large Computer Programs». IEEE Annals of the History of Computing (IEEE Educational Activities Department). Vol 5. Pag 350 – 361

United States. Navy Mathematical Computing Advisory Panel. 1956, Symposium on advanced programming methods for digital computers, [Washington, D.C.]: Office of Naval Research, Dept. of the Navy, OCLC 10794738

Royce, W. 2014. «Managing the Development of Large Software Systems». Formato PDF. Disponible en: http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

McConnell, M. 1996.  Estimates that «…a requirements defect that is left undetected until construction or maintenance will cost 50 to 200 times as much to fix as it would have cost to fix at requirements time». p. 72

Oxagile. 2014. Waterfall Software Development Model». Formato HTML. Disponible en: http://www.oxagile.com/company/blog/the-waterfall-model/