Benemérita Universidad Autónoma de Puebla Vicerrectoría de ... · MAPA CONCEPTUAL DE LA ASIGNATURA: Benemérita Universidad Autónoma de Puebla ... 1.3 Scrum en el contexto de

Benemérita Universidad Autónoma de Puebla

Vicerrectoría de Docencia

Dirección General de Educación Superior

Facultad de Ciencias de la Computación

INGENIERIA DE SOFTWARE AVANZADA

1

PLAN DE ESTUDIOS (PE): INGENIERIA EN CIENCIAS DE LA COMPUTACIÓN

AREA: OPTATIVA DISCIPLINARIA

ASIGNATURA: INGENIERIA DE SOFTWARE AVANZADA

CÓDIGO: CCOM-607

CRÉDITOS: 5

FECHA: 15 DE JULIO DE 2011






2

1. DATOS GENERALES

Nivel Educativo:

Licenciatura

Nombre del Programa Educativo:

Licenciatura en Ingeniería en Ciencias de la Computación

Modalidad Académica:

Presencial

Nombre de la Asignatura:

Ingeniería de Software Avanzada

Ubicación:

Optativa disciplinaria

Correlación:

Asignaturas Precedentes:

Ingeniería de Software

Asignaturas Consecuentes:

Conocimientos, habilidades, actitudes y valores previos:

Conocimientos: Programación, Bases de datos, Matemáticas básicas, Probabilidad y estadística Básica, Métodos y Metodologías de la Ingeniería de Software. Habilidades: Identificar y solucionar problemas, Análisis, diseño, Abstracción, Comunicación escrita y oral, trabajo en grupo, manejo de herramientas computacionales, autodidacta, trabajar bajo presión, etc. Actitudes Ser: Disciplinado, líder, proactivo, responsable, solidario, critico, colaborador, comprometido, respetuoso, tolerante






3

2. CARGA HORARIA DEL ESTUDIANTE

Concepto Horas por periodo Total de

horas por periodo

Número de

créditos Teorías Prácticas

Horas teoría y práctica Actividades bajo la conducción del docente como clases teóricas, prácticas de laboratorio, talleres, cursos por internet, seminarios, etc. (16 horas = 1 crédito)

3 0 80 3

Horas de práctica profesional crítica. Servicio social, veranos de la investigación, internado, estancias, ayudantías, proyectos de impacto social, etc. (50 horas = 1 crédito)

Horas de trabajo independiente. En donde se integran aprendizajes de la asignatura y tiene como resultado un producto académico ejem. exposiciones, recitales, maquetas, modelos tecnológicos, asesorías, ponencias, conferencias, congresos, visitas, etc. (20 horas = 1 crédito)

0 2 48 2

Total 3 2 128 5

3. REVISIONES Y ACTUALIZACIONES

Autores:

MARIA DE LA CONCEPCION PEREZ DE CELIS HERRERO (COORD. DE PROGRAMA DE ASIGNATURA) MARIA DEL CONSUELO MOLINA GARCIA YALU GALICIA HERNANDEZ ABRAHAM SANCHEZ LOPEZ RAFAEL DE LA ROSA FLORES GUILLERMO MARIN DORADO ALMA DELIA AMBROSIO VÁZQUEZ

Fecha de diseño: 03 DE FEBRERO DE 2009

Fecha de la última actualización: 15 DE JULIO DE 2011

Fecha de aprobación por parte de la academia de área

15 DE JULIO DE 2011

Fecha de aprobación por parte de CDESCUA

28 de Noviembre 2011

Fecha de revisión del Secretario Académico 28 de Noviembre 2011






4

Revisores:

AMBROSIO VÁZQUEZ ALMA DELIA ANZURES GARCÍA MARIO. ARCHUNDIA SIERRA ETELVINA. BOONE ROJAS MARIA DEL ROCIO CARRILLO RUIZ MAYA GONZÁLEZ CALLEROS JUAN MANUEL GUERRERO GARCÍA JOSEFINA MOLINA GARCIA MARÍA DEL CONSUELO PÉREZ DE CELIS HERRERO MARÍA DE LA CONCEPCIÓN SOMODEVILLA GARCÍA MARÍA JOSEFA

Sinopsis de la revisión y/o actualización:

Se establece una orientación metodológica para abordar los temas del programa de asignatura basada en el siguiente tipo de esquema de trabajo: -Planeación didáctica del Tema. -Propuesta de actividades de motivación y diagnóstico para el estudio del Tema. -Desarrollo del Tema. -Actividades de Evaluación del Aprendizaje del tema. Se incluyen como parte de la orientación didáctica pedagógica y dentro del programa de asignatura la especificación de las actividades de diagnóstico, de evaluación del aprendizaje y complementarias propuestas para temas del presente programa. Las cuales se especifican en el libro desarrollado por profesores responsables de la actualización. Ref. Libro Electrónico: Tópicos Selectos para la Enseñanza de la Ing. de Software: Introducción a la Ingeniería de Software. Verano 2011. www.cs.buap.mx

4. PERFIL DESEABLE DEL PROFESOR (A) PARA IMPARTIR LA ASIGNATURA:

Disciplina profesional: CIENCIAS DE LA COMPUTACION

Nivel académico: MAESTRÍA

Experiencia docente: 3 AÑOS

http://www.cs.buap.mx/






5

Experiencia profesional: 3 AÑOS

Nota: se consideran la disciplina profesional que debe tener, el grado académico, la experiencia disciplinaria y docente, las asignaturas que debe haber impartido y la formación o capacitación docente/disciplinaria que se juzgue adecuada.

5. OBJETIVOS:

General:

Que el alumno pueda ser capaz de realizar proyectos y productos de calidad mediante la aplicación de los métodos de la ingeniería de software

Específicos:

Que el alumno identifique las ventajas de aplicar metodologías de desarrollo de software.

El alumno aplique Ingeniería de requerimientos para obtener las especificaciones de un Sistema.

Que el alumno planifique formas de trabajo en equipo de desarrollo de software

El alumno generé documentación bajo estándares de procesos de desarrollo

El alumno aplique herramientas de última generación en el proceso de desarrollo de software.






6

6. MAPA CONCEPTUAL DE LA ASIGNATURA:






7

7. CONTENIDO

Unidad 1

Objetivo Específico

Contenido Temático/Actividades

de aprendizaje

Bibliografía

Básica Complementaria

Modelos Ágiles de Proceso

Que el alumno se familiarice con las metodologías de desarrollo derivadas del paradigma orientado a objetos

1.1 Manifiesto Ágil “Tópicos Selectos para la Enseñanza de la Ing. de Software: Introducción a la Ingeniería de Software.” Academia del área de Bases de Datos e Ing. de Software. Verano 2011. 1. www.cs.buap.mx 2. Cockbun, A.

“Agile Software Development”. Addison-Wesley. 2001.

3. Scott W. Ambler The Object Primer, Third Edition Cambridge University Press © 2004 ISBN:0521540186

1. PRESSMAN, Roger S.

Ingeniería del software: un enfoque práctico. 5. ed. Madrid: McGraw-Hill, 2002. 601

2. SENN, James A. Análisis y diseño de sistemas de información. 2. ed. México: McGraw-Hill, 1992. 942 p.

3. LARMAN, Craig. UML y patrones introducción al análisis y diseño orientado a objetos. 2 ed. México: Prentice-Hall, 1999. 507 p.

4. JACOBSON, Ivar; BOOCH, Grady y RUMBAUGH, James. El proceso unificado de desarrollo de software. Madrid: s.n., 2000. 438 p.

1.2 Metodologías ágiles 1.2.2 Introducción a metodologías ágiles 1.2.3Proceso XP 1.2.3.1Prácticas XP 1.2.4 Metodología de desarrollo DAS

1. Jeffries, R., Anderson, A., Hendrickson, C. “Extreme Programming Installed”. Addison-Wesley. 2001

2. Newkirk, J., Martin R.C. “Extreme Programming in Practice”. Addison-

Direcciones electrónicas: www.aanpo.org/aticles/index www.refactorin.com www.xprogramming.com www.refactorin.com www.xprogramming.com www.adaptivesd..com www.dsdm.org www.cs3inc.com/DSDM.htm www.controlkchaos.com www.crystalmethodologies.org www.thecoadletter.com www.agilemodeling.com







8

Unidad 1



de aprendizaje

Bibliografía


Wesley. 2001.

Introducir los conceptos básicos del paradigma de aspectos. Conocer el paradigma de Aspect-Oriented Programming con la suficiente profundidad como para comparar los diferentes enfoques existentes.

1.3 Scrum en el contexto de los métodos ágiles. 1.3.1. El proceso de Scrum. 1.3.2 Conceptos de Scrum: roles, tipos de reuniones, productos. 1.3.3 Especificación de requerimientos con User Stories y Acceptance cases

Schwaber K., Beedle M., Martin R.C. “Agile Software Development with SCRUM”. Prentice Hall. 2001.


1.4 Método de desarrollo de sistemas dinámicos MDSD 1.4.1Introducción a

MSDS 1.4.1.1 Melé 1.4.1.2 Cristal 1.4.2Desarrollo conducido por características DCC 1.4.3 Modelado ágil MA

Stapleton J. “Dsdm Dynamic Systems Development Method: The Method in Practice”. Addison-Wesley. 1997.


1.5 Metodología orientada a Aspectos: 1.5.1Proceso de desarrollo de software orientado a aspectos AOP 1.5.2 Proceso de desarrollo de software orientado a objetivos SOP 1.5.3 Evaluación de arquitecturas desde la perspectiva aspectual

[AspectJ] Homepage of AspectJTM, Xerox Palo Alto Research Center (Xerox Parc), Palo Alto, California. http://aspectj.org/

[BCHRT 05] D. Binkley, M. Ceccato, M. Harman, F. Ricca, and P. Tonella.


http://www.amazon.com/exec/obidos/search-handle-url/index=books&field-author=Schwaber%20Ken/102-2598906-4646501

http://www.amazon.com/exec/obidos/search-handle-url/index=books&field-author=Beedle%2C%20Mike/102-2598906-4646501

http://www.amazon.com/exec/obidos/search-handle-url/index=books&field-author=Martin%2C%20Robert%20C./102-2598906-4646501

http://www.amazon.com/exec/obidos/search-handle-url/index=books&field-author=Stapleton%2C%20Jennifer/102-2598906-4646501

http://aspectj.org/






9

Unidad 1



de aprendizaje

Bibliografía


ASAAM

Automated refactoring of object oriented code into aspects. In 21st IEEE International Conference on Software Maintenance (ICSM), 2005.

[CBE99] C. Constantinides, A. Bader and T. Elrad. A

Unidad 2 Objetivo

Específico


de aprendizaje

Bibliografía


PSP Personal Software Process (Sopor te de Metodologías basadas en Modelos de Madurez de Procesos )

1. Conocerá las áreas especificas donde se realiza el proceso de planeación de PSP 2. Conocerá el proceso de estimación de PSP 3. Conocerá los beneficios de las revisiones entre colegas 4. Aprenderá algunas estrategias básicas para alcanzar la calidad del Software 5. Conocerá

3.1 Conceptos y principios 2.1.1Objetivos 2.1.2Niveles de PSP 2.2 PSP 0 Identificar Actividades 2.2.1 Base de Mejora: Planeación, Evaluación, Resultados 2.2.2 Documentar el Proceso: Actividades, Tiempos, Defectos

1.“Tópicos Selectos para la Enseñanza de la Ing. de Software: Introducción a la Ingeniería de Software.” Academia del área de Bases de Datos e Ing. de Software. Verano 2011.

www.cs.buap.mx “Software Engineering: A Practioner’s Approach”, Roger S. Pressman, McGraw Hill, 1997.

“An Integrated Approach to Software Engineering”, Pnkaj Jalote, Springer, 1997. “Team Software

2.3 PSP 0.1 Registro de Tamaño 2.3.1 Líneas de código 2.3.2 Puntos de función 2.3.3 Estándar de







10

Unidad 2 Objetivo

Específico


de aprendizaje

Bibliografía


principios de mejoras del proceso basado en PSP

Codificación

Process”, Watts Humphrey, Software Engineering Institute, 2001. Personal Software Process”, Watts Humphrey, Software Engineering Institute, 1999. “Ingeniería de Software”, Ivan Sommerville, Pearson, 2003.

2.4 PSP 1 Planeación y estimaciones 2.4.1 Estimar y planear el tamaño y tiempo en base a lo historico 2.4.2 Reportes de Pruebas

2.5 PSP 1.1 2.5.1 Mejorar estimación de recursos

2.6 PSP 2 Calidad 2.6.1 Detección temprana de defectos, en base a la predicción de estos. 2.6.2 Revisiones de diseño

2.7 PSP 2.1 Uso de técnicas para verificación de Diseño 2.7.1 Uso de plantillas

2.8 PSP 3.0 Mejora del proceso en términos de hacerlo repetible (cíclico) 2.8.1 Para aplicación a programas de mayor tamaño 2.8.2 Registro del seguimiento 2.8.3 Análisis del resumen de la planeación, tiempos, tamaños y defectos por cada ciclo






11

Unidad 2 Objetivo

Específico


de aprendizaje

Bibliografía


2.9 Beneficios de PSP y verificación de reportes

Unidad 3 Objetivo

Específico


de aprendizaje

Bibliografía


Team Sof tware Process , TSP. (Sopor te de Metodologías basadas en Modelos de Madurez de Procesos )

1. Conocerá una metodología de desarrollo orientada a equipo 2. Conocerá la dinámica para definir objetivos de proyecto 3. Conocerá los roles que componen un equipo TSP 4. Aprenderá a presidir una reunión para inicio de proyecto 5. Conocer las partes esenciales de la calidad de software basado en TSP 6 Conocerá la mecánica básica de mejoras del proceso

3.1Conceptos y principios 3.2 Estrategia de

desarrollo en ciclos 3.3 Los procesos de

TSPi 3.4 Lanzamiento del

proyecto 3.5 Estrategia de

Desarrollo 3.6 EL plan de

Desarrollo 3.7 Definicion de

Requerimientos 3.8 Diseñando en

equipo 3.9 Implementacion

del producto 3.10 Pruebas de

integracion 3.11 El Postmortem

“Tópicos Selectos para la Enseñanza de la Ing. de Software: Introducción a la Ingeniería de Software.” Academia del área de Bases de Datos e Ing. de Software. Verano 2011. www.cs.buap.mx “ Software Engineering: A Practioner’s Approach”, Roger S. Pressman, McGraw Hill, 1997. “An Integrated Approach to Software Engineering”, Pnkaj Jalote, Springer, 1997. “Team Software Process”, Watts Humphrey, Software Engineering

1. www.sei.cmu.edu (Software Engineering Institute of Carnegie-Mellon University). 2. www.jese.fhg.de (Fraunhofer Institute for Software Engineering Germany). 3. Sunset.usc.edu (Center for Software Engineeering of the USC). 4. · Diversos artículos sobre el área de ingeniería de software proporcionados por el profesor.







12

Unidad 3 Objetivo

Específico


de aprendizaje

Bibliografía


Institute, 2001. Personal Software Process”, Watts Humphrey, Software Engineering Institute, 1999. “Ingeniería de Software”, Ivan Sommerville, Pearson, 2003.

8. CONTRIBUCIÓN DEL PROGRAMA DE ASIGNATURA AL PERFIL DE EGRESO

Unidad

Perfil de egreso (anotar en las siguientes tres columnas a qué elemento(s)

del perfil de egreso contribuye esta asignatura)

Conocimientos Habilidades Actitudes y valores

Unidad 1: Modelos Ágiles de Proceso Unidad 2: PSP Personal Software Process (Sopor te de Metodologías basadas en Modelos de Madurez de Procesos ) Unidad 3: Team Sof tware Proces s , TSP. (Sopor te de Metodologías basadas en Modelos de Madurez de Procesos )

Diseño, gestión y administración de proyectos

Para analizar, elaborar, evaluar, integrar, operar, desarrollar o adaptar proyectos, productos y tecnología

Para interactuar con otros especialistas de diversas áreas de conocimiento, entender sus necesidades y proponer soluciones.

Para aplicar metodologías para el análisis, diseño e implementación de sistemas basados en Para expresar las ideas y pensamientos de manera clara, precisa y correcta.

hardware y software.

Podrá incorporarse a empresas (o generarlas) que demanden el desarrollo, el uso y el mantenimiento de sistemas de cómputo de propósito específico.

Estará preparado para trabajar en equipo, emprender, liderar proyectos e incidir en la transformación de la realidad sustentablemente.

Será un profesional






13

Unidad

Perfil de egreso (anotar en las siguientes tres columnas a qué elemento(s)

del perfil de egreso contribuye esta asignatura)

Conocimientos Habilidades Actitudes y valores

responsable, solidario, crítico, ético y comprometido con la sociedad y con el medio ambiente.






14

9. Describa cómo el eje o los ejes transversales contribuyen al desarrollo de la asignatura (ver síntesis del plan de estudios en descripción de la estructura curricular en el apartado: ejes transversales)

Eje (s) transversales Contribución con la asignatura

Formación Humana y Social La importancia del desarrollo de software de calidad en beneficio de las personas y la sociedad en lo que corresponde a la automatización y gestión de procesos.

Desarrollo de Habilidades en el uso de las Tecnologías de la Información y la Comunicación

En un mundo globalizado y el alcance de las tecnologías de la información permite al alumno investigar respecto de la Ingeniería de Software e implementación como producto en la vanguardia tecnológica.

Desarrollo de Habilidades del Pensamiento Complejo

Análisis de los modelos orientado a objetos en la solución de problemas y su aplicación en el desarrollo de proyectos respecto de la asignatura (pensamiento crítico y creativo).

Lengua Extranjera Comprensión de los documentos, libros, artículos y espacios web en inglés.

Innovación y Talento Universitario La evaluación de los modelos orientados a objetos y lo que se puede mejorar, generando espacios para emprender en la competitividad del desarrollo del software de vanguardia del modelaje orientado a objetos.

Educación para la Investigación La continua mejora del desarrollo de software y los cambios en las tecnologías invita al alumno a estar en una constante






15

investigación de los avances tecnológicos y desarrollo del software en la solución de problemas y proyecto.

10. ORIENTACIÓN DIDÁCTICO-PEDAGÓGICA. (Enunciada de manera general para aplicarse durante todo el curso). Ver Anexo.

Estrategias a-e Técnicas a-e Recursos didácticos

clases teóricas, de aproximadamente 90 minutos cada una.

Lectura por parte de los alumnos de artículos. Los alumnos deberán hacer, en grupos, presentaciones sobre estos artículos

Ejecución de un trabajo práctico que incluirá un pequeño desarrollo de software que sirva para entender los problemas de la construcción de grandes sistemas y para producir entregables representativos de este tipo de proyectos (por ejemplo, los entregables referidos a la gestión del proyecto).

Clases prácticas, que tendrán distintas modalidades según el caso:

1. Resolución de ejercicios en clase (por parte de los alumnos con posterior discusión) 2. Clases de presentación y resolución de ejercicios en pizarrón 3. Clases de explicación y/o consulta sobre el trabajo práctico. Durante algunas de

1. Exposiciones verbales por parte del profesor. 2. Exposiciones por parte del Alumno 3. Realización de Trabajos por parte del Alumno 4. Realización de Lecturas por parte del Alumno 5. Desarrollo de estudios de campo por parte del alumno 6. Desarrollo de un proyecto integrador.

Presentaciones, uso de herramientas de software, artículos de investigación.






16

Estrategias a-e Técnicas a-e Recursos didácticos

las clases los alumnos deberán hacer tareas de sus proyectos (Trabajo Práctico).

Nota: ver glosario 11. CRITERIOS DE EVALUACIÓN

Criterios Porcentaje

Exámenes 40%

Participación en clase 10%

Tareas

Exposiciones

Simulaciones

Trabajos de investigación y/o de intervención

Prácticas de laboratorio

Visitas guiadas

Reporte de actividades académicas y culturales

Mapas conceptuales

Portafolio

Proyecto final 40%

Otros 10%

Total 100%

Nota: Se refiere a lo que se evaluará del proceso A-E, considerando sus finalidades, la información y las consecuencias que se derivan de este proceso, los resultados, los momentos, las orientaciones, las técnicas y los instrumentos, todo esto nos conducirá al diálogo y reflexión sobre el aprendizaje del grupo. Los porcentajes serán establecidos por la academia de acuerdo a los objetivos de cada asignatura.

12. REQUISITOS DE ACREDITACIÓN

Estar inscrito oficialmente como alumno del PE en la BUAP

Haber aprobado las asignaturas que son pre-requisitos de ésta

Aparecer en el acta

El promedio de las calificaciones de los exámenes aplicados deberá ser igual o mayor que 6

Cumplir con las actividades propuestas por el profesor

Nota: Describe los requisitos que el estudiante debe cumplir para acreditar la materia.






17

ANEXO

Ejemplo de Tipo de Actividades Propuestas.

Especificadas en extenso en el libro de Ref. Básica:

“Tópicos Selectos para la Enseñanza de la Ing. de Software: Introducción a la Ingeniería de Software.” Academia del área de Bases de Datos e Ing. de Software. Verano 2011. www.cs.buap.mx

Actividades Complementarias

Métodos ágiles

Se propone realizar una actividad grupal de análisis y reflexión para cerrar el estudio de métodos

ágiles.

Debido a la novedad de las metodologías ágiles, muy pocos datos empíricos están disponibles en

relación con cada método. El desafío más grande para el líder del proyecto, por lo tanto, es la selección

de un método apropiado dentro de la cantidad de métodos ágiles disponibles en la actualidad. Esto

es muy parecido a la situación que enfrentaron los primeros desarrolladores en adoptar la tecnología de

objetos. Aunque todos los métodos ágiles, en cierta medida, se ajustan a los principios descritos en el

manifiesto ágil, no todos se gobiernen en el mismo sentido. Existen diferencias significativas en

términos de tamaño del equipo, la propiedad del código, la duración de cada ciclo iterativo, el énfasis

de actividades de flujo al frente y de flujo inverso, y los mecanismos

para una rápida retroalimentación y adaptación al cambio.

Melnik [7] hace un estudio empírico para identificar el uso de métodos ágiles en la práctica. Algunos

de sus resultados son los siguientes:

1. Estado de uso en la practica

a. Zona amplia libre de mediciones

Pocos experimentos







18

Incluso menos resultados publicados

Foco mínimo en recolección de datos

Datos existentes generalmente incompletos

Consultores de muy alto nivel solo transmiten anécdotas

b. Experimentos existentes

Muy triviales o

Defectos experimentales

i) Gran cantidad de variables que no pueden ser controladas

ii) Pequeñas muestras

iii) Sujetos ajenos a la profesión

iv) Conducido en un lapso breve de tiempo

2. La adopción de esta metodología ha sido lenta en la industria (41%)

3. Poco conocida (54 % no sabe de ella) y de los que la conocen y aún no la adoptan (29%) muy

pocos se encuentran en la posibilidad (7%) de adoptarla.






19

4. El tamaño es importante. Cuando nos referimos al volumen de personas que trabajan en una

compañía. Mientras mayor sea el número mayor el nivel de conocimiento de los métodos ágiles.

5. Los proyecto que usan métodos ágiles han logrado un nivel de madurez mayor que solo

proyectos piloto






20

6. Los beneficios tangibles que se reportan, 90% incremento de productividad, 85% reducción de

defectos de software, 83% aceleración de tiempo para poner en el mercado el producto, 66%

reducción de costo.






21

7. Un caso de estudio que muestra el éxito en el área aeroespacial con la empresa Boeing. El

8. Técnicas que son más usadas, planeación iterativa (65%), pruebas de unidades de desarrollo

(60%), discusión diaria (55%), planeación de entregables (54%), integración continua (50%).

9. Las metodologías más usadas






22

10. Han logrado pasar el abismo los métodos ágiles y no quedar en ser algo para visionarios, al

parecer ha pasado esa barrera.

11. Veamos ahora que industrias han adoptado los métodos ágiles






23

12. La satisfacción en el trabajo es mayor en un esquema ágil

Actividad 1. Reflexión sobre uso de métodos ágiles

Objetivo. El alumno reflexionará sobre la eficacia de los métodos ágiles.






24

Especificaciones.

Responder al cuestionario y hacer un debate en clase.

Ejemplo de Resultados.

1. ¿Los métodos ágiles son buenos por las prácticas que promueven o por qué sus promotores

simplemente son muy buenos desarrolladores?

Para lograr resultados se requiere disciplina, y mucha practica, es por eso que un método

ágil solo será exitoso si se adopta de forma correcta.

Un proceso ágil va a funcionar con personas competentes y por encima del promedio [1].

2. ¿Qué consecuencias negativas puede haber en la empresa respecto al nivel de los

profesionales que se requieren para el uso de métodos ágiles?

Dificultad para conseguir personal pues será muy complicado encontrar equipos de

desarrolladores que funcionen en el médelo ágil. Afectar autoestima de tu personal al ser un

esquema de selección de personal muy elitista lo cual afectara la moral de los

desarrolladores no-agiles.

3. ¿Cómo se va afectada la toma de decisiones?

Los desarrolladores de software y el cliente toman la mayoría de las decisiones. Esto crea un

ambiente plural de toma de decisiones con diferente historial, actitud, metas, y disposición

cognitiva. La toma de decisiones es más complicada comparada con un enfoque tradicional

donde el administrador del proyecto toma la mayoría de las decisiones.

4. ¿Cuál es el nivel de dificultad de adoptar esta cultura de toma de decisiones?

Una organización que adopta un modelo ágil debe considerar que se requiere de un esfuerzo

enorme en tiempo y paciencia para lograr instaurar la cultura de confianza y respeto

necesarios para que un esquema de toma de decisiones ágil funcione.

5. ¿Cómo debe ser el cliente de un desarrollo ágil?

El éxito de un desarrollo ágil depende de encontrar clientes que van de manera activa a

participar en el proceso de desarrollo. Más aún, los clientes deben ser: colaboradores,

representativos, poseer autoridad en la toma de decisiones, comprometidos, y poseer

conocimiento. Un perfil complicado a encontrar sobre todo en sistemas complejos.

6. ¿Listar algunas ventajas del uso de métodos ágiles?

Algunas fortalezas de este modelo son:

Los modelos ágiles enfatizan las comunicaciones cara a cara en vez de la

documentación.






25

Los modelos ágiles son una manera efectiva de trabajar en conjunto para alcanzarlas

necesidades de las partes interesadas en el proyecto.

El modelo ágil se puede decir que es una metodología muy práctica a la hora de tener

que diseñar modelados y documentación, ya que proporciona documentación, ya que

proporciona información de cómo poder realizarlos de una manera ágil, logrando

entregar modelos y documentos que realmente sean de importancia para el usuario y

eliminando los datos que sean innecesarios.

El resultado final es un software de alta calidad en el menor tiempo posible y un cliente

satisfecho.

7. ¿Listar algunas limitantes de los métodos ágiles?

Algunas debilidades de este modelo son:

Combinado con la preferencia por las comunicaciones cara a cara, generalmente los

métodos ágiles son criticados y tratados como "indisciplinados" por la falta de

documentación técnica.

Es un complemento a los métodos existentes, no es una metodología completa.

Los modelos ágiles no son un proceso de desarrollo de software completo, donde no

incluye las actividades de programación, las actividades de prueba, no cubre la gestión

de proyectos, implementación del sistema, las operaciones del sistema, soporte del

sistema u otros elementos relacionados con la realización de proyectos que no sean la

documentación y el modelado.

Hay una falta de énfasis en el diseño y documentación necesarios.

Solo los programadores experimentados pueden tomar las decisiones necesarias durante

el proceso de desarrollo.

El problema con los modelos ágiles adaptables es que requieren un equipo eficaz de

desarrollo tanto a nivel individual como de equipo.

8. ¿Qué problemas se pueden enfrentar una organización para adoptar un enfoque ágil desde el

punto de vista tecnológico?

Las herramientas de soporte juegan un papel crítico en el éxito de la implementación de

un software basado en la metodología ágil. Las organizaciones que busquen adoptar

metodologías ágiles deben invertir en herramientas que apoyen y faciliten

el rápido desarrollo iterativo, gestión de versiones / configuración, refactorización, y

otras técnicas ágiles. Por supuesto, las herramientas por sí sola no puede hacer que el

desarrollo de software con éxito. En una organización la tecnología existente puede

afectar los esfuerzos para migrar a las metodologías ágiles. Para las empresas que confían

únicamente en tecnologías de mainframe puede resultar difícil la migración a los métodos

ágiles en comparación con los que utilizan el desarrollo OO técnicas.






26

9. ¿Cuál de las siguientes aseveraciones es cierta?

a) equipos contentos equipos productivos –Mito

b) equipos contentos baja rotación de personal – Hecho que impacta la economía de la

empresa ya que la rotación de personal tiene un costo de 70% a200% en el salario

anual de los empleados.

10. ¿Cuál de las siguientes aseveraciones es verdadera?

Es posible diagramar a priori y en detalle la totalidad del ciclo de vida y sus artefactos -

Falso

El seguimiento de un plan garantiza la excelencia de un proceso de desarrollo - Falso

El diseño previo implica corrección arquitectónica y/o mejora las cualidades no-funcionales

- Falso

El diseño previo incide sobre la calidad del código - Falso

La semántica de los lenguajes de diseño mapea punto a punto sobre la semántica de los

frameworks de programación - Falso

El diseño y el plan documentan el desarrollo real y/o facilitan su mantenimiento o

transferencia - Falso

-¿Consideras que el desarrollo de tus productos de software que has desarrollado hasta la fecha, ha sido

metodológico y disciplinado?

-¿Tus productos de programación cumplen con algunos o la mayoría de los factores de calidad que se

han revisado?

Documents

Benemérita Universidad Autónoma de Puebla Vicerrectoría de ... · MAPA CONCEPTUAL DE LA ASIGNATURA: Benemérita Universidad Autónoma de Puebla ... 1.3 Scrum en el contexto de