Nombres en el código (Name)

Label = lbl
TextBox=txb
Button= btn
GroupBox= gbx

Informe

El día miercoles 11 de septiembre, debería estar terminado el informe sobre la metodología, Juvenal subirá al Mail el miercoles en la noche la parte de los Roles que es una de las últimas que va quedando faltante. (venga)

La idea sería el jueves en la mañana en el horario que tenemos fijado para reunión tener el informe en mano, y además tener conocimiento de los tópicos que el profe pidió para la clase ._.

Comentarios pa las modificaciones plx 8).

Metodologias RUP, XP Y FDD

RUP (Rational Unified Process), este es uno de los procesos más generales que existe, esta enfocado a cualquier tipo de proyecto así no sea de software, se basa en la documentación generada en cada uno de sus cuatro fases:
1. Intercepción (puesta en marchar),
2. Elaboración (definición, análisis y diseño),
3. Construcción (implementación) y
4. Transición (fin del proyecto y puesta en producción) en las cuales se ejecutarán varias iteraciones (según el tamaño del proyecto).
RUP se basa en UseCase (casos de uso) para describir lo que se tiene y lo que se espera del software, está muy orientado a la arquitectura del sistema a implementarse, documentándose de la mejor manera, basándose en UML (Unified Modeling Language - Lenguaje de Modelado Unificado).

XP (eXtrme Programing - Programación Extrema), se basa en el trabajo orientado directamente al objetivo, basándose para esto en las relaciones interpersonales y en la velocidad de reacción para la implementación y para los cambios que puedan surgir durante el desarrollo del proceso.
Esto se logra, minimizando el riesgo de fallo del proceso manteniendo dentro del equipo a un representante "competente" del cliente, este representante es quién responderá a todas las preguntas y dudas que surjan por parte del equipo de desarrollo durante el proceso, de forma que no se retrase la toma de decisiones.
XP se basa en UseStories (historias de uso), estas historias las escribe el cliente o su representante dentro del equipo y describen los escenarios claves del funcionamiento del software, a partir de estas se generan los releases (entregas) entre el equipo y el cliente. Estos releases (entregas) son los que permiten definir las iteraciones necesarias para cumplir con los objetivos, de manera que cada resultado de la iteración sea un programa aprobado por el cliente de quien depende la definición de las siguientes iteraciones.
Una característica saltante de XP, es que el código siempre se produce en parejas, parejas que van cambiando constantemente para lograr así que todo el equipo sepa y pueda modificar según necesidades el código generado, esto logra en el equipo que los integrantes aprendan entre sí y compartan todo el código.

FDD (Feature Driven Development - Desarrollo Manejado por Rasgos), este proceso se considera como punto medio entre los procesos pesados y ágiles, aunque en la práctica es más similar a este último, es una combinación de XP y RUP. Pensado para proyectos relativamente cortos, al igual que los anteriores también esta basado en iteraciones que producen un software funcional que puede ser visto, probado y monitorizado por el cliente.
Estas iteraciones son decididas en base a las funcionalidades que el software debe tener, funcionalidades definidas por el cliente, este proceso está dividido en cinco fases:
1. Develop an Overall Model - Desarrollo de un modelo global,
2. Build a Feature List - Construcción de una lista de funcionalidades,
3. Plan by Feature - Plan de releases (entregas) basadas en las funcionalidades a implementar,
4. Design by Feature - Diseñar en base a las funcionalidades definidas y
5. Build by Feature - Implementar en base a las mismas funcionalidades.
Aquí en el equipo de trabajo si existen jerarquías, siempre debe haber un jefe de proyecto, y aunque es un proceso considerado ligero también incluye documentación (la mínima necesaria para que algún nuevo integrante pueda entender el desarrollo de inmediato).

COMPARANDO LOS PROCESOS
Lo necesario es saber con que recursos contamos (tiempo, dinero, personal) pues depende mucho de estos recursos el poder saber elegir un proceso y claro está debemos tener muy en claro el alcance de nuestro proyecto y los resultados que deseamos obtener y en que tiempo.
TAMAÑO DE LOS EQUIPOS

RUP: Pensado para proyectos y equipos grandes, con roles designados y con una duración extendida.

XP: Pensado para proyectos cortos con equipos pequeños y rotables en cuanto a roles.

FDD: Pensado para proyectos y equipos medianos a pequeños, con la flexibilidad que a mayor necesidad de código, mayor organización.

OBTENCIÓN DE REQUISITOS

RUP: Se basa en los UseCase (casos de uso) donde se describen los requerimientos de la aplicación desde el punto de vista del usuario.

XP: Se Basa en los UseStories (historias de uso), que al igual que el anterior definen los detalles técnicos sin meterse con los detalles de implementación.

FDD: Define como se va a proceder después de recoger los requisitos definidos por el usuario.

CARGA DE TRABAJO

RUP: Proceso pesado por estar basado mucho en la documentación, documentación que se ve afectada con los posibles cambios volátiles que a los clientes se les ocurre en cuanto a funcionalidades del software, la justificación de esto es que gracias a su plan de desarrollo con el que se controla el desarrollo se pueden reconocer los problemas y fallos de forma temprana y corregirlos.

XP: Proceso ligero porque no se les asignan roles organizativos al equipo, roles como el modelado o generación de la documentación, esto es reemplazado por la presencia de un representante especializado del cliente, haciendo así más flexibles los posibles cambios que se presenten durante el desarrollo del software.

FDD: Aunque también genera documentación es la mínima necesaria para comprender el código, si bien es cierto el quipo cuenta con cierta libertad también es cierto que estos dependen directamente del jefe de proyecto quien es el responsable directo de proyecto.

RELACION CON EL CLIENTE

RUP: Al final de cada fase, se le presenta al cliente los artefactos finales de dicha fase, para que sean evaluados por este y se puedan generar las iteraciones necesarias para la siguiente fase.

XP: La comunicación con el cliente es fluida (a través de su representante) después de cada iteración el cliente recibe un pedazo de programa funcional, así el cliente está informado permanentemente y puede intervenir rápidamente si el desarrollo se aleja de sus necesidades.

FDD: A diferencia del XP, aquí además de lo antes mencionado, existe el modelo general desarrollado en primera fase, la que provee un marco general dentro de cual evolucionará el proyecto (mientras no sea necesario cambiarlo claro)

DESARROLLO

Aquí los tres procesos están basados en iteraciones, lo que les permite acercarse poco a poco a la solución sin tener que entrar demasiado rápido a los detalles, la diferencia está en que los programadores de XP tienen menor carga a parte del desarrollo del software entonces les permite hacer las iteraciones con una menor duración.

PUNTOS FLACOS
Es lógico pensar que si existen varios procesos de desarrollo de software es sencillamente que cada uno presenta deficiencias o carencias según el punto de vista del equipo de desarrollo o las necesidades que el cliente presente.

RUP: Dado que este es un proceso general y cubre todas las posibles expectativas tanto del cliente como del equipo de desarrollo, es precisamente esa característica su mayor punto flaco, pues es muy grande para proyectos y equipos pequeños ya que deben repartirse 32 roles y generar muchos artefactos finales, los cuales pueden ser aprovechados en una reutilización de productos, modelos o procesos pero también significa un incremento de tiempos y costos.

XP: Este proceso está muy orientado a la implementación, esto lo hace bueno para el equipo de desarrollo ya que no debe preocuparse de la documentación y ya que los equipos rotan todos aprenden de todos, por otro lado el cliente también se siente satisfecho pues recibe un software que se adapta exactamente a sus deseos, pero esto implica que para esto debió designar a una persona totalmente involucrada en el negocio, lo que podría implicar que esta persona deje de hacer sus funciones para estar totalmente disponible al equipo de desarrollo, razón por la cual se considera mejor la utilización de este proceso para desarrollos internos, pues debe haber una gran confianza entre el cliente y el equipo de desarrollo.

FDD: El principal problema de este proceso esta representado por la necesidad de contar con miembros experimentados en el equipo, miembros que puedan definir los roles y funciones de cada uno, que marquen el camino a seguir desde el principio con la elaboración del modelo global, el hecho de ser una combinación de XP y RUP es lo que lo hace más atractivo a la implementación, claro siempre y cuando la experiencia de esa gente de mayor jerarquía no cree dependencias.

Primer Ejemplo en C#

Trabajando con Visual Studio 2005
En la primera linea se define una clase (class) de nombre HolaMundo cuya definición estará comprendida entre la llave de apertura y su correspondiente llave de cierre.
Dentro de la definición de la clase se define un método de nombre Main cuyo código es el indicado entre la llave de apertura y su respectiva llave de cierre. Un método no es más que un conjunto de instrucciones a las que se les asocia un nombre, de modo que para posteriormente ejecutarlas baste referenciarlas por su nombre en vez de tener que reescribirlas. Lo que antecede al nombre del método indica cuál es el tipo de valor que se devuelve tras la ejecución del método, y en este caso es void que significa que no se devuelve nada. Por su parte, los paréntesis que se colocan tras el nombre del método indican cuáles son los parámetros que éste toma, y como en este caso están vacíos ello significa que el método no toma parámetros. Los parámetros de un método permiten variar el resultado de su ejecución según los valores que se les dé en cada llamada. La palabra static que antecede a la declaración del tipo de valor devuelto es un modificador del significado de la declaración de método que indica que el método está asociado a la clase dentro de la que se define y no a los objetos que se creen a partir de ella.
Main() es lo que se denomina el punto de entrada de la aplicación, que no es más que el método por el que comenzará su ejecución. Necesita del modificador static para evitar que para llamarlo haya que crear algún objeto de la clase donde se haya definido.
Finalmente, la línea 3: contiene la instrucción con el código a ejecutar, que lo que se hace es solicitar la ejecución del método WriteLine() de la clase Console definida en el espacio de nombres System pasándole como parámetro la cadena de texto con el contenido ¡Hola Mundo!. Nótese que las cadenas de textos son secuencias de caracteres delimitadas por comillas dobles aunque dichas comillas no forman parte de la cadena.
Para compilar y ejecutar CTRL+F5.
A programar se ha dicho.