lunes, 7 de julio de 2014

Todo

El patrón Estrategia (Strategy)

Propósito

Define una familia de algoritmos, encapsula cada uno de ellos y los hace intercambiables. Permite que un algoritmo varié independientemente de los clientes que lo usan.

Aplicabilidad

Muchas clases relacionadas difieren solo en su comportamiento. Las estrategias permiten configurar una clase con un determinado comportamiento entre muchos posibles.
Se necesitan distintas variantes de un algoritmo.
Un algoritmo usa daos que los clientes no deberían conocer. Use el patón Strategy para evitar exponer estructuras de datos complejas y dependientes del algoritmo
Una clase define muchos comportamientos y estos se representan como múltiples sentencias condicionales en sus operaciones. En vez de tener muchos condicionales, podemos mover las ramas de estos a sus propias clases estrategia

Estructura del Patrón de comportamiento Estrategia (GOF)

Participantes

Estrategia (Componedor)
- Declara la interfaz común a todos los algoritmos permitidos.
- El *contexto* usa esa interfaz para llamar al algoritmo definido por una estrategia
Estrategia Concreta
- Implementa el algoritmo concreto
Contexto
- Instancia un objeto Estrategia Concreta
- Mantiene una referencia la un objeto estrategia (concreta)
- Puede definir una interfaz que permita a la Estrategia (concreta) acceder a sus datos

Consecuencias

Familias de algoritmos relacionados.: Las jerarquías de clases Estrategia definen una familia de algoritmos o comportamientos
Una alternativa a la herencia.: La herencia ofrece otra forma de permitir una variedad de algoritmos o comportamientos. Se puede heredar directamente de una clase contexto para proporcionar diferentes comportamientos. Pero esto liga el comportamiento al Contexto, mezclando la implementación del algoritmo con la del Contexto, lo que hace que éste sea más difícil de comprender, mantener y extender. Y no se puede modificar el algoritmo dinámicamente. Acabaremos teniendo muchas clases relacionadas cuya única diferencia es el algoritmo o comportamiento que utilizan. Encapsular el algoritmo en clases Estrategia separadas nos permite variar el algoritmo independientemente de su contexto, haciéndolo más fácil de cambiar, comprender y extender.
Las estrategias eliminan las sentencias condicionales.: El patrón estrategia ofrece una alternativa a las sentencias condicionales para seleccionar el comportamiento deseado. Cuando se juntan muchos comportamientos en una clase es difícil no usar sentencias condicionales para seleccionar el comportamiento correcto. Encapsular el comportamiento en clases estrategias separadas elimina estas sentencias condicionales, delegando la tarea en el objeto estrategia.
Los clientes deben conocer las diferentes estrategias.: el patrón tiene el inconveniente potencial de que un cliente debe comprender como difieren las Estrategias antes de seleccionar la adecuada. Los clientes pueden estar expuestos a cuestiones de i implementación. Por lo tanto, el patrón estrategia debería usarse solo cuando la variación del comportamiento sea relevante a los clientes.
Costes de comunicación entre Estrategia y Contexto.: La interfaz de Estrategia es compartida por todas las clases Estrategia Concreta, ya sea el algoritmo que implementa trivial o completamente. Por lo tanto, es probable que algunos objetos Estrategia Completa no usen toda la información que reciben a través de dicha interfaz; las estrategias concretas simples pueden incluso no utilizar nada de dicha información. Esto significa que habrá veces en las que el contexto crea e inicializa parámetros que nunca e utilizan. Si esto puede ser un problema, necesitaremos un acoplamiento más fuerte entre Estrategia y Contexto
Mayor numero de objetos.: Las estrategias aumentan el número de objetos de una aplicación. A veces se puede reducir este coste implementando estrategias como objetos sin estado que puedes ser compartida por el contexto. El contexto mantiene cualquier estad residual, pasándolo en cada petición de al objeto estrategia. Las estrategias compartidas no deberían mantener el estado entre invocaciones.

Bibliografia:

Hernández Tejada,David (2002), Teleprogramadores.com

DEFINICIÓN Y CONCEPTO DE UML

UML son las siglas de “Unified Modeling Language” o “Lenguaje Unificado de Modelado”. Se trata de un estándar que se ha adoptado a nivel internacional por numerosos organismos y empresas para crear esquemas, diagramas y documentación relativa a los desarrollos de software (programas informáticos).

¿QUÉ ES Y PARA QUÉ SIRVE UML?

El término “lenguaje” ha generado bastante confusión respecto a lo que es UML. En realidad el término lenguaje quizás no es el más apropiado, ya que no es un lenguaje propiamente dicho, sino una serie de normas y estándares gráficos respecto a cómo se deben representar los esquemas relativos al software. Mucha gente piensa por confusión que UML es un lenguaje de programación y esta idea es errónea: UML no es un lenguaje de programación. Como decimos, UML son una serie de normas y estándares que dicen cómo se debe representar algo.

UML es una herramienta propia de personas que tienen conocimientos relativamente avanzados de programación y es frecuentemente usada por analistas funcionales (aquellos que definen qué debe hacer un programa sin entrar a escribir el código) y analistas-programadores (aquellos que dado un problema, lo estudian y escriben el código informático para resolverlo en un lenguaje como Java, C#, Python o cualquier otro). Por tanto si estás dando tus primeros pasos en programación, te recomendaríamos que te olvides de UML hasta que tengas unos conocimientos mínimos como uso de condicionales, bucles, y conocimiento de la programación orientada a objetos. Esto es solo una recomendación, en realidad prácticamente cualquier persona puede usar UML, incluso podría usarse para realizar esquemas o documentación de procesos que no tengan que ver con la informática.

Hemos dicho que UML es un estándar. Vamos a aclarar primero qué es un estándar. Supongamos que vamos a definir un estándar llamado “LMAPR” o lenguaje de modelado de aprenderaprogramar.com. Ahora definimos dentro de nuestro estándar estas normas:

Un animal debe representarse con su nombre escrito enteramente en minúsculas enmarcado dentro de un rectángulo doble. Encima del nombre debe etiquetarse el tipo de animal así: <<Tipo de Animal>>. Por ejemplo, <<Gato>>.

Si un animal envía un mensaje a otro animal deben conectarse los dos animales con una línea punteada terminada en flecha encima de la cual debe figurar el texto msg(“Contenido del mensaje”).

Ahora supongamos que tenemos dos gatos, uno de los cuales le dice al otro “Caza un ratón y tráemelo aquí por favor”. Veamos formas de representar esto:

Esta es una forma de representación. Sin embargo, no se adapta al estándar que hemos definido por varios motivos: no indica <<Gato>> encima de los nombres de los animales, no escribe los nombres en minúsculas, no representa los animales con un rectángulo, etc.

Veamos la representación que sí se adaptaría al estándar definido:

Con este ejemplo sencillo hemos tratado de hacer explícito qué es y para qué sirve UML: un conjunto de normas que nos dicen cómo hay que representar esquemas de software. En el caso del software orientado a objetos, en vez de gatos tendremos clases u objetos instanciados, y dispondremos de numerosos tipos de esquemas y diagramas para representar distintas cosas. Un esquema que cumple las normas UML podría tener este aspecto:

O también este otro:

¿Por qué si ambos esquemas cumplen con UML tienen un aspecto tan distinto? Porque UML define normas para construir muchos tipos de esquemas, no esquemas de un solo tipo.

¿Quién usa UML? UML lo suelen usar las empresas o medianos o grandes equipos de desarrollo software con el objetivo de planificar y documentar cómo se construyen los programas informáticos complejos. Los usuarios individuales o pequeños equipos de desarrollo de 2 ó 3 personas no suelen usar herramientas UML. UML es un término que se relaciona mucho con “Ingeniería del software”. Al igual que un proyecto de edificio requiere la participación de un arquitecto y unos plantos, un proyecto software requiere la participación de ingenieros informáticos y una planificación y documentación.

Elementos

Ejemplo:

Supongamos que tenemos tenemos un el caso del Diccionario implementado mediante un árbol binario, en donde cada nodo posee:

key: Variable por la cual se realiza la búsqueda, puede ser generica.

item: Contenido a almacenar en el diccionario asociado a "key", cuyo tipo también puede ser genérico.

Para este caso particular hemos definido un Diccionario para almacenar String y Personas, las cuales pueden funcionar como llaves o como item, solo se mostrarán las relaciones para la implementación del Diccionario:

Bibliografia

http://www.aprenderaprogramar.com/index.php?option=com_attachments&task=download&id=611

Diagramas de actividades

Capturar las acciones internas de un proceso.

Son abstracciones a nivel muy alto relacionadas entre sí presentando todos los procesos todos los procesos que ocurren dentro del sistema

Un diagrama de actividades muestra un flujo de acciones (nodos ejecutan un proceso), generalmente secuencias además presentan los resultados de dichas acciones

Usos.

· Capturar las acciones internas de un proceso.

· Capturar la especificación de un caso de uso.

· Mostrar flujos entre procesos del negocio.

Simbología

Figura 1.- Simbología ocupada en diagramas de actividades

Unión Es en el nodo donde se combinan los caminos de un no do de decisión. Marca el fin condicional.

Ejemplo de consignación la secuencia de acciones que se realiza para hacer una consignación en una entidad bancaria. Cada actividad se realiza cuando finaliza la actividad anterior. Cuando uno llna el formato antes de entregarlo, junto con el dinero, al cajero.

Figuran 2 Asignaciones

Acciones.

La actividad es el proceso de hacer algo. Las acciones son un paso en toda la actividad.

Ejemplo:

Actividad: Lavar un auto

Acciones: enjabonar, enjuagar, secar (Figura 3)

Figura 3 : Acciones de Diagrama de Actividades

Las decisiones son usadas cuando se quiere seguir alguna acción dependiendo de cierta condición figura 4

Figura 4:

Los caminos que salen del diamante tiene un nombre entre [] el cual indica la condición por la cual se toma ese camino.

Dicha condición se evalúa con un ture o false figura 5

Figura 5

Si algunas acciones no dependen de otra, puede ocurrir al mismo tiempo, en paralelo , se señalan utilizando forks y joins

Figura 7:

Después de un fork , el flujo se separa en dos o más caminos simultáneos, todas las acciones que surjan en el camino se ejecutan al mismo tiempo.

No todos los caminos se terminarán al mismo tiempo.

El join marca el nodo en donde se esperará a que todos los caminos simultáneos hayan terminado sus tareas. No se puede proceder después del join sin haber terminado todos los caminos anteriores.

Metodo Delphi

El primer estudio de Delphi fue realizado en 1950 por la Rand Corporation para la fuerza aérea de Estados Unidos, y se le dio el nombre de Proyecto Delphi. Su objetivo era la aplicación de la opinión de expertos a la selección de un sistema industrial norteamericano óptimo y la estimación del número de bombas requeridas para reducir la producción de municiones hasta un cierto monto.

Es un método de estructuración de un proceso de comunicación grupal que es efectivo a la hora de permitir a un grupo de individuos, como un todo, tratar un problema complejo. (Linstone y Turoff, 1975)

La capacidad de predicción de la Delphi se basa en la utilización sistemática de un juicio intuitivo emitido por un grupo de expertos.

El objetivo de los cuestionarios sucesivos, es “disminuir el espacio intercuartil, esto es cuanto se desvía la opinión del experto de la opinión del conjunto, precisando la mediana”, de las respuestas obtenidas.

Dentro de los métodos de pronóstico, habitualmente se clasifica al método delphi dentro de los métodos cualitativos o subjetivos.

La calidad de los resultados depende, sobre todo, del cuidado que se ponga en la elaboración del cuestionario y en la elección de los expertos consultados.

El proceso operativo del Método Delphi se puede desglosar en las siguientes fases:

1. Selección del tema y las personas responsables de la organización del proceso de encuesta. Debido a que las preguntas deben ser cerradas, debe prestarse especial atención a los temas cubiertos en las mismas, para extraer de la forma más precisa posible la información.
2. Selección de expertos. En todas las investigaciones basadas en el Método Delphi, el rol que ejerce cada participante es crucial. Por tanto, todos deben ser especialistas en el campo determinado que se estime necesario.
3. Desarrollo de cuestionarios para la primera etapa de la encuesta. Los organizadores necesitan decidir el número de rondas de cuestionario (las preguntas del formulario deben ser claras y estar enunciadas de forma que faciliten la recogida estadística de datos)
4. En el primer formulario de encuesta también se pide a los expertos una evaluación sobre sus conocimientos y competencias sobre el tema a tratar (la evaluación solo se realiza una vez en todo el proceso)
5. E necesario hacer una lectura en profundidad, y una edición del primer cuestionario (revisando los errores ortográficos y lógicos, y eliminando aquellas cuestiones poco clara o ambiguas)
6. Tras esto, puede hacerse el envío de los primeros cuestionarios a los expertos (por correo o e-mail), esperando su respuesta en un plazo estimado de 10 días.
7. Recopilación, análisis y elaboración de resultados de la primera etapa de la encuesta (presentación estadística de resultados)
8. Elaboración del segundo cuestionario –las preguntas son más concretas y detalladas- Además de las preguntas, se incluyen los resultados y opiniones de la primera fase. Si uno o varios de los expertos tienen una opinión totalmente diferente de la tendencia general o del consenso alcanzado, se les pide que revisen las otras opiniones, justifiquen su punto de vista y aporten su opinión final (que puede ser la misma o cambiar)
9. Envío del segundo formulario a los expertos
10. Recopilación, análisis y elaboración de resultados de la primera etapa de la encuesta (mismo procedimiento que en la primera fase),
11. El proceso descrito puede repetirse todas las veces que sea preciso para alcanzar un consenso común.
12. La fase final incluye el desarrollo del informe final y presentación de resultados de la encuesta.

Bibliografía
http://www.eoi.es/blogs/nataliasuarez-bustamante/2012/02/11/%C2%BFque-es-el-metodo-delphi/

http://www.google.com.mx/url?sa=t&rct=j&q=&esrc=s&source=web&cd=8&cad=rja&uact=8&ved=0CEIQFjAH&url=http%3A%2F%2Fwww.prospectiva.eu%2Fzaharra%2F03_Delphi_ESTE.pdf&ei=4S6iU-7eG5KaqAb9_4DgDg&usg=AFQjCNEXvA6s0n4v6lSezdt_Sd2hWrQUXA&bvm=bv.69137298,d.b2k

http://www.slideshare.net/camiloan40/diagrama-de-actividades-uml
Dispositivas Dr. Juan Manuel Gonzalez Calleros

Modelado de Tareas
Introducción

Hoy en día cualquier proyecto que se lleve a cabo debe llevar una serie de pasos y de tal forma que se formalice y se lleve a un lenguaje estandarizado y unificado

Con esto queremos decir que el desarrollo de todo proyecto y no solo del software sea orientado a objetos, se pueda visualizar, se especifique y se documentó con un lenguaje común ya que esto llevara a la reproducción del mismo siguiendo los pasos documentados.

Este lenguaje unificado que cumple con estos requerimientos, es ciertamente UML, el cual cuenta con una notación estándar y semánticas esenciales, para el modelado de un sistema orientado a objetos.

El UML unido a un gestión de calidad, evita malos entendidos y entrega ciertas precauciones en la evolución y mantención de programas. Especialmente en lo referente a los requerimientos asociados al levantamiento y diseño funcional de un sistema. En efecto, por ejemplo con los Clientes Dilema, quienes no podrán hacer pensar que el cambio que están solicitando es pequeño, cuando detrás de la petición existe una enorme cantidad de tareas relacionadas al requerimiento.

Qué es UML?

El Lenguaje de Modelado Unificado (UML:Unified Modeling Language) es la sucesión de una serie de métodos de análisis y diseño orientadas a objetos que aparecen a fines de los 80's y principios de los 90s.UML es llamado un lenguaje de modelado, no un método. Los métodos consisten de ambos de un lenguaje de modelado y de un proceso.

El UML , fusiona los conceptos de la orientación a objetos aportados por Booch, OMT y OOSE (Booch, G. et al., 1999).

UML incrementa la capacidad de lo que se puede hacer con otros métodos de análisis y diseño orientados a objetos. Los autores de UML apuntaron también al modelado de sistemas distribuidos y concurrentes para asegurar que el lenguaje maneje adecuadamente estos dominios.

El lenguaje de modelado es la notación (principalmente gráfica) que usan los métodos para expresar un diseño. El proceso indica los pasos que se deben seguir para llegar a un diseño.

La estandarización de un lenguaje de modelado es invaluable, ya que es la parte principal del proceso de comunicación que requieren todos los agentes involucrados en un proyecto informático. Si se quiere discutir un diseño con alguien más, ambos deben conocer el lenguaje de modelado y no así el proceso que se siguió para obtenerlo.

Ver RobotDocIRS y ¿Cuáles son las características que debe tener una herramienta UML?

Semántica y Notación

Una de la metas principales de UML es avanzar en el estado de la integración institucional proporcionando herramientas de interoperabilidad para el modelado visual de objetos. Sin embargo para lograr un intercambio exitoso de modelos de información entre herramientas, se requirió definir a UML una semántica y una notación.

La notación es la parte gráfica que se ve en los modelos y representa la sintaxis del lenguaje de modelado. Por ejemplo, la notación del diagrama de clases define como se representan los elementos y conceptos como son: una clase, una asociación y una multiplicidad. ¿Y qué significa exactamente una asociación o multiplicidad en una clase?. Un metamodelo es la manera de definir esto (un diagrama, usualmente de clases, que define la notación).

Para que un proveedor diga que cumple con UML debe cubrir con la semántica y con la notación.

Una herramienta de UML debe mantener la consistencia entre los diagramas en un mismo modelo. Bajo esta definición una herramienta que solo dibuje, no puede cumplir con la notación de UML.

El lenguaje está dotado de múltiples herramientas para lograr la especificación determinante del modelo, pero en nuestro caso se trabaja en forma simplificada sobre:
•Modelamiento de Clases
•Casos de Uso
•Diagrama de Interacción

•Los diagramas de clases de UML forman la vista lógica.

•Los diagramas de interacción de UML constituyen la vista de proceso.

•La vista de desarrollo captura el software en su entorno de desarrollo.

• Los diagramas de despliegue integran la vista física .

•Los escenarios: el modelo de casos de uso.

Casos de Uso (Use Case)

Introducción

El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactuan (operaciones o casos de uso).
Un diagrama de casos de uso consta de los siguientes elementos:
•Actor.

•Casos de Uso.

•Relaciones de Uso, Herencia y Comunicación.

Elementos
•Actor:

Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema.
Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local.
•Caso de Uso:

Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.

•Relaciones: ◦Asociación

◦Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.

◦Dependencia o Instanciación

Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.
◦Generalización

Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).

Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).
extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características).
uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.
De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde esta la duda clásica de usar o heredar.

bibliógrafa
Ceria, Santiago, 2014 Casos de Uso Un Método Práctico para Explorar Requerimientos, Ingeniería de Software I Texto recuperado URL http://www-2.dc.uba.ar/materias/isoft1/2001_2/apuntes/CasosDeUso.PDF
11-06-2014

Metodologías tradicionales

Las metodologías tradicionales son denominadas, a veces, de forma peyorativa, como metodologías pesadas.

Centran su atención en llevar una documentación exhaustiva de todo el proyecto y en cumplir con un plan de proyecto, definido todo esto, en la fase inicial del desarrollo del proyecto.

Otra de las características importantes dentro de este enfoque, son los altos costes al implementar un cambio y la falta de flexibilidad en proyectos donde el entorno es volátil.

Las metodologías tradicionales (formales) se focalizan en la documentación, planificación y procesos (plantillas, técnicas de administración, revisiones, etc.)

METODOLOGÍAS ÁGILES

Historia

En febrero de 2001, tras una reunión celebrada en Utah-EEUU, nace el término “ágil” aplicado

al desarrollo de software. En esta reunión participan un grupo de 17 expertos de la industria del

software, incluyendo algunos de los creadores o impulsores de metodologías de software. Su

objetivo fue esbozar los valores y principios que deberían permitir a los equipos desarrollar

software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto.

Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales,

caracterizados por ser rígidos y dirigidos por la documentación que se genera en cada una de las

actividades desarrolladas.

Tras esta reunión se creó The Agile Alliance3, una organización, sin ánimo de lucro, dedicada a

promover los conceptos relacionados con el desarrollo ágil de software y ayudar a las

organizaciones para que adopten dichos conceptos. El punto de partida es fue el Manifiesto

Ágil, un documento que resume la filosofía “ágil”.

Según el Manifiesto se valora:

· Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las

herramientas. La gente es el principal factor de éxito de un proyecto software. Es más

importante construir un buen equipo que construir el entorno. Muchas veces se comete el

error de construir primero el entorno y esperar que el equipo se adapte automáticamente. Es

mejor crear el equipo y que éste configure su propio entorno de desarrollo en base a sus

necesidades.

· Desarrollar software que funciona más que conseguir una buena documentación. La

regla a seguir es “no producir documentos a menos que sean necesarios de forma inmediata

para tomar un decisión importante”. Estos documentos deben ser cortos y centrarse en lo

fundamental.

La colaboración con el cliente más que la negociación de un contrato. Se propone que
exista una interacción constante entre el cliente y el equipo de desarrollo. Esta colaboración
entre ambos será la que marque la marcha del proyecto y asegure su éxito.
· Responder a los cambios más que seguir estrictamente un plan. La habilidad de
responder a los cambios que puedan surgir a los largo del proyecto (cambios en los
requisitos, en la tecnología, en el equipo, etc.) determina también el éxito o fracaso del
mismo. Por lo tanto, la planificación no debe ser estricta sino flexible y abierta.
Los valores anteriores inspiran los doce principios del manifiesto. Son características que
diferencian un proceso ágil de uno tradicional. Los dos primeros principios son generales y
resumen gran parte del espíritu ágil. El resto tienen que ver con el proceso a seguir y con el
equipo de desarrollo, en cuanto metas a seguir y organización del mismo. Los principios son:
I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de
software que le aporte un valor.
II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una
ventaja competitiva.
III. Entregar frecuentemente software que funcione desde un par de semanas a un par de
meses, con el menor intervalo de tiempo posible entre entregas.
IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.
V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que
necesitan y confiar en ellos para conseguir finalizar el trabajo.
VI. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información
dentro de un equipo de desarrollo.
VII. El software que funciona es la medida principal de progreso.
VIII. Los procesos ágiles promueven un desarrollo sostenible. Los promotores,
desarrolladores y usuarios deberían ser capaces de mantener una paz constante.
IX. La atención continua a la calidad técnica y al buen diseño mejora la agilidad.
X. La simplicidad es esencial.
XI. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí
mismos.
XII. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo, y
según esto ajusta su comportamiento.

Otros métodos ágiles

· SCRUM5 [16]. Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. Define un marco para la gestión de proyectos, que se ha utilizado con éxito durante los últimos 10 años. Está especialmente indicada para proyectos con un rápido cambio de requisitos. Sus principales características se pueden resumir en dos. El desarrollo de software se realiza mediante iteraciones, denominadas sprints, con una duración de 30 días. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente. La segunda característica importante son las reuniones a lo largo proyecto, entre ellas destaca la reunión diaria de 15 minutos del equipo de desarrollo para coordinación e integración.

· Crystal Methodologies6 [5]. Se trata de un conjunto de metodologías para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo y la reducción al máximo del número de artefactos producidos. Han sido desarrolladas por Alistair Cockburn. El desarrollo de software se considera un juego cooperativo de invención y comunicación, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, así como tener políticas de trabajo en equipo definidas. Estas políticas dependerán del tamaño del equipo, estableciéndose una clasificación por colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros).

· Dynamic Systems Development Method7 (DSDM) [17]. Define el marco para desarrollar un proceso de producción de software. Nace en 1994 con el objetivo de crear una metodología RAD unificada. Sus principales características son: es un proceso iterativo e incremental y el equipo de desarrollo y el usuario trabajan juntos. Propone cinco fases: estudio viabilidad, estudio del negocio, modelado funcional, diseño y construcción, y finalmente implementación. Las tres últimas son iterativas, además de existir realimentación a todas las fases.

· Adaptive Software Development8 (ASD) [9]. Su impulsor es Jim Highsmith. Sus principales características son: iterativo, orientado a los componentes software más que a las tareas y tolerante a los cambios. El ciclo de vida que propone tiene tres fases esenciales: especulación, colaboración y aprendizaje. En la primera de ellas se inicia el proyecto y se planifican las características del software; en la segunda desarrollan las características y finalmente en la tercera se revisa su calidad, y se entrega al cliente. La revisión de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo.

· Feature -Driven Development9 (FDD) [3]. Define un proceso iterativo que consta de 5 pasos. Las iteraciones son cortas (hasta 2 semanas). Se centra en las fases de diseño e implementación del sistema partiendo de una lista de características que debe reunir el software. Sus impulsores son Jeff De Luca y Peter Coad.

· Lean Development10 (LD) [15]. Definida por Bob Charette’s a partir de su experiencia en proyectos con la industria japonesa del automóvil en los años 80 y utilizada en numerosos proyectos de telecomunicaciones en Europa. En LD, los cambios se consideran riesgos, pero si se manejan adecuadamente se pueden convertir en oportunidades que mejoren la productividad del cliente. Su principal característica es introducir un mecanismo para implementar dichos cambios.

Referencias

(2006 ) METODOLOGÍAS Y CICLOS DE VIDA, recuperado de URL http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema04.PDF

Canos, Joseh. Letelier, Patricio. Penades Ma. Carmen , Métodologías Ágiles en el Desarrollo de Software, Articulo recuperado de http://noqualityinside.com.ar/nqi/nqifiles/XP_Agil.pdf

El trabajo en equipo es : organización

Para ello definamos organización es: que es una unidad social que ha sido creada con la intencion de alcanzar metas especificas sobre una base continua.

La organización de los individuos surge como una manera de superar las limitaciones que tiene, y complementarlas las virtudes que se tiene con un equipo.

Para ello se deben diseñar puestos de trabajo, limitar las funciones que desempeñaran y delegar responsabilidades.

Problemas que impiden la implantación de un trabajo en equipo:

Lideres

La tecnología

Adaptación al entorno

Lideres

En ellos se depositan las expectativas. Creyendo que es un proceso espontaneo y no solo del trabajo o esfuerzo del día a día.

Otro problema radicado en los lideres es no pretender que la su actuación tiene una simbiosis con todos los individuos y creer que solo ellos pueden resolverlo todo.}

La tecnología

El avance y adopción de las tecnologías deja obsoletos algunos procesos para la organización así como redefine otros nuevos

Algunas sugerencias que solo deben usar el enfoque si

· Existe un ambiente igualitario en la organización

· Existe un alto grado de independencia en las funciones de líder con el fin de alcanzar las metas generales en la organización

· Los miembros del equipo están situados bastante cerca unos de otros para reunirse con frecuencia en poco tiempo

Resulta evidente que un punto a favor de las tecnologías de comunicación nos permite realizar grupos de trabajo muy dispersos.

Adaptación del entorno.

Las limitaciones de un nuevo problema y las limitaciones que tiene el grupo para resolverlas, creando con esto nuevos grupos para subsanar dichas carencias y poder resolver el nuevo problema.

Administración de proyectos.

Es un área de vital importancia para desarrollar cualquier proyecto

Habilidades de gestión

- Técnicas: Aplicaciones de métodos, procesos y procedimientos

- Humanas: Entendimiento de la Psique humana

- Conceptuales: Capacidad de entender y vislumbrar como un todo el problema incluyendo las herramientas para solucionar el mismo

- Diseño: La construcción de una solución de manera eficiente que lleve un proceso al éxito con el mínimo de esfuerzo y costo

Características de un gestor:

Resolución de problemas: La manera creativa de cómo resolver un problema incentivando tanto a los individuos a su cargo como entendiendo sus problemas para que sean más productivos.

Dotes de Gestión: Estos vienen con la experiencia y conocimiento de un tema, para poder tener grandes dotes de gestión se debe conocer a fondo un problema y tener un poco de experiencia.

Bibliografía :

Ros Guasch, Joan Anton (2006) Analisis de Roles de trabajo en equipo. Tesis Doctora. Universidad Autonoma de Barcelona, España.

La crisis del software

El término “crisis del software” se acuñó en 1968, en la primera conferencia organizada por la OTAN sobre desarrollo de software; y con él se etiquetaron a los problemas que surgían en el desarrollo de sistemas de software. En la misma conferencia se utilizó por primera vez el término "ingeniería del software" para describir el conjunto de conocimientos que existían en aquel estado inicial. Algunas referencias útiles para comprender cuáles eran los conocimientos estables para el desarrollo de software en 1968 son:
* En 1962 se publicó el primer algoritmo para búsquedas binarias.
* C.Böhm y G. Jacopini publicaron en 1966 el documento que creaba una fundación para la eliminación de "GoTo" y la creación de la programación estructurada
* En 1968 los programadores se debatían entre el uso de la sentencia GoTo, y la nueva idea de programación estructurada; ese era el caldo de cultivo en el que Edsger Dijkstra escribió su famosa carta "GoTo Statement Considered Harmful" en 1968.
* La primera publicación sobre programación estructurada no vio la luz hasta 1974, publicada por Larry Constantine, Glenford Myers y Wayne Stevens.
* El primer libro sobre métrica de software fue publicado en 1977 por Tom Gilb.
* El primer libro sobre análisis de requisitos apareció en 1979.

CAUSAS DE LA CRISIS DEL SOFTWARE

Durante finales de los años 50 y principios de los 60, la potencia computacional de las maquinas era bastante limitada. Es por esto que los programas que se desarrollaban eran “simples” desde nuestro punto de vista actual. Seguían un proceso de desarrollo bastante artesanal, sin una metodología o un camino a seguir para su desarrollo. En esta época se solían usar los lenguajes de bajo nivel para el desarrollo de Software.

Pero a finales de los 60, la potencia de las maquinas empezó a aumentar de forma considerable. Empezaron a aparecer los lenguajes de programación de alto nivel, y las maquinas necesitaban programas mucho más complejos de los desarrollados hasta la época. En definitiva, fue un salto tremendo en cuanto a potencial de hardware, que no fue acompañado por un salto en el desarrollo de software.

En esta época, se empezó a concebir el Software como producto, y se empezaron a desarrollar algunos proyectos para que funcionaran en las máquinas de la época. Pero aparecieron importantes problemas: los productos excedían la estimación de costes, había retrasos en las entregas, las prestaciones no eran las solicitadas, el mantenimiento se hacía extremadamente complicado y a veces imposible, las modificaciones tenían un coste prohibitivo…en resumen, se desarrollaba software de mala calidad, ya que la técnica utilizada para desarrollar pequeños programas para maquinas con mucho menos potencial se quedaba desfasada, y muchas veces este software acababa en el olvido. Como ejemplo, podemos ver este gráfico del año 1979, en el que se recoge la inversión en desarrollo de sistemas software en ese año ($6.8 Millones), y como se acabó ese software.

La crisis del software se refiere principalmente a las siguientes características del proceso de desarrollo:

- Incumplimiento sistemático de los plazos de entrega.
- Desajuste entre el presupuesto inicial estimado y el presupuesto final del proyecto.
- Baja calidad del producto final: Incumplimiento de especificaciones y dificultad de mantenimiento.

Que alguien me diga en qué porcentaje de los proyectos en los que ha participado como programador, analista, jefe de proyectos o gerente se ha cumplido algunas de las premisas anteriores. En bastantes, ¿verdad?.

Conclusiones

Las bases para eliminar la crisis del software en un proyecto de desarrollo de software son muy conocidas por todos, lo que pasa es que son tantos los ingredientes a utilizar (unos dependientes del grupo de desarrollo y otros no) para que un proyecto salga bien en plazos, presupuesto y calidad, que no resulta nada sencillo (aunque no es imposible) conseguirlo.

Por todo lo anterior, pese a que la solución tiene una base metodológica y de disciplina (de todas las partes que intervienen en el proyecto, teniendo mucho peso la parte usuaria), la base para arreglarla es cultural, es decir, la adquisición de buenos hábitos de base para el desarrollo de proyectos software (ya que sin esta cultura, la metodología se llenará de polvo en las estanterías y la disciplina un bien perecedero) y la erradicación de los mitos del software en todas sus vertientes.

Nadie tiene la llave para ser infalible en los proyectos de desarrollo de software, es decir, como se ha dicho antes, un proceso de desarrollo tiene muchos condicionantes y es muy complicado manejarlos todos, sobre todo cuando no dependen de uno. En cualquier caso, lo que hay que intentar siempre es tender a hacer las cosas de la mejor manera posible y a intentar cumplir los objetivos de plazos, presupuestarios y de calidad, porque si hay una cosa que debe clara a todos, es que si un proyecto no se enfoca hacia esos objetivos, es complicado, muy complicado, que se consigan por casualidad.

miércoles, 2 de julio de 2014

Patrón de estrategias, patron observador. Pruebas