Está en la página 1de 25

EJERCICIOS SOBRE ENFOQUES DEL SOFTWARE

Presentado por: JULIAN RICARDO BENAVIDES FREDDY ALEXANDER FUENTES FABIO ANDRES BOLAÑOS

UNIVERSIDAD DE NARIÑO FACULTAD DE INGENIERIA PASTO 22 DE septiembre de 2011

1. LO

QUE UN DESARROLLADOR PREGUNTAR AL USUARIO:

DE

SOFTWARE

LE

DEBE

Para un desarrollo adecuado de cualquier software, un desarrollador debe analizar y comprender muy bien al usuario final de su creación, por ello consideramos que las preguntas más adecuadas serian las siguientes: a. ¿Los requisitos son estables? Es de suma importancia que el diseñador tenga claro si el usuario aspira a que su software se conserve estable en el tiempo o si por el contrario desea que este sea compatible con cambios y adaptaciones futuras. b. ¿Sería mejor tener un diseño rígido según lo establecido y después de finalizado llevar un proceso de reingeniería? esta pregunta con el fin de determinar si el cliente desea que su software se guie por sus instrucciones especificas o si por el contrario desea un software versátil. c. ¿Qué infraestructura posee el cliente? ¿Es la más adecuada para el tipo de sistema que se pretende llevar a cabo? ¿Qué le haría falta? ¿Habrá que renovar y/o ampliar las instalaciones tecnológicas? Es de suma importancia conocer la infraestructura que posee nuestro cliente, para diseñar un software compatible con la clase de tecnología que posee, por ejemplo si es un software diseñado para un sistema operativo especifico, conocer las limitantes del hardware que tenga el cliente, si utiliza equipos de tecnología de punta o si por el contrario el software deberá adaptarse a equipos con tecnología limitada. d. ¿El cliente y/o usuario y el resto del personal, tiene bastante cultura informática? ¿Saben lo suficiente como para entender el manejo del sistema? Previsión, debemos saber que existen muchos tipos de usuarios finales para un software, por lo tanto nuestro diseño deberá ser directamente proporcional al nivel de conocimiento del usuario en esta área, si el usuario es principiante, el desarrollador deberá entregar un producto con interfaz simple y practica para facilitar las condiciones de trabajo del usuario.
2. LO QUE EL USUARIO DEBE PREGUNTAR AL DESARROLLADOR DE SOFTWARE:

a. ¿mi infraestructura tecnológica es compatible con el software que me van a suministrar? Muchas veces el software ya se encuentra previamente diseñado, y es de suma importancia conocer con que tipo de tecnología son compatibles y con cuales no, por esto el usuario debe dar a conocer la capacidad tecnológica que posee en su infraestructura.

b. ¿a que clase de usuario va dirigido mi diseño? Es de suma importancia conocer las características del usuario. para que el diseñador logre colmar todas sus peticiones. que tanto dominio posee en temas informáticos y tecnológicos. c. El usuario debe preguntarse a si mismo la capacidad económica que posee para realizar una petición al desarrollador. ¿Qué es exactamente lo que necesitamos que nuestro software sea capaz de ejecutar? El usuario debe tener muy claro que tareas desea que el software ejecute. saber si es un usuario avanzado o por el contrario es un usuario con muchas limitantes. si no también ser compatible con la infraestructura que el usuario posea. por que entre mas complejo es un software. 4. LO QUE LOS USUARIOS DEBEN PREGUNTARSE A SI MISMOS SOBRE EL SOFTWARE A DESARROLLAR. b. . ¿Qué nivel de conocimiento informático debo manejar para dominar el software? Debemos preguntar al desarrollador que tan difícil será dominar el nuevo software. a. mas costoso se vuelve. 3. ¿es mi diseño compatible con la infraestructura del usuario? Un aspecto importante. y aclarar al desarrollador nuestras perspectivas a futuro para hacer que el software soporte cambios en su diseño. a. ¿es el software capaz de resistir posibles cambios futuros? como usuarios debemos estar seguros si queremos que nuestro software tenga versatilidad. Costos. LO QUE EL DESARROLLADOR DEBE PREGUNTARSE A SI MISMO SOBRE EL SOFTWARE A DESARROLLAR.b. y preguntar si debemos capacitarnos en alguna rama para que el empleo de este se nos facilite. el diseño debe no solo ser encaminado a cumplir cierto tipo de tareas.

además de que los intereses son comunes entre clases y también son únicos. Estos proporcionan una metodología y un marco de trabajo para documentar las capacidades de negocio y puede dar soporte a las actividades de integración y consolidación. estos puntos se pueden tomar como intereses comunes a varias entidades o procedimientos dentro de un programa. de manera que no deban hacerlo estos mismos. por ejemplo liberar la memoria que ya no se utiliza más por los diferentes componentes del programa. a su vez brinda una forma estándar de exposición e invocación de servicios (comúnmente pero no exclusivamente servicios web). Para que un proyecto de este tipo tenga éxito. lo cual facilita la interacción entre diferentes sistemas propios o de terceros. METODO DE SERVICIOS. METODO DE ASPECTOS. El desarrollo de sistemas usando SOA requiere un compromiso con este modelo en términos de planificación. Este paradigma aborda el problema de separación de intereses. La arquitectura orientada a servicios es tanto un marco de trabajo para el desarrollo de software como un marco de trabajo de implementación. la solución a este problema sería crear un aspecto. que en términos generales es un objeto que se dedica a una y solo una función o tarea dentro del programa. .5. DESARROLLO DE SOFTWARE ORIENTADO A La Arquitectura Orientada a Servicios es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos del negocio. DESARROLLO DE SOFTWARE ORIENTADO A Durante el desarrollo de una aplicación se encuentran muchos fragmentos de códigos o funciones que se repiten en distintas clases. Si para cada clase manipula por si misma estas funciones se tiene redundancia en aplicaciones. 6. herramientas e infraestructura. los desarrolladores de software deben orientarse ellos mismos a esta mentalidad de crear servicios comunes que son orquestados por clientes o middleware para implementar los procesos de negocio. Permite la creación de sistemas altamente escalables que reflejan el negocio de la organización.

que resuelve múltiples necesidades. Por el contrario un modelo de proceso de software es una representación abstracta de un proceso. como indica la palabra. Diseño. DIFERENCIA ENTRE PERSONALIZADO. ingenieros de software y desarrolladores. es un software que no se adapta completamente al vocabulario. En general. Entre las más conocidas tenemos:  ERwin: herramienta de diseño de bases de datos que genera productividad y permite generación y mantenimiento de aplicaciones. 9. 8. de la empresa y de su forma de trabajar. Un proceso de software es un conjunto estructurado de actividades para:  Especificar  Diseñar  Implementar y probar sistemas de software. Es decir. a la medida del usuario. describiendo a este desde una perspectiva particular. DIFERENCIA ENTRE UN MODELO DE PROCESO DE SOFTWARE Y UN PROCESO DE SOFTWARE. durante todos los pasos del Ciclo de Vida de desarrollo de un Software (Investigación Preliminar. SOFTWARE GENERICO Y SOFTWARE El software personalizado. busca complacer todas las necesidades y adaptarse lo mejor posible a los requerimientos. El software estándar.). Implementación e Instalación. y la empresa probablemente sólo empleará algunas. necesidades y funciones que necesita la empresa. Análisis. es aquel que se diseña.7. . es un software genérico. Un modelo ayuda mucho a mejorar un proceso debido a que en el modelo podemos simular o conceptualizar como se comportara exactamente el proceso que estamos diseñando. MENCIONE CINCO METODOS DE TIPOS PROPORCIONEN LAS HERRAMIENTAS CASE. DE AYUDA QUE Se puede definir a las Herramientas CASE como un conjunto de programas y ayudas que dan asistencia a los analistas.

En la elaboración de los diagramas.es un producto para la generación de esquemas de base de datos e ingeniería reversa trabaja para proveer una solución comprensible para el diseño. 11. Oracle Designer: Oracle Designer es un conjunto de herramientas para guardar las definiciones que necesita el usuario y automatizar la construcción rápida de aplicaciones cliente/servidor gráficas. ¿ES POSIBLE COMBINAR MODELOS DE PROCESOS? Para proyectos largos es mejor combinar lo mejor del modelo de cascada y evolutivo: se puede hacer un prototipo global del sistema y posteriormente reimplementarlo con un acercamiento más estructurado. los elementos asociados. consistencia y documentación del sistema en conjunto. ¿ES LO MISMO EL PROCESO UNIFICADO AL UML? No. 12. el System Architect conecta directamente al diccionario de datos. EasyCASE: el centro de productos para procesos. este es el encargado de mostrar resultados visibles. Por el contrario UML es el lenguaje utilizado por el proceso unificado para preparar todos los esquemas de un sistema software. Los subsistemas con requisitos bien definidos y estables se pueden programar utilizando cascada y la interfaz de usuario se puede especificar utilizando un enfoque exploratorio. lo cual quiere decir que el sistema software en construcción esta formado por componentes software interconectados a través de interfaces bien definidas. mientras que un flujo de trabajo es la sucesión de fases para llevar a cabo una tarea dentro del proceso unificado. 10. etc. y metodologías usadas. System Architect: Esta herramienta posee un repositorio único que integra todas las herramientas. normalización. comentarios. e Ingeniería de Base de Datos. . esto debido a que el proceso unificado esta basado en componentes. reglas de validaciones. modelamiento de   datos y eventos. ¿CUAL ES LA DIFERENCIA ENTRE UNA FASE Y UN FLUJO DE TRABAJO EN EL PROCESO UNIFICADO DE SOFTWARE? Una fase hace referencia a un único paso específico en el proceso unificado de software.

¿CUALES SON LAS VENTAJAS DE PROPORCIONAR VISTAS ESTATICAS Y DINAMICAS DEL PROCESO UNIFICADO? Una vista estatica muestra con mucho detenimiento y meticulosidad como se va desarrollando el proceso unificado en cada una de sus fases. El software desarrollado en una unidad de tiempo es llamado una iteración.  Al software en funcionamiento sobre la documentación extensa. las vistas dinamicas muestran el resultado final del proceso. análisis de requerimientos. Cada iteración del ciclo de vida incluye: planificación. la mayoría minimiza riesgos desarrollando software en cortos lapsos de tiempo.. Gracias a este manifiesto dichos actores postulan que valoran más lo siguiente:  A los individuos y sus interacciones sobre los procesos y las herramientas. la cual debe durar de una a cuatro semanas. La alianza ágil definió 12 principios para quienes quieren alcanzar la agilidad: 1. Kent Beck y otros 16 desarrolladores destacados firmaron el manifiesto para el desarrollo ágil. revisión y documentación.13. Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado. En esencia este movimiento ágil nace como un intento por superar las debilidades advertidas y reales en la ingeniería de software convencional. LA AGILIDAD EN LA INGENIERIA DE SOFTWARE Y LOS DOCE PRINCIPIOS DE ALIANZA AGIL El desarrollo ágil de software es un marco de trabajo conceptual de la ingeniería de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. lo cual permitirá ver si el software trabaja tal y como se tenia previsto o si por el contrario se están presentando fallos en alguna de sus fases.  A la respuesta al cambio sobre el seguimiento de un plan. pero la meta es tener un demo (sin errores) al final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto.  A la colaboración del cliente sobre la negociación del contrato. diseño. .Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continúa de software valioso. codificación. Existen muchos métodos de desarrollo ágil. En el año 2001.

12. el diseño y la construcción están intercalados...El software en funcionamiento es la medida primaría de progreso. 8. 7.La simplicidad – el arte de maximizar la cantidad de trabajo no realizado – es esencial. 6.. es difícil presagiar cómo cambiarán las prioridades del cliente mientras se ejecuta un proyecto. que ambos se deben realizar de forma conjunta.Benvenidos los requisitos cambiantes. Darles el ambiente y el soporte que necesitan. 11. incluso en fases tardías del desarrollo. los mejores requisitos.  El análisis. De igual forma. el diseño y la construcción no son predecibles (desde el punto de vista de la planeación) lo que sería deseable. Los patrocinadores..  Para muchos tipos de software. desde un par de semanas hasta un par de meses..Entregar con frecuencia software en funcionamiento. de modo que los modelos de diseño se prueben conforme como se crean. 4. Esto quiere decir..A intervalos regulares el equipo refleja la forma en que se puede volver más efectivo.2.Los procesos ágiles promueven el desarrollo sustentable. EL PROCESO AGIL DE DESARROLLO DE SOFTWARE Martin Fowler señala que los procesos ágiles de software se caracterizan de una manera que refieren tres suposiciones claves:  Resulta difícil predecir cuales requisitos de software persistirán o cambiaran. entonces su comportamiento se ajusta y adecua en concordancia..El método más eficiente y efectivo de transmitir información hacia y dentro de un equipo de desarrollo es la conversación cara a cara. y los mejores diseños emergen de equipos auto organizados. 10..La atención continua a la excelencia técnica y al buen diseño mejora la agilidad. 3...Las mejores arquitecturas. desarrolladores y usuarios deben ser capaces de mantener un paso constante de manera indefinida. 9. 5. con preferencia en las escalas de tiempo más cortas. y confiar en ellos para obtener el trabajo realizado.La gente de negocio y los desarrolladores deben trabajar juntos a diario a lo largo del proyecto..Construir proyectos alrededor de individuos motivados. .

etc. Sin que exista colaboración esto es imposible. habilidades específicas relacionadas con el software y un conocimiento general del proceso que el equipo a decidido aplicar. Colaboración: La ingeniería de software incluye evaluar. Confianza y Respeto mutuo: el equipo “debe unirse con tanta fuerza. y no al revés. Enfoque Común: Todos los miembros del equipo deben enfocarse en una meta: entregar al cliente un incremento de trabajo de software dentro del tiempo establecido. Capacidad de resolución de problemas confusos: Los gestores deben reconocer que el equipo de desarrollo enfrentará ambigüedades y sufrirá golpes de manera continua gracias a los cambios. Pero la adaptabilidad sin progreso logra muy poco. Un problema que este resolviendo hoy no será el mismo que estaré resolviendo mañana. crear información que ayudara al equipo de desarrollo y al cliente a entender el trabajo. Por lo que es importante que un proceso ágil realice una adaptación incremental. Lo importante es que el proceso se ajusta a las necesidades de las personas y del equipo. Cockburn y Highmith señalan: “El desarrollo ágil se centra en los talentos y las habilidades de los individuos. Autonomía y Autoridad. que el todo sea mayor que la suma de las partes. ¿Cómo se maneja esto en un proceso? La respuesta es generar procesos ágiles adaptables. Estos incrementos deben entregarse en cortos periodos para que la adaptación mantenga un buen ritmo con el cambio.El gran punto según lo mencionado anteriormente tiene que ver con lo impredecible. Habilidad para la toma de decisiones: todo equipo de software debe tener la habilidad de controlar su propio destino. analizar y usar información que se comunica al equipo de software. Rasgos que deben poseer las personas que participen de un desarrollo ágil y el equipo mismo: Competencia: abarca un talento innato. y la pregunta que nace es. puesto que el proceso se ajusta a personas y equipos específicos”. . FACTORES HUMANOS Los factores humanos son uno de los puntos importantes para llevar acabo algún proceso de desarrollo ágil.

 El ciclo de desarrollo de PE se divide en liberaciones. La PE utiliza como enfoque preferido la orientación a objetos.MODELOS AGILES PROGRAMACION EXTREMA (PE) Los primeros trabajos sobre las ideas y los métodos asociados a Programación Extrema se realizaron en la década de los 80. Son importante destacar los siguientes aspectos de está metodología: Valores  Comunicación  Retroalimentación  Simplicidad  Coraje Principios  Retroalimentación Rápida  Cambio Incremental  Trabajo de Calidad  Simplicidad. el trabajo fundamental fue publicado en el año 1999 por Kent Beck. cada una de las cuales es medida en historias de usuarios .  Características particularidades del proceso:  Fase inicial de captura de requerimientos es eliminada.

Planeación Comienza creando una serie de historias que describen las características y la funcionalidad requeridas para el software que se construirá. Diseño. debe ser entendible tanto para el cliente como para los desarrolladores.       Diseño  Esta actividad sigue de manera rigurosa el principio de mantener las cosas simples. el equipo PE ordena las historias que se desarrollaran de una de las siguientes tres maneras: 1. Las historias con valor mas alto se moverán en el programa y se implementaran al principio. Estas tarjetas son el único producto del diseño. Se prefiere simplicidad a complejidad. Una vez establecido el compromiso básico. 2. Los miembros del equipo PE evalúan las historias y le asignan un costo. Codificación y Prueba. Cada historia las escribe el cliente y se coloca en una carta índice. el cuál se mide en semanas de desarrollo. Historia de Usuarios: unidad funcional en un proyecto PE. El cliente le asigna un valor a la historia basándose en los valores generales del negocio. Los clientes y el equipo PE trabajan juntos para decidir cómo agrupar las historias hacia el próximo lanzamiento. ni más ni menos.  El diseñó es una guía de implementación para una historia como esta escrita. verificable y pequeña. Después de que se realiza el primer lanzamiento el equipo de PE calcula la velocidad del proyecto (La velocidad del proyecto es el número de historias implementadas en un lanzamiento).  La PE apoya el uso de las tarjetas CRC como un mecanismo efectivo para pensar en el software en un contexto orientado a objetos. La PE logra todas las cosas mencionadas anteriormente en el contexto de cuatro actividades claves: Planeación. . Todas las historias serán implementadas de un modo inmediato (dentro de pocas semanas). Si la historia requiere mas de tres semanas se solicita una reformulación. 3. Se debe generar un compromiso básico de las historias que se desarrollaran en un incremento. Las historias más riesgosas se moverán dentro del programa y se implementarán al principio.

 También existe una integración continua. sino que debe desarrollar una serie de pruebas de unidad.  Se recomienda que las pruebas de integración y de sistemas se vayan realizando a medida que se realizan un conjunto pequeño de pruebas de unidades. Este modelo de clases Responsabilidad-Colaborador (CRC) proporciona un medio simple para identificar y organizar las clases relevantes para los requisitos del sistema o producto. una técnica de construcción que también es de diseño. Esto ya que el diseño se considera una fase que puede y debe modificarse de manera continua a medida que prosigue la construcción. Se realizan en base a las historias de usuario. Codificación  La PE recomienda que después de diseñar las historias y realizar el trabajo de diseño preliminar el equipo no debe moverse hacia la codificación. las especifica el cliente. Esto apoya una estrategia de regresión de prueba.”  Las pruebas de aceptación o cliente.  Una vez desarrollada las pruebas el desarrollador puede centrarse en implementar lo necesario para cumplirlas. ya que cada vez que se termina de codificar una historia se debe integrar esta parte con las realizadas por los demás. PE recomienda que dos personas trabajen juntas en una estación de trabajo creando una historia (se sigue el concepto dos cabezas piensan mejor que una).  Uno de los aspectos importantes de la codificación es la PROGRAMACION EN PAREJAS. . Pruebas  Las pruebas de unidad que se crean deben implementarse con un marco de trabajo que permita automatizarlas.  Si el diseño de una historia se encuentra difícil.  La PE apoya la re fabricación (refactoring). Esto se refrenda con la siguiente frase: “Arreglar problemas pequeños cada pocas horas toma menos tiempo que arreglar problemas enormes justo antes de la fecha limite. la PE recomienda la creación inmediata de un prototipo operacional de esa porción del diseño.

 El resultado final será un producto más cercano a las necesidades del usuario en el final del desarrollo. y se han realizado algunos cambios. minimizar los gastos generales y maximizar el hecho de compartir conocimientos tácitos e informales”. probar. SCRUM tiene también estructura y mecanismos de control. documentar y construir”. La jugada de rugby a la cuál hace mención el nombre SCRUM se refiere al proceso de volver a poner la pelota en juego. Estos principios son consistentes con lo que señala el manifiesto ágil:  Los equipos de trabajo pequeños están organizados para “maximizar la comunicación.  El proceso de adaptarse a los cambios técnicos y de negocios “para asegurar que se produzca el mejor producto posible”. en vez de métodos definitivos que intentan predecir el progreso y detener el cambio. ajustar. esto lo realiza un conjunto de jugadores. . específicamente en el año 2001 por Schwaber y Beedle. Este proceso de desarrollo fue presentado a la OMG en el año 1995.  El proceso produce incrementos frecuentes de software “los cuales se pueden inspeccionar. SCRUM espera el cambio.  En ambientes impredecibles. Aplicado al desarrollo de software. se debe usar métodos empíricos para monitorear el progreso y el cambio.MODELOS AGILES MELE El nombre SCRUM (MELE en español) se deriva de una jugada de rugby. Este es un modelo ágil de proceso que desarrollaron Jeff Sutherland y su equipo a principios de la década de los 90. SCRUM asume que los base lines cambiarán significativamente durante el proyecto. la definición se refiere a la técnica de organización y gestión usada para llevar acabo exitosamente proyectos de desarrollo de software en un ambiente caótico.

En cualquier minuto se pueden agregar requerimientos a las características. Bajo estos principios se guían las actividades dentro un proceso que incorpora las siguientes actividades del marco de trabajo: requisitos. Durante el sprint no se pueden introducir cambios a las características. . evolución y entrega.  Los procesos de scrum proporcionan la “capacidad de declarar un producto como „realizado‟ siempre que esto se requiere”. Sprint: consiste en unidades de trabajo que se requieren para satisfacer un requisito definido en las características en un periodo definido (lapso usual 30 días). diseño. Features (Características): son una lista que considera la prioridad de los requisitos o características de proyecto que proporcionan un valor comercial para el cliente. análisis. El trabajo de desarrollo y la gente que lo realiza están divididos en “particiones o paquetes de bajo acoplamiento”.  Conforme se construye el producto se realizan pruebas y documentación constante.

sino de gestión de proyectos de desarrollo. MODELOS AGILES DESARROLLO ADAPTATIVO DE SOFWARE (DAS) El desarrollo adaptativo de software (DAS) lo propuso Jim Highsmith 1998 como una técnica para construir software y sistemas complejos. Como SCRUM no es realmente una metodología de desarrollo de software. Por tanto. Los apoyos filosóficos del DAS se enfocan en la colaboración humana y la organización propia del equipo.Reuniones de Scrum: son reuniones cortas (por lo general de 15 minutos) y las realiza a diario el equipo de scrum. la mayoría de los métodos de desarrollo de software pueden ser gestionados usando SCRUM sin mayores conflictos. no determina prácticas de desarrollo de software. Highsmith 1998 expone lo anterior cuando escribe: .

Se estudia la adecuación de DSDM al proyecto y se identifican los riesgos del mismo. los compromisos de las distintas partes y quién o quienes financiarán el proyecto. El estudio de la organización propia demuestra que dicha visión es errónea. La organización propia emerge cuando los individuos. es en el momento de energía creativa cuando surge la solución a algún problema persistente.La organización propia es una propiedad de los sistemas adaptativos complejos. El desarrollo adaptativo del software (DAS) fue propuestos por Jim Highsmith como una metodología para desarrollar el software y sistemas muy complejos. El se centra en la colaboración humana y la organización. colaboración y aprendizaje. Está compuesto por cinco fases: . Tendemos a ver este fenómeno del surgimiento colectivo como un accidente. La metodología está compuesta por tres fases que se realizan de forma secuencial: . Una salida emergente es una propiedad más allá de la capacidad de cualquier agente individual. Por ejemplo. es el turno de repasar su ciclo de vida. similar a un "aja" colectivo. Ciclo de vida del proyecto. desarrolladores en un equipo de software) cooperan [colaboran] para crear salidas emergentes. El ciclo de vida del DAS se conforma de tres fases como muestra en la figura: Especulación. pero en forma colectiva generan la propiedad de la conciencia. un prototipo de viabilidad (el prototipo tiene sentido si se quieren evaluar algunos aspectos técnicos o funcionales y se puede utilizar para obtener . MODELOS AGILES METODO DE DESARROLLO DE SISTEMAS DINAMICOS (MDSD) Una vez analizados los principios y asunciones que sirven de base a la metodología. o al menos como independiente y sin reglas. las neuronas individuales del cerebro no poseen conciencia. En esta fase se realiza un informe de viabilidad.Pre proyecto: Se define el alcance global. los agentes independientes (células en un cuerpo.Estudio de la viabilidad (Feasability study). especies en un ecosistema. quiénes son los departamentos y personas implicadas.

Definición del calendario (se acuerda el plan de trabajo para la construcción de este prototipo). . Obtención del prototipo funcional y Revisión del prototipo funcional (se determina el grado de aceptación del prototipo desarrollado. La participación e implicación del usuario resulta fundamental en esta fase. En esta fase se obtiene un modelo de procesos identificando los usuarios clave en cada uno de ellos. si falta o se detecta algún nuevo aspecto técnico se vuelve a la fase de Iteración del diseño y la construcción. Revisión del prototipo de diseño. en función de lo que se decida en esta fase se irá a la fase de Postproyecto o a una de las fases anteriores del ciclo de vida). Si DSDM se ha considerado adecuado para el proyecto. un catálogo de requisitos priorizado (algo lógico para una metodología iterativa e incremental).Implementación (Implementation). habría que replantear la realización del proyecto siguiendo DSDM o con cualquier otra metodología. la arquitectura del sistema y el plan de prototipado. Se divide en 4 fases: Aprobación del usuario (el usuario realiza la aprobación del producto a entregar). Formación (se forma a los usuarios finales de la aplicación). tratándose por tanto de un producto finalista en el sentido de que ya podría ser usado para realizar el trabajo cotidiano sobre las funcionalidades implementadas). .información adicional del proyecto) y plan general del proyecto (plan de desarrollo + registro de riesgos). Definición del calendario (se acuerda el plan de trabajo para la realización de este modelado funcional). . Se divide en 4 fases: Identificación del prototipo funcional (se definen las funcionalidades que cubrirá el prototipo y se elabora un modelo funcional del mismo). si no es relevante se vuelve a la fase de Iteración del modelo funcional. Revisión de negocio (se revisa la adecuación del sistema a las necesidades del negocio y a los objetivos iniciales que se habían establecido para el mismo. el siguiente paso consiste en realizar un análisis más en profundidad del proceso o procesos de negocio que se van a informatizar.Iteración del diseño y de la construcción (Design and Build Iteration). Si falta o se detecta algún nuevo aspecto funcional relevante se vuelve a la fase de Estudio del Negocio. . es muy importante la obtención del feedback del usuario para que las especificaciones del producto a obtener con esta iteración se acerquen lo máximo posible a las necesidades del usuario). . Se divide en 4 fases: Identificación del prototipo de diseño (se determinan los requisitos funcionales y no funcionalidades que cubrirá el prototipo). si en la misma no se consigue. mediante pruebas realizadas por el usuario y/o la revisión de documentación. Construcción del prototipo de diseño (será un producto utilizable para los usuarios.Estudio del negocio (Business study).Iteración del modelo funcional (Functional Model Iteration). Implementación (se instala el producto en las instalaciones del cliente).

esto permite reducir el tiempo necesario para que los usuarios tengan en producción las distintas evoluciones del producto.Post proyecto: Tiene como objetivo la continuidad del sistema en el sentido de que siga siendo útil a las necesidades de los usuarios. Es importante señalar que DSDM permite trabajar con varios prototipos simultáneamente siempre y cuando “no se molesten” entre sí. ya que enfatiza cuestiones de calidad y define claramente entregas tangibles y formas de evaluación del progreso. El DCC concede una mayor importancia a las directrices y técnicas de la gestión del proyecto que muchos otros métodos ágiles. . MODELOS AGILES DESARROLLO CONDUCIDO POR CARACTERÍSTICAS (DCC) Es un modelo de proceso práctico para la ingeniería del software orientada a objetivos. Para la metodología una característica es una función valida por el cliente y que pude ser implementada en menos de dos semanas. Es aplicado en proyectos de software de tamaño moderado y grande. comprendería por tanto el mantenimiento del sistema que se realizaría (si se estima conveniente siguiendo el ciclo de vida DSDM).

AM es una manera efectiva de trabajar en conjunto para alcanzar las necesidades de las partes interesadas en el proyecto. y se trata sobre ser efectivo. A un nivel más detallado AM es una colección de valores. AM es algo que funciona en la práctica. más no es un sustituto de la gente competente. AM no es una bala de plata. AM es un complemento a los métodos existentes. no un proceso prescriptivo. principios. mostrado en el siguiente diagrama. y prácticas para modelar software que puede ser aplicado a un proyecto de desarrollo de software de una manera eficaz y ligera. AM es una recopilación de las mejores prácticas.   AM es una actitud.        . AM no es un ataque a las herramientas CASE. AM es para el desarrollador promedio. AM no es un ataque a la documentación.MODELO AGIL (MA) Es una metodología basada en la práctica para una documentación y modelado efectivo de sistemas software. de hecho AM aconseja la creación de documentos que tengan valor. no es una metodología completa. AM es efectivo. no es una teoría académica.

. así como entre los desarrolladores y analistas. Explorar la aplicación de técnicas de modelado en proyectos de software a través de un enfoque ágil.  Simplicidad: Es importante que los desarrolladores entiendan que los modelos son fundamentales para la simplificación del software y así puedan tener la capacidad de elaborar un diagrama o dos en vez de escribir decenas o incluso cientos de líneas de código.   Valores de AM:  Comunicación: Es un valor muy importante ya que promueve una comunicación entre el equipo de trabajo y sus participantes en el proyecto.  Humildad: Los mejores desarrolladores deben tener la humildad de reconocer que ellos no lo saben todo. principios y prácticas que conlleven a un modelado ligero efectivo. Explorar el como mejorar el modelado bajo procesos prescriptivos.AM tiene tres objetivos:  Definir y mostrar como poner en práctica una colección de valores.  Coraje: El coraje es importante porque hay que tomar decisiones importantes y ser capaces de cambiar de dirección cuando el camino tomado para el desarrollo no es el correcto. que tanto sus compañeros desarrolladores. DSDM o SCRUM. los clientes y de hecho todos los interesados en el proyecto tienen algo que añadir para la mejor realización. tal como XP.

. y la razón es muy simple: hay un porcentaje de incertidumbre en los requisitos del cliente. y con un proceso en Cascada no tienes opción de maniobra cuando detectas estos problemas (que se detectan casi siempre. Con un proceso Iterativo. y que en diferentes iteraciones nos aproximaremos más a la solución adecuada. en los diseños. 3. La documentación y un modelado efectivo son indispensables para cualquier desarrollador.. 4. Describa agilidad (para proyectos de software) con sus propias palabras. Idear un factor clave que ayude a un equipo de trabajo de ingeniería de software a volverse aun mas manejable. en los análisis. asumimos que hay incertidumbre. el diseño del software será sin duda alguna un diseño exitoso. Seleccione un principio de agilidad de los doce principios y trate de determinar si cada uno de los modelos consultados trabaja ese principio. si todos los integrantes del equipo muestran un índice de eficiencia alto. para ello la mejor manera de lograr estas premisas es manteniendo un orden lógico y pasos consecutivos en el diseño del software. ¿Por qué un proceso iterativo facilita más manejar el cambio? Lo primero que deberíamos hacer es preguntarnos por qué es necesario el cambio. ya que la incertidumbre se reduce. 2. y el cambio constante sobre las Historias de Usuario. El grupo decidió escoger el siguiente principio para su análisis: . Creemos que un factor vital en un grupo de trabajo es la eficiencia. y no necesariamente en la fase de pruebas o despliegue). La agilidad para proyectos de software hace referencia a que el diseño de estos debe ser encaminado a satisfacer las necesidades del usuario y ser compatible con su hardware. ¿Todos los procesos agiles son iterativos? Creemos que todos los procesos ágiles se basan en modelos iterativos: en la base de estos procesos están las entregas rápidas.CUESTIONARIO 1.

. Explicar los siguientes conceptos:  Re fabricación: es una técnica de construcción que también es de diseño. por ejemplo: La persona que está haciendo la codificación se le da el nombre de controlador mientras que a la persona que está dirigiendo se le llama el navegador. el otro piensa en la clase que satisfará la prueba. 5. y los mejores Creemos que en todos los modelos estudiados se ejecuta este principio.11.  Programación en parejas: es un caso especial en donde mientras que uno codifica las pruebas de unidades. diseños emergen de equipos auto organizados. . los mejores requisitos. Se sugiere a menudo para que a los dos socios cambien de papeles por lo menos cada media hora o después de que se haga una prueba de unidad. Esto ya que el diseño se considera una fase que puede y debe modificarse en el transcurso del diseño del software.Las mejores arquitecturas. ya que en todos los modelos vemos un orden y unas premisas de ejecución para lograr el diseño optimo del software.

ANÁLISIS ORIENTADO A OBJETOS PROGRAMA QUE TRANSFORMA COORDENADAS POLARES A COORDENADAS RECTANGULARES Sustantivos Programa Operaciones Angulo Verbos realizar Program a Atributos Operación sin cos Angulo grados minutos segundos radian pi gradoTotal r sumar mostrarGradoTotal calcularRadian mostrarRadian Coordenada x y Metodos Iniciar mostrarCo or calcularCoor .

Angulo ~grados:float ~minutos:float ~segundos:float ~radian:float ~pi:float ~gradoTotal:float ~radio:float Sumar (): float mostrarGradoTotal(): float calcularRadian():float mostrarRadian():float 1 sin 1 cos Operación ~sin ~cos MostrarCoor(): void 1 Coordenada 1 Programa ~x:float ~y:float calcularCoor (): float mostrarCoor (): float +form:Angulo 1 Trabaja en iniciar(): void .

 84:.947.948/08419. -. 1.8 03970.947 ./0.8.73485476:F0830.:3.8 7E5/..-0   7002486:0:31.2-4 .2-4   ..:.3E88 . .7.848 .4 843 3/85038. :3 06:54 /0 97..4380.3 :3 J3/./5./4897.9.7.0 6:0 . /0 8419../O08.545..88947.40708:0390573.0848.70  . 34 90308 45.430 :3 573..8   .5740..30.-.307.4.0780. 8.80 /0 57:0-.90 /0 /090723./.830./4 010.20390 03.08/.-7.9.9.8:..41.248.7.438:85745../08/0 :8:..6:0..:34/04824/048.-..8 6:0 80 /090.9..408.039.740 .3 ./..70.8 08 2.702482E8.5740.9.7 089.2-4  45720746:0/0-07J../..0 /0 01. :3 547.548  97.6:00/80N4/0 08948 /0-0 80703..9-0 .01.9.85.4  .:3/80N409484     $00.70 .425.48 03 0 /80N4 /0 8419./ 5.6:07/08.70  5.O3 08 2: 8250 .-. 894/48 48 3907./. /0 47..3/4 /090.4389.079/:2-70 03 48706:8948/0.08843907.8. 2047 2.079/:2-708070/:.94  0 /80N4 /08419.03.8 802570  34 30.&$% #     08.438:9.30.8 4 /0850:0  43 :3 574.:32.54 /0 . 7.0390 0348.084 03 .8:2248 6:0 ..0   %4/4848574..774. .08.7.74     /0.-085.3E88 0348/80N48 .70807E83/:/.08.080573.07.084907.54   7:54/0.9./47     !476:F:3574.07010703.0848 089E3 .079/:2-70 6:003/10703908907. /4.7.03./..8 08948 574-02.7 :3 1.39084-70..48  7002486:094/4848574.O3 /0 2.4 /0 30307J.4803 .:/0 ...:.23.O3.8   0 .8 57028. 04 ./.:2039.0 573.7-..2E82.3.4308348.9.43 8: ...43:3574.80 /0 08948 574..4  5./4 .7/. 3.084 907..70.78.0708570:39.:.390303/4 :3 47/03 O.34-7.981.82.70. .0 /0 3.8/0&8:.0848E0880-.7./ /0 48 /4.948/08419.O3  :3 24/0..74  807 .03:37:54/097.30324/048907.3908 /0 06:54 2:0897.:9.5742.9.

4/1.47.O3800/.O36:09.7.2.:3.438/07..54 .76:90..5008547420348.2-03/0 5.0../08 049745038.0248 :3 47/03  :3.:9..4/1..3.:784/0/80N4/08419. 54700254 . 57:0-.O3035.6:0089E.70     5.0342-70 /0.981.507843.2..2-F308/0/80N4  894.-7..8 /0 00.7E..03/43/020397.6:0.8  48 204708 706:8948    48 204708 /80N48020703/006:548..70   !747.:9447.6:00/80N480.86:0.9F../.05948   #01.43897:.48/4884.806:08./4720397.7488:03908.7.03/4.8 204708 ..86:0:34 .48./0:3/./               ./47 $08:070.806:05:0/0/0-024/1.507843.:3...840850.9:7.70/80N445924/08419.6:0089E/703/4800.43974. 6:0 03 94/48 48 24/048 .O308:3.1./0.O3 5./488000.8/0:3/.03../48   7002486:00394/484824/048089:/.0890573. 03..3.857:0-.47.780 03097.20/.70..808:3.4/085:F8/06:080.203:/45......38.8 57028.  .43. 57:0-.:..

. 7 8:2.7#.7 24897. $$ #%  % $ !# #"&%#$ # #$! #$  #$#%&#$  $:89./.77.4308 3:4    97-:948 !747..:..7447          .    '07-48 70.  507. .   094/48 3.7#.7 24897./48 23:948 80:3/48 7./.39.O3 83 .74 47  ./4%49./.48  3:4 7.48 !747./4%49./.3 5 7..2 .2...3 447/03..:.3 24897.7 507..

9  ./.9 =514./.77.9       14723:4   @f f©f ° 3.9 24897.7447 14.9 .9 =7../4%49.7 14.9 24897.314.7447 14..7#.7447 .2..48  4897.9 =23:94814.9 =80:3/4814.4/   447/03.:.     !747..7 .  3:4 =7. =14.7#./4%49./.3 14./4814.9 24897..4/          .9 $:2.:.9 =7.O3 =83 =.9  ¾°  n¾ 507.9 =14.3 14./. 14.9 =7./414.14..

    .