Queda entregada la práctica 6 de AESM: Modelado con UML.


Modelado Con UML

Práctica 6 (9ª sesión)

Damos comienzo a la práctica 6 - Modelado UML.

En esta práctica realizaremos el modelado UML del proyecto del cual hicimos el documento de especificación de requisitos (práctica 5). La herramienta CASE elegida para construir los modelos es  Gliffy. El reparto de tareas es el siguiente:


Rómulo Espinosa Montoya

• Diagrama de casos de uso
• Diagrama de clases
• Diagramas de interacción
• Dibujar diagramas de interacción
• Diagramas de estados
• Dibujar diagramas de estados
• Diagrama de actividad
• Revisar documento final

Dulce Isis Segarra López

• Diagrama de casos de uso
• Diagrama de clases
• Dibujar diagrama de clases
• Diagramas de interacción
• Dibujar diagramas de interacción
• Diagramas de estados
• Diagrama de actividad
• Unir documento 

Laura Sirvent Collado

• Diagrama de casos de uso
• Dibujar diagrama de casos de uso
• Diagrama de clases
• Diagramas de interacción
• Dibujar diagramas de interacción
• Diagramas de estados
• Diagrama de actividad
• Dibujar diagrama de actividad

El plazo para terminar todas las partes expira el Martes 22 de Mayo de 2012, día en el que toda la documentación será enviada a Dulce Isis Segarra López, que es la encargada de recibir las diferentes partes en esta práctica. Para la unión de las diferentes partes y para la revisión de las mismas, cada miembro del grupo irá subiendo las versiones de su parte a Google Docs.

Práctica 5 (8ª Sesión)

En esta sesión el grupo se ha dedicado a continuar la práctica y ha resolver las dudas que ha ido apareciendo a los largo el desarrollo de la práctica.

Práctica 5 (7ª Sesión)

Damos comienzo a la práctica 5 - Análisis y especificación de requisitos

Debemos de realizar un análisis y especificación de los requisitos de manera formal del proyecto de red social realizado en la asignatura del primer cuatrimestre Sistemas Multimedia. Hemos concluido en el reparto de tareas de la práctica, quedando la misma de la siguiente forma:

Rómulo Espinosa Montoya

• Introducción: Definiciones, acrónimos y abreviaturas, referencias y resumen
• Descripción General: Perspectiva del producto y funcionalidad del producto
• Requisitos: Requisitos funcionales
• Apéndices
• Dar formato a todo el documento y cohesionar las partes

Dulce Isis Segarra López

• Introducción: Alcance y personal involucrado
• Descripción General: Suposiciones y dependencias y evolución previsible del sistema
• Requisitos Específicos: Requisitos comunes de los interfaces
• Corrección ortográfica

Laura Sirvent Collado

• Introducción: Introducción y propósito
• Descripción General: Características de los usuarios y restricciones
• Requisitos: Requisitos no funcionales, otros requisitos
• Revisión del documento

El plazo para terminar todas las partes expira el Lunes 2 de Abril de 2012, día en el que toda la documentación será enviada a Laura Sirvent Collado, que es la encargada de recibir las diferentes partes en esta práctica. Para la unión de las diferentes partes y para la revisión de las mismas, cada miembro del grupo irá subiendo las versiones de su parte a Google Docs.  

Práctica5-AESM

Refactorización en la práctica: peligros y soluciones - Resumen y preguntas

Resumen

INTRODUCCIÓN

Refactorizar es una práctica muy importante dentro de las metodologías ágiles, como Extreme Programming. Implica hacer modificaciones en el código para así mejorar su estructura interna sin variar el comportamiento del mismo. Por tanto, no es una técnica para modificar la aplicación, o encontrar y corregir errores. Refactorizar más bien consiste en hacer cambios pequeños en el código pero sin variar su comportamiendo, siempre manteniendo el control y sin cometer equivocaciones. Se propone seguir ciertas técnicas matemáticas con el fin de reducir partes complejas del código en partes mucho más simples, y que a fin de cuentas, hacen lo mismo.

Aún así, es importante conocer que en la práctica hay que tener en cuenta ciertos factores que puedan entorpecer o complicar el proceso de refactorización. Factores como por ejemplo el factor humano, que al tener un exceso de celo en querer conseguir un diseño y código perfecto, se pierda demasiado tiempo en realizar infinitas refactorizaciones, o el hecho de estar trabajando en equipo, donde hay que llevar sumo cuidado en la sincronización de las tareas y escuchar a todos los miembros del equipo en sus posibles propuestas de rediseño o refactorización del código.

CARACTERÍSTICAS

Mediante la refactorización obtendremos en nuestro proyecto las siguientes características:

• Calidad: un código de calidad trata de un código sencillo y bien estructurado de forma que cualquiera pueda leerlo y entenderlo en poco tiempo. Esta calidad se obtiene gracias al continuo proceso de reflexión que se lleva a cabo sobre el código pudiendo corregirlo y simplificarlo.
• Eficiencia: gracias a la refactorización obtendremos un código eficiente al evitar la duplicación de código y al simplificarlo, ya que esto nos facilita la modificación y correcion de código y el añadir nuevas funciones.
• Diseño Evolutivo en lugar de Gran Diseño Inicial: se realizará un buen diseño a partir de un simple diseño inicial que sólo represente algunas funcionalidades. Esto se debe a que se va refactorizando el diseño y poco a poco se van añadiendo nuevas funciones haciendo un diseño más completo. El diseño inicial sólo contemplará algunas funcionalidades debido a que inicialmente no se suelen tener claros los requisitos.
• Evitar la Reescritura de código: hay que enfrentarse al código y refactorizarlo en vez de reescribirlo por no seguir los mismos estándares del código ya existente.

CONCLUSIONES

Refactorizar es una técnica muy útil ya que suele abordar uno de los puntos débiles de muchos de los proyectos software, el código.  En muchos proyectos se suele crear el código y comprobar que funcione, pero son pocas las ocasiones en las que se refactoriza el código, es decir, se trata de simplificar y estructurar de tal forma que sea lo más eficiente y claro posible, eliminando redundancias, clases, variables, etc….  Gracias a la posibilidad  de preparar el código para poder adaptarse a cambios en el sistema, esta técnica es empleada sobre todo en el desarrollo ágil de software.

Pero hay ciertos problemas asociados a esta técnica que hacen que algunos equipos no quieran hacer uso de la misma. Esto es debido a que la técnica de refactorizar no ofrece resultados a simple vista, y en muchas ocasiones, se suele pensar que no es útil, sin embargo mantener el código estructurado y simple, puede facilitar futuras pruebas y modificaciones, pudiendo adaptar el código del sistema a construir fácilmente cuando se producen cambios en los requisitos o especificaciones. Otro problema de la factorización es la necesidad de un buen entendimiento entre todo el equipo de desarrollo ya que un cambio por parte de un desarrollador a la hora de refactorizar, puede afectar al resto del equipo, esto puede hacer que el equipo se muestre reticente a refactorizar. Además los desarrolladores encargados de refactorizar pueden sentirse menospreciados por tener que realizar esta tarea y no la de crear código, aunque sea una tan tarea de suma importancia. Por último, un problema muy habitual de esta técnica, es que se emplea la refactorización de código pero no de forma asidua, de tal forma que tratar de refactorizar un código avanzado, amplio y con muchas funcionalidades, se vuelve una tarea demasiado costosa.

En conclusión, refactorizar es una técnica que requiere de un equipo comprometido y crea firmemente en que la refactorización ayuda a crear software de calidad y que se trata de una técnica muy valiosa.

Enlaces utilizados:

• http://www.willydev.net/descargas/WillyDev_Refactorizacion.pdf
• http://es.wikipedia.org/wiki/Refactorizaci%C3%B3n

Preguntas tipo test:

1. La refactorización:

1. Es una técnica en desuso
2. Es idea poco realista por su elevada complejidad
3. Se asemeja a las pruebas unitarias
4. Ninguna de las anteriores

2. Sobre la refactorización:

1. Consiste en tener el mínimo código aunque se pierda funcionalidad.
2. Se basa en simplificar y estructurar el código.
3. Motiva cambios en el código para cambiar la funcionalidad del mismo.
4. Ninguna de las anteriores

3. En refactorización, ¿qué es un “Bad Smell”?

1. Encontramos una parte del programa que no funciona y no sabemos encontrar el por qué.
2. Secciones de código que nos indican que el desarrollo funciona perfectamente y sin problemas.
3. Secciones de código que nos indican que el programa puede volverse problemático o inmanejable si seguimos desarrollándolo.
4. Ninguna de las anteriores.

4. La refactorización continua:

1. Consiste en refactorizar el código cada cierto intervalo de tiempo determinado.
2. Consiste en refactorizar cada vez que se acaba una parte del código, cuando está reciente.
3. Consiste en refactorizar el código al final de cada iteración.
4. Ninguna de las anteriores.

5. La realización de pruebas automáticas:

1. No es necesario en la refactorización, ya que no supone riesgo.
2. Es necesario en la refactorización, ya que el no realizar prueba conllevaría un alto riesgo en la refactorización.
3. Es necesario realizar pruebas automáticas, pero sólo en algunas partes de código.
4. Ninguna de la anteriores.

6. Los pasos de la refactorización son:

1. Pruebas, Herramientas, Formar sobre patrones de refactorización, refactorizar los principales fallos de diseño, refactorizar al final del desarrollo.
2. Pruebas, Herramientas, Formar sobre patrones de refactorización y arquitectura, refactorizar los principales fallos de arquitectura, refactorizar cada nueva funcionalidad.
3. Pruebas, Herramientas, Formar sobre patrones de refactorización y diseño, refactorizar los principales fallos de diseño, refactorizar cada nueva funcionalidad, refacorización continua al completo.
4. Ninguna de las anteriores.

7. La refactorización en el trabajo en equipo supone:

1. Coordinarse en el trabajo de refactorización, porque podrían modificarse archivos que están siendo modificados simultaneamente por otros desarrolladores.
2. Que si un miembro del equipo encuentra una idea diferente a la que se está llevando a cabo, comunicarlo en base a una posible refactorización.
3. Reunirse diariamente el equipo de desarrolladores para plantear las posibles refactorizaciones a llevar a cabo.
4. Todas son correctas.

8. La características de un código simple son:

1. Que el código funciones.
2. Que no haya código duplicado.
3. Que el código permita entender el diseño.
4. Todas las anteriores.

Microsoft patterns & practices - Resumen y preguntas

Resumen

INTRODUCCIÓN

Microsoft Patterns & Practices son una serie de recomendaciones probadas y seguidas por el equipo de desarrollo de Microsoft, que explican cómo se debe diseñar, desarrollar,  desplegar y operar una aplicación para que pueda operar con la arquitectura de la plataforma Microsoft. El equipo de desarrollo sigue la filosofía de las metodologías ágiles, empleando un híbrido entre Scrum y Extreme Programming. Gracias a esto pueden entregar de forma incremental versiones del producto para que el cliente pueda retroalimentar al equipo lo más rápido posible y que el resultado final satisfaga sus exigencias de la forma más completa posible.

Otro punto importante es la distribución del equipo. En los equipos que siguen una metodología ágil, prima la idea de agrupar a todo el equipo de desarrollo y al cliente en una única habitación, pero no siempre será posible pues existen algunos elementos externos que hacen que los equipos sean más distribuidos:

• Mercados mundiales (Global Markets):  en muchas ocasiones las empresas se expanden hacia nuevos mercados, necesitando pues equipos especializados en estos mercados, quizá se lleven a cabo fusiones o adquisiciones, teniendo parte del equipo en una localización diferente.
• Talento global (Global Talent): las empresas suelen buscar empleados experimentados en otras ciudades o incluso otros países. Para ello es necesario disponer de visas de trabajo, soportar los costes de reubicación y contar con el deseo del nuevo empleado de trasladarse.
• Reducción de los costes: a menudo las empresas buscan reducir costes mediante la externalización de ciertos servicios,  teniendo pues equipos en diferentes países. En cualquier caso habrá que tener en cuenta una serie de factores como la reducción de la productividad o los costes adicionales de los viajes para saber si es una opción rentable ya que la reducción de los costes de desarrollo no siempre será suficiente.

Usualmente, el equipo de Patterns & Practices, se compone de owners (propietarios o dueños), developers (desarrolladores), testers (probadores) y documentation writers (redactores de documentación o documentalistas), además si es necesario se unen al equipo expertos de la materia sobre la que se va a trabajar.

En cualquier caso existen una serie de roles con unas responsabilidades asociadas a cada uno:

• Product Owner: es el responsable de representar al cliente, además ayuda al equipo de desarrollo para que puedan entender de forma correcta los requerimientos del mismo.
• Coach: El coach o Scrum Master es el principal responsable de cómo trabaja el equipo, se encarga básicamente de supervisar todo el trabajo y de aportar la retroalimentación necesaria para que todo el equipo trabaje en equipo.
• Team Member: el equipo está compuesto por desarrolladores, testers o probadores y documentalistas.
• Expertos en la materia: se trata de expertos que se incluyen en el equipo siempre que sea necesario pues aportan información valiosa sobre temas concretos.

CARACTERÍSTICAS

Enfocado a la comunicación: los miembros del equipo han de poder comunicarse fácilmente en caso de haber alguna reunión, tener dudas a la hora de realizar una tarea, necesitar la ayuda de un miembro del equipo o comunicarse con el cliente. Por ello, han de tener a su alcance software que les permita comunicarse, por ejemplo por videoconferencia, o una sala cercana a todos ellos con las herramientas necesarias para una reunión (proyector...). Para ello, Microsoft patterns & practices utiliza para comunicarse, teléfonos de mesa, Windows Live Messenger y Office Communicator.

Viajes: en Microsoft patterns & practices en muchas ocasiones se realizan viajes al comienzo, durante y al final del proyecto en los que se reúnen los equipos del mismo con el fin de hacer mejoras en los proyectos, tener retroalimentación entre los equipos o por la necesidad mandar un especialista a otro proyecto en el que no hay este tipo de especialista.

Distribución del equipo: en Microsoft patterns & practices los equipos están distribuidos en diferentes partes del mundo con diferencias horarias significativas. A pesar de ello, son capaces de coordinar a cada uno de los equipos para que cuando cada uno de los equipos llegué a su puesto de trabajo sea capaz de saber que tiene que hacer en función de que han hecho los demás equipos.

Enfocado a dirigir al equipo: en Microsoft patterns & practices se ha guiado al equipo de forma que ellos eligan que metodología es mejor para su forma de trabajo.

Distribución del trabajo: en muchas ocasiones, debido a la distribución del trabajo en diversas partes del mundo, puede que en un proyecto se perciba inconsistente. Por ello, en Microsoft patterns & practices, los distintos equipos se comunican y transfieren sus conocimientos mediante sesiones de emparejamiento y diseño. Todo ello con el objetivo de emparejar y revisar el código independientemente de la zona geográfica.

Construcción del equipo: en múltiples ocasiones no se mantienen los mismos equipos y se contrata a nuevos miembros. El problema de esta situación es que los nuevos miembros pueden tardar en adaptarse a la forma de trabajo del equipo ya existente por falta de docmentación de anteriores proyectos y retrasar el desarrollo de nuevas veriones de un proyecto. Por ello, en Microsoft patterns & practices se intenta mantener al menos a la mitad del equipo, que hizo un proyecto, para la realización de otra versión de dicho proyecto. También se utiliza SharePoint wikis para almacenar la documentación de los proyectos y así poder documentar y poner al día a los nuevos miembros.

Proporcionar la herramientas adecuadas: Microsoft patterns & practices utiliza una serie de herramientas útiles para un seguimiento progresivo y entornos distribuidos:

• Visual Studio Team System
• Scrum for Team System

CONCLUSIONES

Utilizar el desarrollo ágil en equipos distribuidos en mayor o menor grado puede ser satisfactorio para el negocio ya que podemos formar un equipo con mucho talento buscando los mejores miembros en ámbito mundial para cada rol del proceso de desarrollo, disminuyendo además los costes.

Microsoft con sus equipos patterns & practices ha conseguido llegar a esta meta con éxito, aunque siempre siendo consciente de unos posibles inconvenientes que pueden generarse a partir de crear un equipo de desarrollo distribuido, sabiendo que hay que apoyar en todo momento al equipo, facilitando siempre la comunicación entre los miembros, ya sea facilitando y proveyendo los medios para que esta comunicación sea satisfactoria.

Además, otra característica de patterns & practices es centrarse en las historias de usuario ante todo, y desarrollar en base a estas historias, y no en base a funcionalidades o componentes. También es importante para mantener la disciplina en un desarrollo ágil, y más en un equipo distribuido, establecer un rol de coach que ayude a supervisar el trabajo realizado. Otro punto de vital importancia es no realizar cambios drásticos en el equipo de desarrollo de un proyecto a otro, es decir, intentar mantenerlo en el tiempo, o realizar los cambios lenta y gradualmente.

En definitiva, seguir las pautas que Microsoft ha establecido en patterns & practices puede ser satisfactoria y tener un alto grado de éxito para un equipo ágil y distribuido, siempre buscando la mejor forma para mantener un buen ambiente en el equipo y a su vez desarrollando software provechoso y que cumpla las expectativas iniciales.

Enlaces utilizados:

• http://msdn.microsoft.com/en-us/practices/ff921345
• http://www.google.es/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cts=1331660450287&ved=0CEAQFjAC&url=http%3A%2F%2Fdownload.microsoft.com%2Fdownload%2F4%2F4%2Fa%2F44a2cebd-63fb-4379-898d-9cf24822c6cc%2Fdistributed_agile_development_at_microsoft_patterns_and_practices.pdf&ei=oIZfT5PJGuPS0QW4vdiPBw&usg=AFQjCNFj33D_qk-IiFQ7IivjuM15v1NbNQ&sig2=kUxflQCH6hAUGcc_Tg37ZQ
• http://netindonesia.net/blogs/wely/archive/2008/07/28/microsoft-patterns-and-practices-an-introduction.aspx

Preguntas tipo test:

1. Los roles presentes en Microsoft Patterns & Practices son:

1. Product Owner, Coach o Scrum Master, Team Member, Expertos en la materia (opional)
2. Product Owner, Team Member
3. Product Owner, Coach o Scrum Master, Team Member
4. Product Owner, Coach o Scrum Master, Team Member, Expertos en la materia

2. Microsoft Patterns & Practices nos ofrece un catálogo de directrices para la construcción de aplicaciones:

1. En la nube
2. De escritorio
3. Web
4. Todas las anteriores

3. Microsoft patterns & practices se basa en las metodologías ágiles:

1. Scrum y Extreme Programming
2. Kanban y Extreme Programming
3. Kanban y Scrum.
4. Ninguna de las anteriores.

4. Cada patterns & practices ofertada es desarrollada:

1. En una comunidad pública conocida como CodePlex.
2. De forma privada, por un equipo de desarrollo conocido como CodePlex.
3. Únicamente por el equipo de desarrollo de Microsoft.
4. Ninguna de las anteriores.

5. Sobre Microsoft patterns & practices:

1. Sigue metodologías tradicionales
2. No externaliza parte de su equipo
3. No emplean roles
4. Ninguna de las anteriores.

6. Microsoft patterns & practices:

1. Recomienda hacer nuevos equipos o grupos de trabajo para cada nuevo proyecto.
2. Recomienta reorganizar el equipo para cada nuevo proyecto.
3. Recomienta no reorganizar continuamente el equipo para cada nuevo proyecto.
4. Ninguna de las anteriores.

7. Los equipos Microsoft patterns & practices:

1. Obligatoriamente deben estar físicamente presentes en un mismo lugar.
2. Igualmente que los equipos de Microsoft, están en un mismo edificio.
3. Suelen estar distribuidos en mayor o menor grado.
4. Ninguna de las anteriores.

8. La distribución de tareas para patterns & practices:

1. Debe hacerse pensando siempre en las funcionalidades del sistema, y no en las historias de usuario.
2. Debe hacerse pensando individualmente en cada historia de usuario.
3. Debe hacerse en función de la localización geográfica de los miembros del equipo.
4. Las anteriores son correctas.

Práctica 4 (6ª Sesión)

En esta sesión el grupo se ha dedicado a la revisión y mejora de la práctica 4. Una vez hecho esto se ha comenzado a realizar la preguntas tipos test de la actividad complementaria.