Test Principios Lean
![]() |
![]() |
![]() |
Título del Test:![]() Test Principios Lean Descripción: Principios Lean |




Comentarios |
---|
NO HAY REGISTROS |
(Ingeniería de Software II) Herramientas: Es un soporte de ayuda para construir el software. Soporte para análisis de requerimiento. Soporte de ayuda para realizar el diseño. (Ingeniería de Software II) Métodos: Indican la forma técnica de cómo construir el proyecto software. Permite realizar tareas de análisis de requerimientos, diseño, construcción de programa, pruebas y mantenimiento. Se definen las actividades para poder realizar el software. Indica la forma técnica de cómo realizar las pruebas y mantenimiento. (Ingeniería de Software II) Proceso: Es un soporte de ayuda para construir el software. Permite realizar tareas de análisis de requerimientos. En el proceso se definen las actividades para poder realizar el software. (Ingeniería de Software II) Compromiso con la calidad: Es el que realiza la gestión para obtener un software de calidad, y hace revisiones para hacer mejoras al producto. Permite realizar tareas de análisis de requerimientos. Permite realizar tareas de construcción de programa, pruebas y mantenimiento. (Ingeniería de Software II - Sintomatología ) En las fases iniciales: Durante sus primeras versiones, las nuevas funcionalidades fluyen de manera graciosa y natural, casi parecen construirse solas. Durante sus primeras versiones, comienzan a surgir una serie de problemas y situaciones que muestran que algo no va bien. Ninguna de la anteriores. (Ingeniería de Software II - Síntomas) Rigidez: Tendencia a que software se rompa en múltiples sitios, cuando realiza el cambio. Incapacidad de reutilizar piezas por el gran acoplamiento. Dificultad de realizar cambios en el software incluso en tareas sencillas. Ninguna. (Ingeniería de Software II - Síntomas) Fragilidad: Ninguna. Dificultad de realizar cambios en el software incluso en tareas sencillas. Dificultad de realizar mantenimiento en el software. Tendencia a que el software se rompa en múltiples sitios cada vez que se realiza un cambio en el, incluso sin tener relación el cambio con lo que se rompe. (Ingeniería de Software II - Síntomas) Inmovilidad: Tendencia a que el software se rompa en múltiples sitios cada vez que se realiza un cambio en el, incluso sin tener relación. Dificultad de realizar cambios en el software incluso en tareas sencillas. Incapacidad de reutilizar piezas del código por el gran acoplamiento que tiene, haciendo que este sea inmovible cuando la funcionalidad es prácticamente la misma que la desea. Para realizar la solución requiere mayor esfuerzo. (Ingeniería de Software II - Síntomas) Viscosidad: Tendencia a que el software se rompa en múltiples sitios cada vez que se realiza un cambio en el, incluso sin tener relación. Dificultad de realizar cambios en el software incluso en tareas sencillas. Incapacidad de reutilizar piezas del código por el gran acoplamiento que tiene, haciendo que este sea inmovible cuando la funcionalidad es prácticamente la misma que la desea. La tendencia de que, en el ámbito del software, realiza la solución buena requiere mayor esfuerzo comparando con la solución mala y rápida y en le ámbito de control de desarrollo, este es lento e ineficiente. (Ingeniería de Software II) Principios que guían el proceso. 1. Ser ágil 2. En cada etapa, centrarse en la calidad 3. Estar listo para adaptar 4. Formar un equipo eficaz. 5. Establecer mecanismos para la comunicación y coordinación 6. Administrar el cambio 7. Evaluar el riesgo. 8. Crear productos del trabajo que agreguen valor para otros. Ninguna. 1. Divide y vencerás. 2. Entender el uso de la abstracción. 3. Buscar la coherencia. 4. Centrarse en la transferencia de información. 5. Construir software que tenga modularidad eficaz. 6. Buscar patrones. 7. Cuando sea posible, representar el problema y su solución desde varias perspectivas diferentes. 8. Tener en mente que alguien dará mantenimiento al software. (Ingeniería de Software II) Principios que guían la práctica. 1. Divide y vencerás. 2. Entender el uso de la abstracción. 3. Buscar la coherencia. 4. Centrarse en la transferencia de información. 5. Construir software que tenga modularidad eficaz. 6. Buscar patrones. 7. Cuando sea posible, representar el problema y su solución desde varias perspectivas diferentes. 8. Tener en mente que alguien dará mantenimiento al software. 1. Ser ágil 2. En cada etapa, centrarse en la calidad 3. Estar listo para adaptar 4. Formar un equipo eficaz. 5. Establecer mecanismos para la comunicación y coordinación 6. Administrar el cambio 7. Evaluar el riesgo. 8. Crear productos del trabajo que agreguen valor para otros. Ninguna. Ingeniería de Software - Principios LEAN. Austero o eficiente) tiene su origen en el sistema de producción de Toyota. Desarrollado entre los años 30 y 80 del siglo pasado que buscaba tener un nivel de manufactura similar al de los EEUU sin contar con el mismo número de partes disponibles. Todas las anteriores. Adaptar a una mentalidad y prácticas con herramientas y técnicas que la soportan. Ingeniería de Software – LEAN La IDEA, La idea principal del desarrollo de software lean es: Mantener todo el enfoque en el cliente, maximizando el valor entregado y minimizando el desperdicio. Busca optimizar el flujo de desarrollo: invertir menos tiempo, necesitar el menor número de personas, minimizar los costos y entregar el producto con el menor número de defectos posible. Todas la anteriores. (Ingeniería de Software II) LEAN – Los siete principios. 1. Eliminar los desperdicios 2. Amplificar el aprendizaje 3. Aplazar las decisiones 4. Entregar rápidamente 5. Empoderar al equipo 6. Internalizar la calidad y la integridad 7. Optimizar en su totalidad. Ninguna. 1. Defectos. 2. Código y funcionalidades innecesarias. 3. Optimización prematura. 4. Documentación innecesaria. 5. Tiempo de espera: retrasos en la entrega del software, falta de información, falta de instrucciones claras. 6. Procesamiento sin estandarización. Utilizar diferentes pasos cada vez que se completa la misma tarea. 7. Subutilización de la capacidad intelectual de los miembros del equipo. (Ingeniería de Software II) LEAN – Eliminar los siete desperdicios. 1. Defectos. 2. Código y funcionalidades innecesarias. 3. Optimización prematura. 4. Documentación innecesaria. 5. Tiempo de espera: retrasos en la entrega del software, falta de información, falta de instrucciones claras. 6. Procesamiento sin estandarización. Utilizar diferentes pasos cada vez que se completa la misma tarea. 7. Subutilización de la capacidad intelectual de los miembros del equipo. Ninguna. 1. Eliminar los desperdicios 2. Amplificar el aprendizaje 3. Aplazar las decisiones 4. Entregar rápidamente 5. Empoderar al equipo 6. Internalizar la calidad y la integridad 7. Optimizar en su totalidad. (Ingeniería de Software II) LEAN- Amplificar el aprendizaje. Implementar un ciclo continuo: 1. Implementar una solución 2. Medir su espacio 3. Aprender al respecto. Ninguno. 1. Implementar una solución 2. Calidad de software 3. Aprender el código. Ingeniería de Software II) LEAN- Amplificar el aprendizaje. Existen dos formas principales de aplicar este principio: 1. Mostrarles la aplicación antes de liberarla para validar la implementación. 2. Desarrollar flujos e interfaces en colaboración con el cliente. 3. Liberar versiones sólo para un número reducido de usuarios y obtener retroalimentación. 01 Necesidades del usuario. 02 Requerimiento del Software. 03 Diseño. 04 El diseño se implementa en código. 05 El código es aprobado y documentado. 06 Producto de software de calidad. (Ingeniería de Software II) LEAN- Amplificar el aprendizaje. Aplazar las decisiones: Es la habilidad de tomar decisiones respecto a la funcionalidad del software tan tarde como sea posible cuando no se cuenta con la información apropiada. 1. Un diseño de software que permita cambios en su implementación de forma fácil. 2. Realizar un desarrollo que involucre diseño e implementación a la par. 3. Entregas rápidas de software. Todas las anteriores. LEAN - Internalizar la calidad y la integridad. Desperdicio de recursos. Pérdida de interés en el usuario. Incapacidad de corroborar el progreso real en nuestras entregas. Definición de estándares. Revisión de código entre los miembros del equipo. Programación entre pares. Pruebas automáticas del software. Integración continua del software. Desarrollo dirigido por pruebas (Test Driven Development). Consciencia de cada miembro del equipo acerca de la importancia de la calidad en el software. |