Benemérita Universidad Autónoma de Puebla

Facultad de Ciencias de la Computación

Tópicos Selectos para la Enseñanza de la Ingeniería de Software:

Introducción a la Ingeniería de Software

Academia del Área de Bases de Datos e Ingeniería de Software

Otoño 2011 ISBN: 978-607-487-368-9

2

Autoridades. Dr. Enrique Agüera Ibáñez Rector de la Benemérita Universidad Autónoma de Puebla Mtro. José Jaime Vázquez López Vicerrector de Docencia Dr. Pedro Hugo Hernández Tejeda Vicerrector de Investigación y Estudios de Posgrado M.C. Marcos González Flores Director de la Facultad de Ciencias de la Computación Dr. Luis Carlos Altamirano Robles Secretario De investigación y de Estudios de Posgrado M.C. Yalú Galicia Hernández Secretaria Académica Dr. Roberto Contreras Juárez Secretario Administrativo Revisores. M.C. Martín Estrada Analco.

Prof. José Luis Luna Govea.

Edición: 1ra, Otoño 2011 ISBN: 978-607-487-368-9 Benemérita Universidad Autónoma de Puebla Dirección de Fomento Editorial 4 sur 104 Puebla, Pue. México. Teléfono y fax 0122229-55-00

3

Autores y Profesores de la Academia del Área de Bases de Datos e Ingeniería de Software participantes:

M.C. Alma Delia Ambrosio Vázquez.

C. Dr. Mario Anzures García.

Dra. Etelvina Archundia Sierra.

M.C. María del Rocío Boone Rojas

Dra. Maya Carrillo Ruiz.

Dr. Juan Manuel González Calleros

Dra. Josefina Guerrero García

M.C. María del Consuelo Molina García.

Dra. María de la Concepción Pérez de Celis Herrero.

Dra. María Josefa Somodevilla García.

Coordinadora del Área de Bases de Datos e Ingeniería de Software y Coordinadora de la Publicación del Libro.

M.C. María del Rocío Boone Rojas

Autora Colaboradora, P.I. de la Facultad de Ciencias de la Computación, BUAP.:

M.E. María del Carmen Cerón Garnica.

4

Presentación La comunidad de la Facultad de Ciencias de la Computación, se ha distinguido entre cosas, por su constante preocupación por actualizar los contenidos temáticos de los planes y programas de estudio, lo cual se ha reflejado formalmente en la actualización de los planes y programas de estudio realizada en diferentes periodos y bajo los diversos modelos establecidos institucionalmente, tales como el modelo de créditos y recientemente el Modelo Minerva.

Sin embargo, el desarrollo vertiginoso, propio del ámbito de las Ciencias de la Computación, requiere que se adopten estrategias propias que permitan atender las demandas de actualización de los planes y programas de estudio y que bajo las restricciones propias institucionales para oficializar tales cambios, se puedan realizar en la práctica y permitan atender adecuadamente las necesidades de preparación actualizada de nuestros estudiantes.

En particular, en nuestra comunidad se han adoptado un conjunto de

estrategias que pretenden atender los retos anteriores, entre las cuales, se pueden citar las siguientes:

-Incorporar, dentro de los planes y programas de estudio, asignaturas con programas abiertos que permitan introducir tópicos selectos correspondientes al desarrollo de las Ciencias de la Computación.

-Contemplar, dentro de los planes y programas de estudio, un conjunto de materias electivas, con programas que permitan la especialización y actualización en las diversas líneas del conocimiento de las Ciencias de la Computación.

-Promover la participación de los profesores en diversas actividades de actualización disciplinaria, profesional y docente. Tales como su incorporación a programas de especialización, de diplomado y de certificación profesional, entre otros.

-Promover el desarrollo o la incorporación del personal docente en diversos proyectos de investigación de las diferentes áreas de las Ciencias de la Computación así como su participación activa en los diversos eventos y foros académicos especializados y de relevancia tanto a nivel nacional como internacional.

5

En este contexto, en el presente periodo de verano y como parte de los

trabajos del personal docente del área de Bases de Datos e Ingeniería de Software de la Facultad de Ciencias de la Computación, se ha organizado el seminario del área, en el cual se ha propuesto como objetivo fundamental lograr unificar los materiales, métodos, estrategias y técnicas en la enseñanza de las asignaturas del área. Lo cual lleve por una parte a preparar los elementos necesarios para poder enfrentar las futuras actualizaciones de los programas de estudio, que de acuerdo a los lineamientos institucionales y propios del desarrollo de la educación, deberán de tener un enfoque orientado al desarrollo de

competencias. Y por otra, integrar elementos necesarios para conformar a mediano plazo nuestro repositorio de objetos de aprendizaje para las diversas asignaturas del área.

Asimismo y con base en el planteamiento realizado en la primera sesión de los trabajos del seminario del área, se abordaron los contenidos de las primeras unidades del programa de la asignatura de “Ingeniería de Software” correspondiente a los Planes y Programas de Estudio de los Programas de Licenciatura e Ingeniería de la Facultad.

En el presente texto, se reportan los resultados de los trabajos desarrollados en el citado seminario, las experiencias compartidas y principalmente el conjunto de actividades propuestas por cada uno de los profesores participantes.

Para cada uno de los temas desarrollados se ha propuesto adoptar el siguiente tipo de esquema de trabajo, en este caso correspondiente al tema de “Antecedentes y Conceptos básicos de la Ingeniería de Software”

2. Antecedentes y Conceptos básicos de la Ingeniería de Software.

2.1 Propuesta de actividades de motivación y diagnóstica para el estudio de

la Ingeniería de Software.

2.2 Planeación didáctica de los antecedentes y conceptos básicos de la

Ingeniería de Software.

2.3 Desarrollo de las actividades de antecedentes y conceptos básicos de

la Ingeniería de Software.

2.3.1 Conceptos y términos de la Ingeniería de Software.

2.3.2 Antecedentes de la Ingeniería de Software.

2.3.3 El Concepto de Ingeniería de Software.

2.3.4 Factores de Calidad del Software.

6

2.4 Comentarios, Conclusiones y Actividades Complementarias sobre los

antecedentes y conceptos básicos de la Ingeniería de Software.

2.5 Referencias capítulo 2.

De acuerdo al esquema de trabajo anterior, el presente texto, consta de seis capítulos. Con el propósito de establecer un antecedente al marco de trabajo adoptado para el presente texto, en el capítulo 1 se presenta un panorama general sobre los antecedentes y conceptos de Planeación Didáctica. En el capítulo 2, se revisan los antecedentes, conceptos y términos de la Ingeniería de Software. El ciclo de vida y las etapas del proceso de desarrollo de un proyecto de software, se aborda en el capítulo 3. En el Capítulo 4, se revisan los modelos Desarrollo Rápido de Aplicaciones y de Métodos Formales. La tecnología CASE (Ingeniería de Software Asistida por Computadora) se revisa en el Capítulo 5. Finalmente y como parte de las tendencias en el desarrollo de la Ingeniería de Software, en el capítulo 6, se presentan los modelos ágiles de Procesos.

Expreso mi reconocimiento y agradecimiento a cada uno de los profesores

participantes en estos trabajos, sin duda alguna, sus valiosas experiencias en el

ejercicio docente y profesional, reflejadas en este documento, establecen ya un

precedente y referencia para la organización y mejora de la calidad de los trabajos

académicos en nuestra Facultad. En particular, agradezco ampliamente la

contribución de la Dra. Etelvina Archundia S., quien nos ha proporcionado la

orientación metodológica para el desarrollo de los mismos.

Así mismo, de manera especial, agradezco al M.C. Martín Estrada Analco y al

Prof. Jose Luis Luna Govea, su trabajo y disposición para realizar la revisión

general de este reporte.

Resalto también el valioso apoyo de las autoridades administrativas tanto a nivel

institucional como de la Facultad que hacen posible la divulgación y oficialización

de los resultados de estos trabajos. A cada uno ellos, expreso mi agradecimiento.

M.C. María del Rocío Boone Rojas. Coordinadora del área de Bases de Datos e Ingeniería de Software

Facultad de Ciencias de la Computación. Otoño 2011

7

Contenido

Portada 1

Página Legal 2

Autores 3

Presentación 4

Capítulo 1 Perspectivas de la Reforma Integral Educativa en México. 10

Etelvina Archundia Sierra, María del Carmen Cerón Garnica. 1.1 Comentarios sobre el Proyecto Tuning en América Latina. 12 1.2 Experiencias en Espacios Comunes en México ECOES. 13

1.2.1Planeación didáctica en la Educación Superior 13 1.2.2 Actividades de aprendizaje 14

1.3 Evaluación sumativa y formativa 15 1.4 Referencias Capítulo 1 16

Capítulo 2 Antecedentes y Conceptos Básicos de la Ingeniería de Software. 17

Etelvina Archundia Sierra, María del Rocío Boone Rojas.

2.1 Propuesta de actividades de motivación y diagnóstico para el estudio de la Ingeniería de Software.

18

2.2 Planeación didáctica de los antecedentes y conceptos básicos de la Ingeniería de Software. 19 2.3 Desarrollo de las actividades de antecedentes y conceptos básicos de la Ingeniería de Software.

21

2.3.1 Conceptos y términos de la Ingeniería de Software. 21 2.3.2 Antecedentes de la Ingeniería de Software. 22 2.3.3 El Concepto de Ingeniería de Software. 26 2.3.4Factores de Calidad del Software. 27

2.4 Comentarios, Conclusiones y Actividades Complementarias sobre los antecedentes y conceptos básicos de la Ingeniería de Software.

29

2.5 Referencias Capítulo 2 29

8

Capítulo 3 Ciclo de Vida. 31

Alma Delia Ambrosio Vázquez, Ma. del Consuelo Molina García.

3.1 Propuesta de Actividades de Motivación y Diagnóstico para el Estudio de el Ciclo de vida del software.

32

3.2 Planeación Didáctica de Ciclo de vida en la Ingeniería de Software. 33

3.3 Desarrollo de las Actividades de ciclo de vida del software. 35

3.3.1 Conceptos y Términos de ciclo de vida, las P`s de la Ingeniería de Software. 35

3.4 Comentarios, Conclusiones y Actividades Complementarias del ciclo de vida del software.

40

3.5 Referencias Capítulo 3 41

Capítulo 4 Los Modelos DRA y de Métodos Formales 42 Mario Anzures García, Maya Carrillo Ruiz.

4.1 Planeación Didáctica del Modelo de Desarrollo Rápido de Aplicaciones. 43 4.2 Propuesta de Actividades del Modelo de Desarrollo Rápido de Aplicaciones. 44 4.3 Planeación Didáctica del Modelo de Métodos Formales. 47 4.4 Propuesta de Actividades del Modelo de Métodos Formales. 48 4.5 Referencias Capítulo 4 51

Capítulo 5 Herramientas de Ingeniería de Software Asistida por Computadora. 52

María Josefa Somodevilla García, María de la Concepción Pérez de Celis Herrero,

María del Rocío Boone Rojas.

5.1 Propuesta de actividades de motivación y diagnóstico para el estudio de las Herramientas de la Ingeniería de Software Asistida por Computadora.

53

5.2 Planeación didáctica de los antecedentes y conceptos básicos de las Herramientas de la Ingeniería de Software Asistida por Computadora.

57

5.3 Desarrollo de las actividades de antecedentes y conceptos básicos de las Herramientas de la Ingeniería de Software Asistida por Computadora.

58

5.3.1 El Concepto CASE. 58 5.3.2 Componentes básicos de CASE. 60 5.3.3 Taxonomía de Herramientas CASE. 61 5.3.4 Caso de Estudio. Introducción a una Herramienta de Ingeniería de Software Asistida por Computadora.

66

5.4 Comentarios, Conclusiones y Actividades Complementarias sobre los antecedentes y conceptos básicos de las Herramientas de la Ingeniería de Software Asistida por Computadora.

68

5.5 Referencias Capítulo 5 68

9

Capítulo 6 Modelos Ágiles de Procesos. 70

Josefina Guerrero García, Juan Manuel González Calleros.

6.1 Propuesta de actividades de motivación y diagnóstico para el estudio de modelos ágiles de proceso.

71

6.2 Planeación Didáctica de modelos ágiles de proceso. 74 6.3 Desarrollo de las Actividades de Introducción a los métodos ágiles de la Ingeniería de Software.

75

6.3.1Introducción a los modelos ágiles. 75 6.4 Desarrollo de las actividades de métodos ágiles de la Ingeniería de Software. 81

6.4.1 Programación Extrema [Extreme Programming ( XP)] 81 6.4.2 Metodologías Crystal [CrystalMethodologies (CM)] 85 6.4.3 SCRUM 89

6.5 Comentarios, conclusiones y actividades complementarias sobre los antecedentes y conceptos básicos de la ingeniería de software.

94

6.6 Referencias Capítulo 6 103

10

Capítulo 1

Antecedentes y Conceptos de Planeación Didáctica.

Etelvina Archundia Sierra María del Carmen Cerón Garnica

1. Perspectivas de la Reforma Integral Educativa en México La Secretaría de Educación Pública ha emitido documentos para la formación docente como lo son el desarrollo de proyectos didácticos, los cuales permiten atender diferentes aspectos que se vinculen con los aprendizajes, las relaciones docente/alumno, la organización de actividades y los intereses educativos en general. De esta manera, los proyectos didácticos son entendidos como actividades planificadas que involucran secuencias de acciones y reflexiones coordinadas e interrelacionadas para alcanzar los aprendizajes esperados que, en el caso de la asignatura de español favorecerán el desarrollo de competencias comunicativas. Los proyectos didácticos se conforman de cuatro elementos fundamentales para su desarrollo: propósito, actividades a

desarrollar, productos y evaluación. [1].

Basándose en las investigaciones educativas y el consenso del camino que debe de seguir el sistema educativo mexicano, se han establecido acuerdos para la

11

implementación del enfoque en competencias, el cual incide desde el nivel básico, medio superior y superior, en donde cada nivel contempla las competencias a desarrollar, en el caso del nivel básico se promueve la comunicación y las habilidades del pensamiento como observar, analizar, razonar, aprender y el ser a través de la socialización. En el nivel medio superior se contempla: la comunicación, el pensamiento crítico y creativo, la responsabilidad social y cívica. En la educación superior el estudio de la propia disciplina y su relación con el campo laboral (Véase figura 1).

Figura 1. Competencias a desarrollar de acuerdo a los niveles de estudio Fuente: Elaboración propia de los autores

Con lo anterior se busca la articulación curricular, en el marco de la Reforma Integral de la Educación Básica (RIEB), basándose en el requisito para el cumplimiento del perfil de egreso, lo que implica integrar los niveles de preescolar, primaria y secundaria para que exista consistencia entre las competencias a desarrollar, a fin de sentar las bases para atender las necesidades de la sociedad actual [2].

Hoy la necesidad de educar para la vida demanda múltiples competencias a los maestros, de modo que éstos sean agentes de cambio que contribuyan a elevar los aprendizajes en los niños, en dotarles de herramientas para el pensamiento complejo y para un desarrollo humano pleno e integral, así como competencias cívicas y sociales que contribuyan a que todas las personas gocen de iguales derechos, libertades y oportunidades, así como elevar el bienestar general.

Lo mencionado para la educación básica y media superior se debe de continuar en la educación universitaria en las diversas áreas del conocimiento para desarrollar individuos con capacidades que les permita incidir en el momento actual y sean transformadores de su contexto social. Por lo que la actividad del docente en el proceso de enseñanza aprendizaje requiere de la profesionalización del docente para atender los retos de la educación hoy en día, por lo que el docente universitario debe de ser competente en el dominio de los contenidos de enseñanza del currículo y que desarrolle las capacidades intelectuales de pensamiento abstracto y complejo en los alumnos universitarios. Para el proceso de enseñanza aprendizaje el docente debe de estudiar la forma en la cual planea, el cómo imparte y evalúa sus actividades en el aula. Debe de relacionar en el conocimiento disciplinar los beneficios de las corrientes pedagógicas a través de los estudiosos como los

12

son: Jean Piaget, Bruner, Lev Vigotsky y Gagne; además del uso de recursos de vanguardia como lo son las Tecnologías de Información TIC´s(Véase figura 2).

Figura 2: Esquema aprendizaje para el docente en la impartición de su práctica profesional Fuente: Elaboración propia de los autores

1.1 Comentarios sobre el Proyecto Tuning en América Latina El enfoque en competencias presentado desde las Reflexiones y Perspectivasde la Educación Superioren América Latina en el Informe Final del Proyecto Tuningen América Latina durante los años 2004-2007, muestra las propuestas de las competencias genéricas, disciplinares y laborales en las diversas áreas del conocimiento.

Las competencias genéricas son los criterios generales que se desarrollan durante los procesos de aprendizaje y su autogestión, por ejemplo: la comunicación, aprender a aprender, aprender ser, aprender a hacer (habilidades procedimentales y técnicas).

Las competencias disciplinares se construyen por la integración de los saberes disciplinares y su aplicación contextual en un marco de conciencia social.

La competencias laborales se relacionan con las disciplinares para la formación y desempeño profesional en un puesto laboral, identificando lo que es capaz de realizar, juzgar y la aptitud del poseedor de la competencia.

Cabe mencionar de acuerdo al informe Tuning, la participación de 62 universidades latinoamericanas debatiendo en 4 grupos de trabajo: Administración de Empresas, Educación, Historia y Matemáticas. En un segundo momento, dada la repercusión que alcanzaronlas actividades realizadas en el marco del proyecto y respondiendo a una demanda de los países latinoamericanos, se incorporaron 120 nuevas universidades en 8 áreas del conocimiento: Arquitectura, Derecho, Enfermería, Física, Geología, Ingeniería, Medicina y Química. Estas 182 universidades, provenientes de 18 países de América Latina (Argentina, Brasil, Bolivia, Colombia, Costa Rica, Cuba, Chile, Ecuador, El Salvador, Guatemala, Honduras, México, Nicaragua, Panamá, Paraguay, Perú, Uruguay y Venezuela)[3].

13

1.2 Experiencias en espacios comunes en México Las acciones mencionadas en el Proyecto Tuning se plasman en el Proyecto Experiencias en Espacios Comunes de Educación Superior ECOES, donde participan la Universidad Nacional Autónoma de México UNAM, Instituto Politécnico Nacional IPN y la

Universidad Autónoma de México UAM, propiciando el intercambio y la movilidad estudiantil. La colaboración se da también en la educación a distancia y en el enlace de las bibliotecas digitales [4].

Si bien el compartir experiencias docentes entre las Universidades también deben de crear estrategias que les permita aplicar el enfoque en competencias en la Educación Superior en México por lo que se requiere integrar los estudios realizados a la fecha en un modelo a seguir en los aspectos de: Diseño curricular, formación docente, desarrollo de programas académicos, planeación didáctica, actividades de aprendizaje y evaluación de los programas académicos y curriculares (véase figura 3).

Figura 3. Aspectos a atender en la Educación Superior en México Fuente: Elaboración propia de los autores

1.2.1 Planeación didáctica en la Educación Superior El intercambio de experiencias entre los docentes de distintas Universidades Públicas Mexicanas aportaría en el proceso de enseñanza aprendizaje una oportunidad de enriquecer la práctica docente y generar materiales que permitan aprendizajes basados en problemas y proyectos, al igual que estudios de casos en contextos reales de excelente calidad, lo cual propiciaría en los alumnos, el interés por las asignaturas de los programas académico y un aprecio al esfuerzo docente vislumbrado en el poder hacer para incidir en la sociedad y transformación de la misma (Véase figura 4).

14

Figura 4 Formas de aprendizaje en educación superior Fuente: Elaboración propia de los autores

La planeación didáctica en la Educación Superior requiere en un primer momento de un diagnóstico que nos permita ubicar los conocimientos, experiencias y prácticas que el alumno ha generado en las asignaturas anteriores. En un segundo momento el docente debe despertar el interés y motivación por los nuevos conocimientos, los cuales se contemplan bajo el control del tiempo, los materiales, recursos a utilizar en las actividades de aprendizaje a realizar para alcanzar las competencias establecidas al inicio. Las actividades de aprendizaje requieren la transferencia de las técnicas de aprendizaje y de los conocimiento disciplinares para llevarlas a cabo durante el desarrollo y ejecución en el aula de los contenidos plasmados en los programas académicos. Otro aspecto a considerar es la evaluación de las actividades de aprendizaje y de los objetivos y propósitos plasmados al principio. Las actividades de aprendizaje requieren de los recursos de vanguardia especializados en la educación a través de las Tecnologías de Información y Comunicación TIC´s. 1.2.2 Actividades de aprendizaje Para las actividades de aprendizaje se requiere del estudio de las estrategias y técnicas en la enseñanza, aunado al conocimiento disciplinar de las asignaturas. Por lo que se recomienda utilizar los mapas conceptuales, mapa mental, cuadros sinópticos, esquemas, gráficos, diagramas; también durante las actividades de aprendizaje se sugieren técnicas de dinámicas grupales como el Panel, Philips 6/6, Trabajos en pequeños grupos y debates.

En la planeación didáctica se destacan las actividades desarrolladas en la motivación e interés respecto al tema de estudio y en el desarrollo del mismo (véase figura 5). La actividad inicial motivacional se considera como un diagnóstico a partir de los conocimientos previos del alumno mediante los recursos de un video, el diálogo, texto o

15

•Motivación

•Diagnóstica

Actividad

inicial

• Trabajo en equipo.

• Estudio de casos

• Solución de problemas

• Investigaciones

• Lecturas

Actividad de

desarrollo

•Conclusiones

•Evaluación

Cierre

una imagen. En este momento el clima de confianza en el aula propicia un medio de investigación e interés por parte del alumno respecto del tema. Para las actividadesen el desarrollo del tema se considera la búsqueda de los conocimientos disciplinarios del tema de diversas fuentes, a partir de datos, investigaciones, solución de problemas y estudio de casos.

Figura 5. Actividades de inicio y desarrollo en la Planeación didáctica Fuente. Elaboración propia de los autores

En el proceso de desarrollo el docente debe pensar en la organización de las

actividades a través de equipos de trabajo y de prácticas de procesos constructivistas para enriquecer el proceso cognitivo de aprendizaje.

Posterior a las actividades de desarrollo las conclusiones y cierre donde el alumno extrae y concreta lo aprendido en el cambio y transformación de los conocimientos previos a los nuevos. El pensamiento analógico, crítico y reflexivo representa la funcionalidad del aprendizaje del tema establecido [5]. 1.3 Evaluación sumativa y formativa La evaluación de los aprendizajes es un proceso complejo puesto que considera la implicación de diversas variables presentes en el aula como lo es la relación entre el docente-alumno, las evidencias del aprendizaje, la relación entre los alumnos, los recursos, las estrategias de aprendizaje aplicadas y la planeación didáctica. Cuando el docente integra las dimensiones mencionada debe de contemplar que la evaluación se puede dar en lo aprendido del tema, de la asignatura y lo que trasciende en el alumno para continuar con el aprendizaje en su práctica profesional. A continuación se presentan los dos tipos de evaluación esenciales a considerar en el proceso de aprendizaje: la evaluación sumativa y la formativa.

La evaluación sumativa debe de ser coherente con las actividades de aprendizaje establecidas durante el desarrollo de la Planeación didáctica. La evaluación sumativa se

16

puede establecer mediante rúbricas, enseñanza asistida por el grupo, lista de cotejo o nota técnica.

En la evaluación formativa el docente deberá crear una guía que permita al alumno

integrar sus conocimientos, habilidades y actitudes en la solución de problemas disciplinares y aprendizaje basado en proyectos. El docente establecerá los tiempos de revisión y de rúbricas que le permita al alumno conocer su progreso y retroalimentación. El ambiente que se propicia en la evaluación formativa es de confianza y logros, permitiendo al alumno el pensamiento creativo para la innovación. 1.4 Referencias Capítulo 1 [1] Secretaría de Educación Pública, (2009) Programas de estudio 2009. Primer grado. Educación básica. Primaria, Segunda edición, 2009, Primera reimpresión, 2010, D. R. © México, DF pág. 31. [2] Curso Básico de Formación Continua para Maestros en Servicio, Planeación didáctica para el desarrollo de competencias en el aula 2010 fue elaborado en la Dirección General de Formación Continua de Maestros en Servicio de la Subsecretaría de Educación Básica, de la Secretaría de Educación Pública. [3] Reflexiones y perspectivas de la Educación Superior en América Latina. Informe Final – Proyecto Tuning – América Latina. 2004-2007.Tuning – América Latina: http://tuning.unideusto.org/tuningal [4] Rositas, J. y Torres, G. Diseño de planes educativos bajo un enfoque de competencias. Ed. Trillas, México, 2011. [5] García, A. y Gómez, E. Notas del Diplomado en Planeación y organización de secuencias e intervención didácticas en torno a aprendizajes cognitivos, BUAP. México, Puebla, 2011

17

Capítulo 2

Antecedentes y Conceptos Básicos de la Ingeniería de Software.

Etelvina Archundia Sierra María del Rocío Boone Rojas

Introducción

Los programas de estudio en computación cuentan, actualmente, con la asignatura de Ingeniería de Software. Los docentes que imparten la asignatura están convencidos de que a los alumnos se les debe motivar el interés por conocer y practicar las metodologías para el desarrollo de sistemas de calidad en computación.

Para que el alumno se interese en el estudio de la Ingeniería de Software el docente deberá realizar una planificación docente para que el alumno comprenda: Cuál es el objeto de su estudio y por lo tanto, la necesidad de aprender su aplicación en el campo de desarrollo de sistemas de cómputo de calidad.

18

Los aspectos que debe identificar el alumno son: el ingenio del sujeto capaz de

transformar mediante la Ingeniería de Software, sistemas de cómputo de calidad al servicio de las personas y de los diversos campos de la sociedad.

En el presente capítulo se propone una serie de actividades de aprendizaje para que el docente pueda desarrollar en su clase los siguientes aspectos:

o Conceptos y términos de la Ingeniería de Software. o Antecedentes de la Ingeniería de Software. o El Concepto de Ingeniería de Software. o Factores de Calidad del Software.

2.1 Propuesta de Actividades de Motivación y Diagnóstico para el Estudio de la Ingeniería de Software.

Actividades Propuestas. Actividad 1 Objetivo. Que el alumno identifique, a priori, algunas de las actividades y ventajas inherentes a la Ingeniería de Software. Especificaciones. E1) Selecciona un producto de programación que hayas desarrollado en un curso anterior. Ejemplo de Resultados. Programa para el curso de algoritmos y estructuras de datos. Profesor. M.C. Marco Antonio Soriano Ulloa. E2) Resuelve el siguiente cuestionario: 1.-Proporciona una lista de, al menos, tres especificaciones de requisitos establecidos por el profesor. Ejemplo de Resultados. Requisito1.

19

Programa que encuentre los caminos de costo mínimo que hay entre cada par de nodos de una digráfica pesada. Requisito 2. Considerar como datos de entrada: n – número de nodos. N – conjunto de nodos. R – conjunto de arcos. P – pesos asignados a cada arco. Requisito 3. Utilizar el algoritmo de Dijkstra. 2.- ¿Consideras que el producto que desarrollaste se apegó a los requisitos establecidos? ¿ Por qué? Ejemplo de Resultados. - Al principio no entendí el problema. - Los resultados fueron incorrectos. 3.- ¿Cumpliste en tiempo y forma, con la fecha de entrega? Justifica tu respuesta. Ejemplo de Resultados. -Sí se entregó en la fecha establecida pero no era exactamente lo que pidió el profesor. 4.- ¿El tiempo establecido de desarrollo fue suficiente? Justifica tu respuesta. Ejemplo de Resultados. -El tiempo sí fue suficiente, pero faltó organizar actividades personales. 5.-Indica, por lo menos, dos aspectos del proceso de desarrollo de tu proyecto que se podrían mejorar. Ejemplo de Resultados. Realizar una mejor planeación de mis actividades. -Interactuar con el profesor para aclarar los requisitos. Recursos. R1) Producto de Programación desarrollado previamente, de preferencia en un lenguaje de alto nivel.

2.2 Planeación Didáctica de los Antecedentes y Conceptos Básicos de la Ingeniería de Software.

20

Tiempo. Se propone cubrir el tema en un intervalo de 4 hrs. Contenido. 1. Conceptos y Términos de la Ingeniería de Software. 2. Antecedentes de la Ingeniería de Software. 3. El Concepto de Ingeniería de Software. 4. Factores de Calidad del Software.

Materiales.

Referencias Bibliográficas.

[1] Fairley Ingenierìa de Software. Prentice Hall. IEEE Trans. on Software Engineering. [2] Capítulo 1 Pressman Roger S. Ingeniería de Software, Un Enfoque Práctico. Mc Graw Hill.

[3] Capítulo 1 IanSommerville. Ingeniería de Software Addison Wesley. Recursos Electrónicos. [4] Gabriel Buades Rubio. “Concepto de Calidad” Ingeniería de Software III Depto. De Ciencias Matemáticas e Informática. Universidad de las Islas Balares http://dmi.uib.es/~bbuades/calidad/sld016.htm Consulta: Junio 2011

[5] Xavier Ferré Grau “Principios Básicos de Usabilidad para Ingenieros Software”

21

Facultad de Informática Universidad Politécnica de Madrid http://is.ls.fi.upm.es/miembros/xavier/papers/usabilidad.pdf Consulta: Junio 2011 [6] Moisés Rodríguez Monje “Calidad de Procesos y Productos Software, ISO/IEC 25000” Alarcos Quality Center http://alarcos.inf-cr.uclm.es/per/fruiz/cur/santander/mrodriguez-iso25000-update.pdf Consulta: Junio 2011

2.3 Desarrollo de las Actividades de Antecedentes y Conceptos Básicos de la Ingeniería de Software.

2.3.1 Conceptos y Términos de la Ingeniería de Software. Material de Referencia. De Pressman [2] se incluye el siguiente material:

Ingeniería. Profesión que posee conocimientos científicos, actividades y criterios (ingenio) para crear dispositivos, métodos y sistemas para transformar los recursos y satisfacer mejor las necesidades de una sociedad.

Software. Conjunto de programas que se pueden ejecutar en una computadora, así como toda la

información, utilerías y recursos necesarios para su diseño, instalación, operación, mantenimiento y refinamiento.

Ingeniería de Software.

Disciplina que establece el uso de principios de ingeniería robustos, orientados a obtener software económico que sea confiable y funcione de manera eficiente.

Perfil del Ingeniero de Software.

Debe ser capaz de encabezar o ser miembro de grupos multidisciplinarios de desarrollo de de todo tipo de software y que en equipo logre producir software de alta calidad.

Diferencia entre programador e Ingeniero de Software.

La Ingeniería de Software difiere de la programación tradicional en que se utilizan técnicas de ingeniería para especificar, diseñar, codificar, validar y mantener los productos dentro del tiempo y presupuesto establecidos para el proyecto. Además, la ingeniería se preocupa por aspectos administrativos que quedan fuera del dominio normal de la programación. El término programador se emplea para denominar a la persona preocupada y abocada a las tareas y detalles de la codificación, empacado y modificación de los algoritmos y estructuras de datos codificados en algún lenguaje de programación particular. Los Ingenieros de Software están, además, capacitados para hacer frente a aspectos de análisis, diseño, verificación, prueba de programas, documentación, mantenimiento y administración del proyecto.

22

Actividades Propuestas. Actividad 1 Objetivo. Que el alumno identifique los términos y conceptos elementales de la Ingeniería de software. Especificación. E1) Revisa las referencias [1] y [2], y realiza tu propia investigación sobre los conceptos y términos de la ingeniería de software. -Elabora un mapa conceptual que involucre los principales términos y conceptos de la ingeniería de software. Ejemplo tipo de Resultados. (Ver mapa conceptual en Programa de curso de la asignatura de Ingeniería de Software, Modelo MUM). Recursos. R1) Referencias [1] y [2] R2) Conexión a Internet.

2.3.2 Antecedentes de la Ingeniería de Software. Material de Referencia.

Recomendación: Revisar Refs. [1] y [2]. A continuación se incluye material de Pressman [2]:

23

La “Crisis del Software” se denomina una etapa en la que todos los programas desarrollados, se corregían cuando había fallos o eran modificados debido a necesidades cambiantes, y que requerían de grandes esfuerzos para mantenerlos, con un costo mayor, a medida que la complejidad del software crecía.

En las pasadas décadas los ejecutivos y desarrolladores se hacían las siguientes preguntas: ¿Por qué lleva tanto tiempo terminar los programas? ¿Por qué es tan elevado el costo? ¿Por qué no podemos detectar los errores antes de entregar el software a los clientes? ¿Por qué resulta tan difícil constatar el progreso del desarrollo del software?

Estas y otras preguntas manifiestan el carácter del software y la forma en que se desarrolla, estos problemas hacen necesaria la adopción de técnicas de Ingeniería de Software. El software es ahora la clave del éxito de muchos de los sistemas basados en computadora. El software marca la diferencia. Lo que diferencia una compañía de otra, es la suficiencia, exactitud y oportunidad de la información proporcionada por el software.

24

Ejemplo de la importancia del software: Dos consultorios dentales; ambos cuentan con los últimos modelos de computadoras personales destinadas a apoyar las tareas y actividades relacionadas con el consultorio. Sólo que uno de ellos, cuenta con un dispositivo especial conectado a la computadora y con un Software para obtener radiografías de piezas dentales por computadora. En un par de minutos la muestra radiográfica está en pantalla y el médico puede obtener diferentes vistas de la placa usando este software. Además, puede establecer una conexión a través de internet o vía modem, para enviar el archivo de la radiografía a otro colega experto, con el fin de consultar y apoyar el diagnostico, todo ello en la misma cita. En la forma tradicional la placa radiográfica estaría lista en un par de días.

El desarrollo de software se ha convertido en una industria con crecimiento vertical en los últimos años, hoy por hoy uno de los hombres más ricos del mundo es el dueño de una casa de software, Microsoft. Hace un par de décadas se sostenía la teoría de que los países que poseían los mejores recursos naturales estaban destinados a ser los más ricos y poderosos del mundo, en México por ejemplo, se manejó la idea de que el petróleo era la gran puerta de entrada al mundo desarrollado. Indudablemente los recursos naturales tienen un papel importante en la economía de los países, sin embargo, poco a poco se fue acuñando una nueva ideología que se sintetiza en lo siguiente: Aquél que posee la información y el conocimiento y hace mejor uso de él, es el que tiene el poder.

Problemas del software.

• La planificación y estimación de costos frecuentemente son imprecisas. • Falta de productividad en la comunidad de software • La calidad del software, a veces, es inaceptable.

Estos problemas al final crean insatisfacción y falta de confianza por parte de los clientes. Los problemas anteriores son sólo manifestación de otras dificultades:

• No tenemos tiempo de recoger datos sobre el proceso de desarrollo del software. • Los proyectos de desarrollo de software se llevan a cabo con sólo una vaga

indicación de los requisitos del cliente. • La calidad del software es normalmente cuestionable. • El mantenimiento de software es muy costoso y no se le ha considerado un aspecto

importante.

Los problemas anteriores son corregibles, la clave es: Dar un enfoque de ingeniería al desarrollo de software.

25

Actividades Propuestas. Actividad 1 Objetivo. Que el alumno identifique el tipo de productos de software desarrollados a partir de la segunda generación de computadoras, cuyo tamaño y complejidad resultó imposible de manejar sin una metodología adecuada. Especificación. -Revisar el Cap.1 de las refs. [1] y [2]. -Proporcionar una lista de los tipos de productos de software que se desarrollaron a partir de la segunda generación de computadoras. Ejemplo de Resultados. -Sistemas de tiempo compartido. -Sistemas con multiprogramación. -Sistemas multitarea. Recursos. R1) Referencias [1] y [2] Actividad 2 Objetivo. Que el alumno identifique los problemas que surgen cuando los productos de software se desarrollan sin el enfoque de la ingeniería de software. Especificación. -Revisar el Cap.1 de las refs. [1] y [2]. (Ver II Planeación, Materiales.) -Proporcionar una lista de los problemas que surgieron durante el desarrollo de los productos de programación durante la etapa llamada “crisis del software.” Ejemplo de Resultados. -El Producto se entregó fuera de tiempo. -El producto no corresponde a los requisitos especificados por el cliente. -Algunas de las opciones del producto NO funcionan o bien, fallan.

26

Recursos. R1) Referencias [1] y[2]

2.3.3 El Concepto de Ingeniería de Software. Material de Referencia.

Ref.[1]. En [1] se incluyen algunas definiciones de la Ingeniería de Software: Definición 1 Ingeniería de Software es el estudio de los principios y metodologías para desarrollo y mantenimiento de sistemas de software [Zelkovitz, 1978] Definición 2 Ingeniería del Software es la aplicación práctica del conocimiento científico en el diseño y construcción de programas de computadora, así como de la documentación asociada, requerida para desarrollar, operar (funcionar) y mantenerlos. Se conoce también como desarrollo de software o producción de software [Bohem, 1976] ' Definición 3 Ingeniería del Software trata del establecimiento de principios y métodos de ingeniería, con el fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales [Bauer,1972]. Definición 4 La aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación (funcionamiento) y mantenimiento del software; es decir, la aplicación de ingeniería al software. 2. El estudio de enfoques como en (1) [IEEE, 1993]. ZELKOVITZ, M. V., SHAW, A. C. y GANNON, J. D.: Principles of Software Engineering and Design. Prentice-Hall, EnglewoodsClif, 1979. BOEHM, B. W.: Software Engineering., IEEE Transactions on Computers, C-25, núm. 12, pp. 1226-1241. BAUER, F. L.: Software Engineering, Information Processing, 71, North Holland Publishing Co., Amsterdarn, 1972 IEEE: Standards Collection: Software Engineering, IEEE Standard 610.12-1990, IEEE, 1993.

27

Actividades Propuestas. Actividad 1 Objetivo: Identificar los conceptos clave asociados a la Ingeniería de Software. Especificación. E1) Realizar una revisión y análisis grupal de las diferentes definiciones de ingeniería de software presentadas previamente. En cada caso, señalar los conceptos clave que se resaltan en cada una de ellas. Recursos. R1) Ref.[2].

2.3.4 Factores de Calidad del Software. Material de Referencia. -Concepto de Calidad. [4], [2], [6], [7] -Factores de Calidad Estructurales y Derivados. [4] -Descripción de Factores.

[1], Cap. 18 y en [4] y [5].

Actividad 1 Objetivo. Que el alumno identifique atributos de calidad en un producto de Programación. Especificación. E1) Selecciona un producto de programación que hayas desarrollado en un curso anterior. E2) Identifica tres factores de calidad que consideres se le pueden atribuir a tu producto. Justifica tu respuesta. Ejemplo de Tipo de Resultados. Es portable, porque se desarrolló en Java, el cual tiene una máquina virtual. Recursos.

28

R1) Referencias [4] y [5]. R2) Un producto de programación desarrollado previamente, de preferencia en un lenguaje de programación de alto nivel. R3) Conexión a Internet.

Actividad 2 Objetivo. Que el alumno identifique que es posible mejorar la calidad de sus productos de programación. Especificaciones. E1) Desde el punto de vista del programador, indica al menos tres características de tu producto de programación que consideres se podrían mejorar. Ejemplo de Resultados. -Utilizar estructuras de datos dinámicas para la implementación de los archivos indizados. E2) Desde el punto de vista del usuario, indica al menos tres características de tu producto de programación que consideres se podrían mejorar. Ejemplo de Resultados. -Mejorar la interfaz del usuario. -Dar más opciones para generar otro tipo de reportes.

Recursos. R1) Referencias [6] y [7]. R2) Un producto de programación desarrollado previamente, de preferencia en un lenguaje de programación de alto nivel. R3) Conexión a Internet. Actividad 3 Objetivo. Que el alumno conozca que existen herramientas para evaluar factores de calidad de software y que pueden ser de diferentes tipos. (En un siguiente capítulo, “Métricas”, se espera que sea capaz de experimentar con al menos una de ellas). Especificaciones. E1) Realiza una búsqueda por Internet y desarrolla una breve documentación sobre tres herramientas para evaluar factores de calidad de un producto de software. Incluye al menos los siguientes aspectos: Nombre.

29

Empresa. Propósito.

Puedes organizar tus resultados en una tabla.

Ejemplo de Tipo de Resultados. Nombre. KEMIS“Kybele Environment Mesaurement Information System” Empresa.KybeleConsulting. Propósito. Facilitar la medición automatizada de la calidad de los productos software. Ej. Factores relacionados con capacidad de un producto para ser probado, de soportar actualizaciones. Recursos. R1) Conexión a internet. R2) Referencias disponibles en [6].

2.4 Comentarios, Conclusiones y Actividades Complementarias sobre los Antecedentes y Conceptos Básicos de la Ingeniería de Software.

Se propone realizar una actividad grupal de análisis y reflexión, relacionada con las siguientes cuestiones. -¿Cuál es el objetivo fundamental de la Ingeniería de software? -¿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? 2.5 Referencias Capítulo 2 [1] Fairley Ingenierìa de Software. Prentice Hall. IEEE Trans. on Software Engineering. [2] Capítulo 1

30

Pressman Roger S. Ingeniería de Software, Un Enfoque Práctico. Mc Graw Hill.

[3] Capítulo 1 IanSommerville. Ingeniería de Software Addison Wesley. Recursos Electrónicos. [4] Gabriel Buades Rubio. “Concepto de Calidad” Ingeniería de Software III Depto. De Ciencias Matemáticas e Informática. Universidad de las Islas Balares http://dmi.uib.es/~bbuades/calidad/sld016.htm Consulta: Junio 2011

[5] Xavier Ferré Grau “Principios Básicos de Usabilidad para Ingenieros Software” Facultad de Informática Universidad Politécnica de Madrid http://is.ls.fi.upm.es/miembros/xavier/papers/usabilidad.pdf Consulta: Junio 2011 [6] Moisés Rodríguez Monje “Calidad de Procesos y Productos Software, ISO/IEC 25000” Alarcos Quality Center http://alarcos.inf-cr.uclm.es/per/fruiz/cur/santander/mrodriguez-iso25000-update.pdf Consulta: Junio 2011 [7] http://www.iso.org

31

Capítulo 3 Ciclo de Vida.

Alma Delia Ambrosio Vázquez Ma. del Consuelo Molina García

Introducción

Un modelo de ciclo de vida define el estado de las fases a través de las cuales se lleva un proyecto de desarrollo de software, este proceso es parte de la calidad del software que un ingeniero de software debe aplicar y al cual debe dar seguimiento.

32

Uno de los objetivos de la asignatura de ingeniería de software, es conseguir que el alumno conozca el concepto de calidad del software, que comprenda, conozca y valore la importancia del uso de metodologías de la ingeniería de software, así como de que le confiera un seguimiento durante todo el ciclo de vida del software.

Tomando en cuenta que la Ingeniería de Software es el resultado de llevar la tradicional disciplina de las ingenierías al mundo de la construcción de sistemas de software es necesario el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software así como de las personas que se involucran en ello. Por las razones expuestas, el objetivo del presente trabajo es realizar una intervención didáctica, que planifique las tareas de aprendizaje en los temas involucrados. En el presente capítulo se propone una serie de actividades de aprendizaje para que el docente pueda desarrollar en su clase los siguientes aspectos:

o Paradigmas de Programación o Las 4 P`s de la Ingeniería de software (Proceso, Producto, Proyecto y

Personas) o Metodologías de la Ingeniería de software o Ciclo de vida del software.

3.1 Propuesta de Actividades de Motivación y Diagnóstico para el Estudio del Ciclo de vida del software .

Dentro de las actividades diagnósticas en esta materia, es trascendental que el alumno conozca las conceptos básicos como paradigmas de programación, las 4 P’s de la Ingeniería de Software, Ciclo de Vida, Modelo, Metodología, Calidad del Software, Planeación y Administración de Proyectos, Factibilidad, Viabilidad, Prototipos, y la Certificación de Procesos.

Actividades Propuestas. Actividad 1 Objetivo. Que el alumno identifique las ventajas de aplicar las metodologías de la ingeniería de software.

33

Especificaciones. E1) Que el alumno realice una investigación sobre el conjunto de métodos, técnicas y herramientas relacionadas con las metodologías de desarrollo de software. E2) Que el alumno realice una investigación sobre las diferencias en los paradigmas de programación. E3) Con base en un análisis crítico-objetivo el alumno basado en un andamiaje, resuma las condiciones apropiadas para la aplicación de metodologías de la Ingeniería de Software estructurada u orientada hacia objetos. E4) Resuelva el siguiente cuestionario: 1. ¿Cuáles son las cuatro componentes P de la ingeniería de software? 2. ¿Qué es el proceso en cascada? 3. ¿Qué estándares existen para documentación? 4.-Establezca las diferencias entre aplicar, o no, una metodología de la Ingeniería de Software en el desarrollo de software. Justifica tu respuesta. Recursos. R1) Consultar bibliografía.

3.2 Planeación Didáctica de Ciclo de vida en la Ingeniería de Software. Tiempo. Se propone cubrir el tema en un intervalo de 4 hrs. Contenido.

• Paradigmas de Programación

• Las 4 P`s de la Ingeniería de software

• Metodologías de la ingeniería de software

34

• Ciclo de vida del software.

Materiales. Referencias Bibliográficas. [1] Capítulo 1 Braude Ingeniería de Software Una perspectiva orientada a objetos Alfaomega 2003 IEEE Trans. on Software Engineering. [2] Capítulo 1 Pressman Roger S. Ingeniería del Software, Un Enfoque Práctico. Mc Graw Hill. [3] Capítulo 1 Ian Sommerville. Ingeniería de Software Addison Wesley. Recursos Electrónicos. [4] Gabriel Buades Rubio. “Concepto de Calidad” Ingeniería de Software III Depto. De Ciencias Matemáticas e Informática. Universidad de las Islas Balares http://dmi.uib.es/~bbuades/calidad/sld016.htm Consulta: Junio 2011 [5] Xavier Ferré Grau “Principios Básicos de Usabilidad para Ingenieros Software” Facultad de Informática Universidad Politécnica de Madrid http://is.ls.fi.upm.es/miembros/xavier/papers/usabilidad.pdf Consulta: Junio 2011 [6] Moisés Rodríguez Monje “Calidad de Procesos y Productos Software, ISO/IEC 25000” Alarcos Quality Center

35

http://alarcos.inf-cr.uclm.es/per/fruiz/cur/santander/mrodriguez-iso25000-update.pdf Consulta: Junio 2011

3.3 Desarrollo de las Actividades de ciclo de vida del software

3.3.1 Conceptos y Términos de ciclo de vida, las P`s de la Ingeniería de Software. Material de Referencia. De Braude [1] se incluye el siguiente material:

Ciclo de Vida

• El ciclo de vida de desarrollo de sistemas informáticos puede dividirse en actividades o fases que, en general, se ajustan al esquema mostrado en el gráfico. Este esquema gráfico es el ciclo de vida típico, dado que existen gran cantidad de variantes que dependen de la organización, del tipo de sistema que se realizará, de los gustos de los administradores, de los tiempos, etc. Las actividades típicas del ciclo de vida son: 1- Estudio de factibilidad. 2- Análisis (de requerimientos). 3- Diseño 4.1- Creación de prototipos 4.2- Implementación 5 - Validación y prueba 6 - Operación y mantenimiento

36

La Ingeniería de Software es el resultado de llevar la tradicional disciplina de las ingenierías al mundo de la construcción de sistemas de software. Es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software.

Los desafios de la Ingenieria de Software son:

La Ing. Sw es una tecnología estratificada

• Enfoque de calidad – La IS debe estar sustentada en un compromiso con la calidad (Gestión de

Calidad Total, Sigma Seis, etc.) que fomente una cultura de mejora continua del proceso.

37

• Procesos – Define un marco de trabajo que debe establecerse para la entrega efectiva, la

gestión de proyectos, el contexto en el cual se aplican los métodos técnicos, se generan los productos del trabajo, se establecen los fundamentos, se asegura la calidad y el manejo adecuado de cambios

• Métodos: – Definen los “cómo” para construir el software desde el punto de vista

técnico. • Herramientas:

– Proporcionan un soporte automático o semi-automático para los métodos. Herramientas CASE

• Métodos: – Planificación y estimación de proyectos. – Análisis de requisitos. – Diseño. – Codificación. – Pruebas. – Mantenimiento.

• Herramientas: – CASE. – CAD, ...

• Procesos. – PSP – TSP – CMMi…..

¿Qué es un proceso?

Define un marco de trabajo que forma la base del control de gestión de proyectos de SW y establecen el contexto en que se aplican los métodos técnicos, se producen los resultados del trabajo, se asegura la calidad, etc

• Los métodos: Indican cómo construir técnicamente el SW. Las tareas que incluye son:

– Análisis de requisitos. – Diseño (estructuras de datos, arquitectura de programación y procedimientos

algorítmicos). – Pruebas. – Mantenimiento.

• Procedimientos: Relacionan métodos y herramientas desde un punto de vista formal. Entre otras cosas, se define la secuencia en que se aplican los métodos

38

Las Cuatro p`s de la Ingenieria de Software

Actividades del Ingeniero del SW • Dependencias profundas entre los ejes:

– No se puede ser un buen diseñador sin saber de tecnologías – No se puede diseñar el proceso sin tener en cuenta la Arquitectura – El proceso tiene que ir apoyado por metodologías – No se puede ser un buen director de proyecto sin saber del resto – No se puede ser un buen arquitecto sin saber de tecnología – No basta con saber de tecnología para ser un buen arquitecto – ….

Trabajo en equipo de desarrollo de software de paradigma estructurado y orientado

a objetos. Actividades Propuestas. Actividad 1 Objetivo. Que el alumno conozca los conceptos básicos relacionados con el ciclo de vida de la Ingeniería de software. Especificación. E1) Revisar las referencias [1], [2] y [3] para realizar una investigación sobre los conceptos y términos de ciclo de vida. -Elaborar un mapa conceptual que represente las metodologías de la ingeniería de software.

39

Ejemplo tipo de Resultados. (Ver mapa conceptual en Programa de curso de la asignatura de Ingeniería de Software). Recursos. R1) Referencias [1] y [2] R2) Conexión a Internet. Actividad 2 Objetivo. Comprender los conceptos básicos de la Ingeniería de software Especificación. E1) Revisar las referencias [1], [2] y [3]

1. Se expone por parte del profesor los conceptos básicos de Ingeniería de Software Proceso, Producto, Personas, Proyecto, Modelo y Metodología.

2. Se reproducirá el video de Apolo 13 a partir de la escena 8 donde inicia el problema

de bióxido de carbono y en tierra se dan instrucciones a un equipo que trabaje con el material a disposición de la tripulación a fin de hacer algo para solucionar el problema.

3. Los estudiantes se reúnen en equipos comentan el video examinado y cada equipo se le entregan unas preguntas tales como:

¿Es importante el proceso para la solución de un problema? ¿La organización del equipo de trabajo ayuda a la solución? ¿Es importante trabajar con roles? ¿Qué estrategia siguieron en el video para solucionar el problema?

4. Un alumno de cada equipo, podrá ser elegido al azar para presentar y justificar ante el grupo las respuestas

5. Por último, se entregará a cada alumno una prueba de verificación del aprendizaje de los conceptos vistos y comentados en clase.

Ejemplo tipo de Resultados. (Ver mapa conceptual en Programa de curso de la asignatura de Ingeniería de Software). Recursos. R1) Referencias [1] y [2]

40

R2)Video, Laptop, cañón, plumones, pizarrón, resumen de la clase y prueba de verificación del aprendizaje

Distribución de tiempo 25 min. Inicio de la clase (Introducción al conocimiento) Exposición por el profesor 35 min. Ver las escenas del video 10 min. Actividad de cada uno de los equipos genera respuestas. 20 min. Presentación de resultados por un alumno de cada equipo 10 min. Realizar la prueba de verificación de conceptos aprendidos 10 min. Conclusiones Total 1 hr. 50 min.

3.4 Comentarios, Conclusiones y Actividades Complementarias del Ciclo de Vida del Software.

En esta etapa el alumno tendrá claro el concepto y la importancia de generar software de Calidad.El alumno conocerá la existencia de varios modelos de ciclo de vida a aplicar de acuerdo a sus características durante el desarrollo de software. Asimismo hará conciencia de la importancia de las P´s de la ingeniería de software.

Se propone realizar una actividad grupal de análisis y reflexión, relacionada con las siguientes cuestiones. - ¿Cuál es la diferencia entre aplicar o no una metodología de la Ingeniería de software? - ¿Para un caso dado, es posible aplicar indistintamente paradigma estructurado u orientado a objetos? - ¿Cómo garantizarías la calidad de tu producto de software?

41

3.5 Referencias Capítulo 3 Referencias Bibliográficas.

[1] Fairley Ingenierìa de Software. Prentice Hall. IEEE Trans. on Software Engineering. [2] Capítulo 1 Pressman Roger S. Ingeniería de Software, Un Enfoque Práctico. Mc Graw Hill.

[3] Capítulo 1 IanSommerville. Ingeniería de Software Addison Wesley.

42

Capítulo 4

Los Modelos DRA y de Métodos Formales

Mario Anzures García Maya Carrillo Ruiz

Introducción Para resolver problemas reales de una empresa, un ingeniero del software o un equipo de ingenieros deben de incorporar una estrategia que a menudo se llama modelo de proceso o paradigma de ingeniería de software. Se selecciona un modelo de proceso para la ingeniería del software de acuerdo a la naturaleza del proyecto y de la aplicación, los métodos y las herramientas que se utilizan, así como los controles y entregas que se requieren. En este capítulo se abordan el modelo de Desarrollo Rápido de Aplicaciones (DRA/RAD) y el Modelo de Métodos Formales.

43

4.1 Planeación Didáctica del Modelo de Desarrollo Rápido de Aplicaciones.

Tiempo. Se propone cubrir el tema en un intervalo de 2 hrs. Contenido.

• Introducción a RAD.

• Definiciones y elementos fundamentales de RAD.

Materiales.

R1) Consultar bibliografía. [1] James Martin

Rapid application development Macmillan Publishing Co., Inc. Indianapolis, IN, USA 1991

[2] Beynon-Davies P.1; Carne C.1; Mackay H.2; Tudhope D. Rapid application development (RAD): an empirical review European Journal of Information Systems, Volume 8, Number 3, 1 Palgrave MacmillanSeptember 1999 , pp. 211-223(13)

[3] Carlo Ghezzi, Mehdi Jazayeri y Dino Mandrioli. Fundamentals of Software Engineering. Prentice Hall International, 1991.

[4] Pressman Roger S.

Ingeniería del Software, Un Enfoque Práctico. Mc Graw Hill.

[5] Ian Sommerville. Ingeniería de Software Addison Wesley.

Recursos Electrónicos. [5] Vídeo tutorial RDA en http://www.youtube.com/watch?v=gPgsKLtwJ68

44

Fig. 4.1 Tutorial RAD

4.2 Propuesta de Actividades del Modelo de Desarrollo Rápido de Aplicaciones.

Actividades Propuestas. Las acciones que se llevarán a cabo tienen como fin incentivar la utilización del modelo DRA. Actividad 1. Objetivo. Estudiar el enfoque DRA. Especificaciones. E1) Que el alumno entienda el modelo DRA Ejemplo de Resultados.

En la formación del alumno es significativo, que éste estudie, comprenda y utilice diversos modelos o metodologías relacionadas con el desarrollo de los diferentes modelos de procesos existentes en la actualidad. Uno de estos es el Modelo de Desarrollo Rápido de Aplicaciones (DRA) o RAD (Rapid Application Development), que es un proceso de desarrollo de software, creado inicialmente por James Martin en

45

1980. El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE, enfatizando un ciclo de desarrollo extremadamente corto utilizando un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un "sistema completamente funcional" dentro de periodos cortos de tiempo.

E2) Que el alumno realice una investigación y redacción de las etapas que comprende el modelo DRA. Ejemplo de Resultados.

� Modelado de gestión: el flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la procesa?

� Modelado de datos: el flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.

� Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario que implemente una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos.

� Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.

� Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.

46

Fig. 4.2 Modelo DRA

E3) Que el alumno realice una investigación sobre las ventajas y desventajas del modelo DRA. Ejemplo de Resultados. Ventajas de RAD

� Comprar puede ahorrar dinero en comparación con construir. � Los entregables pueden ser fácilmente trasladados a otra plataforma. � El desarrollo se realiza a un nivel de abstracción mayor. � Visibilidad temprana. � Mayor flexibilidad. � Menor codificación manual. � Mayor involucramiento de los usuarios. � Posiblemente menos fallas. � Posiblemente menor costo. � Ciclos de desarrollo más pequeños. � Interfaz gráfica estándar.

Desventajas de RAD

� Comprar puede ser más caro que construir.

47

� Costo de herramientas integradas y equipo necesario. � Progreso más difícil de medir. � Menos eficiente. � Menor precisión científica. � Riesgo de revertirse a las prácticas sin control de antaño. � Más fallas. � Prototipos pueden no escalar. � Funciones reducidas (por "timeboxing"). � Dependencia en componentes de terceros.

E3) Con base en un análisis crítico-objetivo el alumno debe resumir las condiciones apropiadas para la aplicación de modelos DRA. RAD se aplica cuando:

� La aplicación funcionará de manera independiente. � Se pueden usar principalmente bibliotecas existentes. � Desempeño no crítico. � Distribución limitada, interna o vertical. � Alcance del proyecto limitado. � Confiabilidad no crítica. � El sistema puede dividirse en muchos módulos independientes. � El producto está dirigido a un mercado altamente especializado. � El proyecto cuenta con fuertes limitantes de tiempos parciales � La tecnología requerida tiene más de un año en el mercado.

E4) Resuelva el siguiente cuestionario: 1. ¿Qué es el Modelo de Desarrollo Rápido de Aplicaciones? 2. ¿Cuáles son las Fases del Modelo del Desarrollo Rápido de Aplicaciones? 3. ¿Mencione algunas de las características del Modelo de Desarrollo rápido de

Aplicaciones? 4. ¿Cuáles son las ventajas del modelo de Desarrollo Rápido de Aplicaciones? 5. ¿Cuáles son las desventajas del modelo de Desarrollo Rápido de Aplicaciones?

4.3 Planeación Didáctica del Modelo de Métodos Formales. Tiempo. Se propone cubrir el tema en un intervalo de 4 hrs.

48

Contenido.

• Introducción

• Modelo de Métodos Formales

• Formalismos matemáticos usados en el Modelo de Métodos Formales

Materiales. Referencias Bibliográficas. [1] Zohar Manna y Richard Waldinger.

The Logical Basis for Computer Programming. Vol 1: Deductive Reasoning.

[2] Helmut Ehrig y Bernd Mahr.

Fundamental of Algebraic Specification. Equations and Initial Semantics. Springer-Verlag 1985.

[3] Z. Manna y A. Pnueli.

The Temporal Logic of Reactiveand Concurrent Systems. [4] L. Lamport y N. Lynch.

Distributed Computing: Models and Methods. Handbook of Theoretical Computer Science. Elsevier Publishers B.V. 1990.

Recursos Electrónicos. [5] Formal Methods

http://www.afm.sbu.ac.uk/

4.4 Propuesta de Actividades del Modelo de Métodos Formales.

Actividades Propuestas. Las acciones que se llevarán a cabo tienen como fin incentivar la utilización del modelo de Métodos Formales.

49

Actividad 1. Objetivo.

Estudiar el modelo de Métodos Formales. Especificaciones. E1) Que el alumno realice una investigación y redacción sobre el modelo de Métodos Formales. Ejemplo de Resultados. Los métodos formales son un conjunto de tendencias de desarrollo de software en donde la especificación, verificación y diseño de componentes se realiza mediante notaciones, lenguajes, herramientas y técnicas basadas en teorías con sólido fundamento matemático completamente funcional" dentro de periodos cortos de tiempo.

El uso de notaciones y lenguajes formales permite plantear de manera clara los requerimientos de un sistema, a través de generar especificaciones que definen el comportamiento en términos del “qué debe hacer” y no del “cómo lo hace”. Gracias al proceso correcto de especificación, propiedades derivadas de cada módulo, se pueden verificar mediante técnicas de razonamiento asociadas a los modelos formales, tales como, probadores de teoremas y verificadores de modelos. A partir de las especificaciones, la implementación de un sistema puede ser generada de manera casi automática. En este proceso, denominado diseño formal, es necesario garantizar que cada nivel de abstracción generado, cumpla con las propiedades verificadas en las abstracciones de más alto nivel.

En los procesos de especificación, los lenguajes de especificación formal más

conocidos y utilizados son Z y VDM, los cuales han sido recomendados como un estándar oficial para la especificación en la construcción de sistemas de software. E2) Que el alumno realice una investigación sobre en qué tipos de formalismo matemáticos se basan los Modelos de Métodos Formales. Ejemplo de Resultados. Los métodos formales son un conjunto de tendencias de desarrollo de software en donde la especificación, verificación y diseño de componentes se realiza mediante notaciones, lenguajes, herramientas y técnicas basadas en teorías con sólido fundamento matemático completamente funcional" dentro de periodos cortos de tiempo.

50

El término formal queda caracterizado por la categoría de modelos matemáticos utilizados. Ejemplos de formalismos son: lógica de primer orden, álgebras, redes de Petri y lógica temporal.

Los formalismos basados en lógica de primer orden y teoría de conjuntos permiten

especificar el sistema mediante un concepto formal de estado y operaciones sobre estados. Con este propósito, datos y relaciones/funciones se describen en detalle y sus propiedades se expresan en lógica de primer orden. La semántica de los lenguajes está basada en la teoría de conjuntos. Durante el diseño e implementación del sistema, los elementos descritos matemáticamente pueden modificarse preservando las características esenciales de la especificación inicial.

Los formalismos algebraicos proponen la descripción de estructuras de datos

estableciendo el nombre de los diferentes conjuntos de datos, funciones básicas y propiedades. No hay concepto de estado modificable en el tiempo. Las propiedades se escriben mediante fórmulas, generalmente, ecuaciones. Diferentes modelos semánticos se han propuesto para caracterizarlas especificaciones algebraicas: modelos iniciales, finales y laxos. Los modelos iniciales identifican términos cuya igualdad puede ser probada desde los axiomas. Los modelos finales identifican términos diferentes cuya desigualdad puede ser probada desde sus axiomas y los modelos laxos identifican todas las álgebras cuyos elementos pueden denotarse con términos sin variables. Para describir sistemas (de estructuras de datos) se propone una amplia gama de operadores de composición y parametrización.

Los formalismos basados en redes de Petri establecen la noción de estado de un

sistema mediante lugares que pueden contener marcas. Un conjunto de transiciones (con pre y post-condiciones) describe la evolución del sistema entendida como consumo y producción de marcas en varios puntos de la red. Existe una extensa literatura sobre las redes de Petri y sus caracterizaciones semánticas: semántica de entrelazado y semántica basada en concurrencia real.

Los formalismos basados en lógica temporal se usan para describir sistemas

concurrentes y reactivos. Un aspecto común asociado a las diferentes lógicas temporales es la noción de tiempo y estado. Una especificación escrita en lógica temporal describe las secuencias admisibles de estados (incluyendo estados concurrentes) para el sistema especificado. E3) Con base en un análisis crítico-objetivo el alumno debe resumir las condiciones apropiadas para utilizar cada formalismo matemático. E4) Resuelva el siguiente cuestionario: 1. ¿Qué es el Modelo de Métodos Formales? 2. ¿Cuál es la diferencia del Método Formal basado en lógica de primer orden y aquel

basado en lógica temporal?

51

3. ¿Cuál es la diferencia del Método Formal basado en lógica de primer orden y aquel basado en redes de Petri?

4. ¿Cuál es la diferencia del Método Formal basado en álgebras y aquel basado en redes de Petri?

5. ¿Cuál es la diferencia del Método Formal basado en redes de Petri y aquel basado en lógica temporal?.

Recursos. R1) Consultar bibliografía.

4.5 Referencias Capítulo 4

[1] James Martin Rapid application development Macmillan Publishing Co., Inc. Indianapolis, IN, USA 1991

[2] Beynon-Davies P.1; Carne C.1; Mackay H.2; Tudhope D. Rapid application development (RAD): an empirical review European Journal of Information Systems, Volume 8, Number 3, 1 Palgrave MacmillanSeptember 1999 , pp. 211-223(13)

[3] Carlo Ghezzi, Mehdi Jazayeri y Dino Mandrioli. Fundamentals of Software Engineering. Prentice Hall International, 1991.

[4] Pressman Roger S. Ingeniería del Software, Un Enfoque Práctico. Mc Graw Hill.

[5] Ian Sommerville. Ingeniería de Software Addison Wesley.

52

Capítulo 5

Herramientas de Ingeniería de Software Asistida por Computadora

María Josefa Somodevilla García María de la Concepción Pérez de Celis Herrero

María del Rocío Boone Rojas

Introducción

En términos generales, la Ingeniería de Software Asistida por Computadora (CASE) identifica al software que se utiliza para asistir a las actividades del proceso del software, tales como la Ingeniería de Requerimientos, el diseño, el desarrollo de programas y las pruebas. De tal forma que las herramientas CASE incluyen, herramientas de diseño, compiladores, herramientas para construcción de sistemas, etc.

53

La tecnología CASE proporciona ayuda al proceso del software al automatizar algunas de sus actividades y al proporcionar información acerca del proceso desarrollado. Esto permite algunas mejoras en la calidad y productividad del software.

En el presente capítulo se revisa el objetivo y el concepto de Herramientas de Ingeniería de Software Asistida por Computadora. Para los componentes de CASE, se incluye una taxonomía de herramientas CASE y ejemplos específicos. Como caso de estudio se considera, el entorno de herramientas integradas para el diseño, administración y desarrollo de bases de datos SQL, MySqlWorkbench.

5.1 Propuesta de Actividades de Motivación y Diagnóstica para el Estudio de las Herramientas de Ingeniería de Software Asistida por Computadora.

Actividades Propuestas. Actividad 1 Objetivo. Que el alumno identifique a priori algunas de las ventajas inherentes de utilizar Herramientas de la Ingeniería de Software Asistida por Computadora. Especificaciones. E1) Desarrolla el diseño de una base de datos elemental, mediante el modelo ER y por medio de las facilidades de diseño o de dibujo de una herramienta de edición básica. Ejemplo. Considera la siguiente porción de una Base de Datos para la Administración de una cadena de Talleres-Mecánicos. Los talleres se identifican mediante un Número de Taller (NTall), tienen un “Supervisor” y se ubican en una “Ciudad”. Cada taller puede tener varios Mecánicos, los cuales se identifican por una clave “NMec”, y se registra su nombre y edad. Los mecánicos tienen varias “Especialidades”, tales como (Afinación, Ajuste de Motor, Sistema Hidráulico, …) pero con diferentes “años” de experiencia.

Ejemplo de Resultados.

Fig. 5.1 Diseño ER, Base de Datos Mecánicos E2) Resuelve el siguiente cuestionario: 1. ¿Consideras que la herramienta que utilizaste fue la más adecuada para apoyar el

proceso de diseño de tu base de datos?2. ¿Por medio de esta herramienta y con respecto al diseño de tu base de datos, se

distinguen claramente las entidades, llaves, atributos y las relaciones de tu base de datos?

3. ¿A partir del diseño ER de tu base de datos, podrías fácilmente traducirlo a un nivel lógico, posiblemente a tablas relacionales?

Recursos. R1) Base de Datos Experimental posiblemente desarrollada en un curso paralelo o previo. R2) Procesador de Texto o herramienta equivalente con facilidades de diseño.

Fig. 5.1 Diseño ER, Base de Datos Mecánicos-Talleres.

E2) Resuelve el siguiente cuestionario:

¿Consideras que la herramienta que utilizaste fue la más adecuada para apoyar el proceso de diseño de tu base de datos?

de esta herramienta y con respecto al diseño de tu base de datos, se distinguen claramente las entidades, llaves, atributos y las relaciones de tu base de

¿A partir del diseño ER de tu base de datos, podrías fácilmente traducirlo a un nivel posiblemente a tablas relacionales?

Base de Datos Experimental posiblemente desarrollada en un curso paralelo o

R2) Procesador de Texto o herramienta equivalente con facilidades de diseño.

54

¿Consideras que la herramienta que utilizaste fue la más adecuada para apoyar el

de esta herramienta y con respecto al diseño de tu base de datos, se distinguen claramente las entidades, llaves, atributos y las relaciones de tu base de

¿A partir del diseño ER de tu base de datos, podrías fácilmente traducirlo a un nivel

Base de Datos Experimental posiblemente desarrollada en un curso paralelo o

R2) Procesador de Texto o herramienta equivalente con facilidades de diseño.

55

Actividad 2

Objetivo. Que el alumno identifique, a priori, algunas de las ventajas inherentes de utilizar Herramientas de la Ingeniería de Software Asistida por Computadora. Así como en este caso, el apoyo que pueden ofrecer en la formalización y documentación del proceso de desarrollo de un proyecto.

Considera la siguiente porción del documento en [5], relacionado con la especificación

de Requisitos funcionales mediante la técnica de “casos de uso” y para un sistema de gestión de un video club. Requisitos relacionados con el Almacenamiento de Información.

RI–03 Información sobre cuentas de socios

Objetivos asociados OBJ–02 Gestionar los socios

Requisitos

asociados

• RF–01 Alta de socio

• RF–02 Baja de socio

• RF–05 Alquiler de cinta de vídeo

• RF–08 Devolución de cintas de vídeo

• RF–09 Ingreso a cuenta

• RF–11 Consulta de un socio

• RF–12 Consulta de socios con pagos pendientes

Descripción El sistema deberá almacenar la información correspondiente a las

cuentas de los socios del vídeo–club. En concreto:

Datos específicos • Saldo de la cuenta en cada momento

• Ingresos realizados en la cuenta, indicando fecha y cantidad

• Cargos realizados en la cuenta, indicando fecha, motivo y

cantidad

• Pagos pendientes, indicando motivo que podrá ser alquiler no

pagado o multa; en el caso de alquiler no pagado se debe

indicar también la película alquilada y la fecha del alquiler

Intervalo temporal sólo presente

Estabilidad Alta

Comentarios Un socio puede hacer ingresos a cuenta, por ejemplo para enviar a

sus hijos por películas sin que éstos tengan que llevar dinero

56

Fig. 5.2 Diagrama de casos de uso del subsistema Gestión de socios

Especificaciones. E1. Realiza la especificación anterior mediante las facilidades que te proporciona la herramienta que utilizaste para la actividad anterior. E2. Resuelve el siguiente cuestionario.

1. ¿Consideras que la herramienta que utilizaste fue la más adecuada para apoyar la especificación de requisitos desarrollada mediante esta técnica?

2. ¿Por medio de tu herramienta, y con respecto a la especificación realizada, se podría fácilmente dar seguimiento y durante el proceso de desarrollo del proyecto a los requisitos establecidos?

3. ¿Por medio de esta especificación, podrías fácilmente, continuar con el proceso de desarrollo del proyecto?

57

5.2 Planeación Didáctica de los Antecedentes y Conceptos Básicos de Ingeniería de Software Asistida por Computadora.

Tiempo. Se propone cubrir el tema en un intervalo de 4 hrs. Contenido. 5. El Concepto CASE. 6. Componentes básicos de CASE. 7. Taxonomía de Herramientas CASE. 8. Caso de Estudio. Introducción a una Herramienta de Ingeniería de Software Asistida

por Computadora.

Materiales.

Referencias Bibliográficas.

[1] Capítulo 29 Pressman Roger S. Ingeniería de Software, Un Enfoque Práctico. McGraw Hill.

[2] Pags. 11,79-82, 225,280. Ian Sommerville. Ingeniería de Software Addison Wesley. Recursos Electrónicos. [3]López Quesada Juan Antonio. Herramientas CASE http://dis.um.es/~lopezquesada/documentos/tema%2013.ppt Alguna herramienta CASE. Ejemplo.MySQLWorkbench www.mysql.com/products/workbench/

58

5.3 Desarrollo de las Actividades de Antecedentes y Conceptos Básicos de Ingeniería de Software Asistida por Computadora.

5.3.1 El Concepto CASE. Material de Referencia. De Pressman [2]: El mejor taller de un artesano -sea mecánico, carpintero o ingeniero del software- tiene

tres características fundamentales: (1) una colección de herramientas útiles que le

ayudarán en todos los pasos de la construcción de un producto; (2) una disposición

organizada que permitirá hallar rápidamente las herramientas y utilizarlas con eficacia; y

(3) un artesano calificado que entienda la forma de utilizar las herramientas de manera

eficaz. Ahora es cuando los ingenieros del software reconocen que necesitan más

herramientas y más variadas, junto con un taller eficiente y organizado en el que puedan

ubicarlas. El taller de ingeniería del software se denomina un entorno de apoyo integrado

a proyectos y el conjunto de herramientas que llena ese taller se denomina ingeniería del

software asistida por computadora (CASE). CASE proporciona al ingeniero la posibilidad

de automatizar actividades manuales y de mejorar su visión general de la ingeniería. Al

igual que las herramientas de ingeniería y de diseño asistidos por computadora que

utilizan los ingenieros de otras disciplinas, las herramientas CASE ayudan a garantizar

que la calidad se diseñe antes de llegar a construir el producto.

En [3] se establece:

� Objetivos de la tecnología CASE. � INCREMENTAR

� Productividad del equipo. � Calidad del Software. � Reusabilidad del software.

� REDUCIR � Costes de desarrollo y mantenimiento.

� AUTOMATIZAR � Gestión del proyecto. � Desarrollo del software. � mantenimiento del software (Incluyendo la automatización y

estandarización de la documentación y de su mantenimiento)

� AUTOMATIZACIÓN DEL DESARROLLO DE SW.:

� Productividad del equipo ↑↑

� Calidad del Software ↑↑

59

� INCREMENTAR

� Reusabilidad del software. � REDUCIR

� Costos de desarrollo y mantenimiento. � AUTOMATIZAR/SIMPLIFICAR

� Gestión del proyecto. � Desarrollo del sw. (permitir aplicación met. estructuradas;

prototipos; desarrollo “visual”) � Mantenimiento del software (Incluyendo la automatización y

estandarización de la documentación y de su mantenimiento) Concepto CASE (Computed Aided Software Engineering) � Conjunto de herramientas y métodos asociados que proporcionan asistencia

automatizada en el proceso de desarrollo del software a lo largo de su ciclo de vida. � Gestión del proyecto. (planificación, estimación y control) � Desarrollo del software. (análisis, diseño, implementación, validación) � Mantenimiento del software.

Actividades Propuestas. Actividad 1 Objetivo. Que el alumno identifique el concepto de Ingeniería de Software Asistida por Computadora. Especificación. E1) Revisa las referencias [1], [2] y realiza tu propia investigación sobre el concepto de ingeniería de software asistida por computadora. -Elabora un mapa conceptual que involucre los principales elementos que involucra el concepto de ingeniería de software asistida por computadora. Ejemplo tipo de Resultados. (Ver mapa conceptual en Programa de curso de la asignatura de Ingeniería de Software, Modelo MUM). Recursos. R1) Referencias [1] y [2]

60

R2) Conexión a Internet.

5.3.2Componentes básicos de CASE. Material de Referencia.

Revisar Referencias [1] y [2]. De acuerdo a López-Quesada [3]:

Fig. 5.3 Componentes CASE

� Interfaz gráfica. � Editor de textos y gráficos. � BD de soporte

(BD del proyecto, depósito o ‘repositorio’ CASE) � Mecanismos de control para:

� acceso a componentes. (datos, código, documentos, dispositivos)

� Compatibilidad de las herramientas. � Consistencia de los productos. � Detección de olvidos. � Trazado de modificaciones.

� Donde la BD de soporte:

61

� Reúne las funciones de: � Catálogo central de archivos y BD’s. � Diccionario de datos y procesos. � Biblioteca de programas y documentación.

� y es la base para: � La integración de herramientas. � El mantenimiento de la integridad del sistema. � La coordinación y compartición de información entre usuarios, con controles

de seguridad y privilegios de acceso. � El control de cambios y versiones. � La estandarización de la documentación. � La reutilización del software. � La gestión del proyecto (incluyendo auditorías). � La incorporación a otro sistema informático.

De una forma más específica en [1] se indica: Aunque se pueden obtener beneficios individualmente de las herramientas CASE que

abarcan actividades de ingeniería del software por separado, la verdadera potencia de

CASE solamente se puede lograr mediante la integración. Entre los beneficios del CASE

integrado (I-CASE) se incluyen: (1) una transferencia regular de información (modelos,

programas, documentos, datos) entre una herramienta y otra, y entre un paso de ingeniería

y el siguiente; (2) una reducción del esfuerzo necesario para efectuar actividades globales

tales como la gestión de configuración de software, el control de calidad y la producción

de documentos; ( 3 ) un aumento del control del proyecto que se logra mediante una mejor planificación, monitorización y comunicación; (4) una mejor coordinación entre los

miembros del personal que estén trabajando en grandes proyectos de software.

5.3.3Taxonomía de Herramientas CASE. Material de Referencia.

De acuerdo a [1] Existe un cierto número de riesgos que son inherentes siempre que se intenta efectuar una

categorización de las herramientas CASE. Existe una sutil implicación que consiste en que

para crear un entorno CASE efectivo se deberán implementar todas las categorías de

herramientas esto no es ni sencillo, ni cierto-. Cuando hay personas que creen que una

herramienta pertenece a una categoría, se puede crear cierta confusión (o contradicción)

al ubicar una herramienta específica dentro de otra categoría. Es posible que algunos

lectores piensen que se ha omitido una categoría completa -e1iminando por tanto un

conjunto de herramientas completo e incluirlo así en el entorno CASE global-. Además,

62

una categorización sencilla tiende a ser plana - esto es, no se muestra la interacción

jerárquica de las herramientas o las relaciones que existen entre ellas-. A pesar de estos

riesgos, es necesario crear una taxonomía de herramientas CASE, para comprender mejor

la amplitud de CASE y para apreciar mejor en donde se pueden aplicar estas herramientas dentro del proceso del software. Las herramientas CASE se pueden clasificar por su

función, por su papel como instrumentos para administradores o personal técnico, por su

utilización en los distintos pasos del proceso de ingeniería del software, por la arquitectura

del entorno (hardware y software) que les presta su apoyo, o incluso por su origen o costo.

La clasificación de la taxonomía que se presenta a continuación utiliza como criterio

principal la función.

� Herramientas de ingeniería de procesos de negocio. � Modelado de procesos y herramientas de gestión. � Modelado de procesos y herramientas de gestión. � Herramientas de análisis de riesgos. � Herramientas de gestión de proyectos. � Herramientas de seguimiento de requisitos. � Herramientas de métricas y de gestión. � Herramientas de documentación. � Herramientas de software de sistema. � Herramientas de control de calidad. � Herramientas de gestión de bases de datos del proyecto. � Herramientas de gestión de configuración de software. � Herramientas de análisis y diseño. � Herramientas PRO/SIM. (De construcción de prototipos y simulación). � Herramientas de desarrollo y diseño de interfaz. � Herramientas de construcción de prototipos. � Herramientas de programación. � Herramientas de desarrollo de Webs. � Herramientas de integración y pruebas. � Herramientas de análisis estático. � Herramientas de análisis dinámico. � Herramientas de gestión de pruebas. � Herramientas de pruebas cliente/servidor. � Herramientas de reingeniería.

En la taxonomía de [3] se incluyen ejemplos específicos dentro de algunas de sus categorías:

� Herramientas de análisis y diseño.

63

� Permiten crear y verificar DFD’s, diagramas E/R, de clase, de estructura... � Herramientas de prototipado:

� Diseñadores de pantallas � Generadores de menús � Generadores de informes � Lenguajes de especificación ejecutables

� Ejemplos:

� DESIGNER/2000 de ORACLE � EASY CASE de Evergreen � Rational ROSE � EXCELERATOR de Intersolv � OBJECT MAKER de Mark IV. � OMTool de GTE. � PARADIGM Plus de Platinum � SILVERRUN de CSA Research � SYSTEM Architect de PopkinSofware& Systems

� Herramientas de acuerdo a su funcionalidad.

� Herramientas de gestión de proyectos ayudan a la planificación y seguimiento del

proyecto � Planificación: agenda de desarrollo. � Estimación: costes, duración, esfuerzo. � Control: productividad, calidad.

� Herramientas de análisis y diseño. � Herramientas de prototipado y simulación. � Herramientas de programación.

� Editores dirigidos por la sintaxis (cabeceras de subrutinas, palabras clave, indentación, nomenclatura de variables, ...)

� Generadores de estructuras de programas. � Entornos integrados de desarrollo para soporte de un lenguaje (editor,

compilador, depurador). � Herramientas de integración y pruebas.

� Analizadores estáticos. � Depuradores. � Generadores de datos. � Comparadores (e.g. de archivos).

� Herramientas de soporte. � Herramientas de mantenimiento.

� Ingeniería inversa.

64

� Reingeniería. En [2] se presenta un ejemplo ilustrativo de una posible clasificación de la tecnología CASE como ayuda para el proceso del software.

Se puntualiza que la tecnología CASE proporciona ayuda automatizada a los procesos del software. Las herramientas CASE ayudan a las actividades individuales del proceso; los bancos de trabajo ayudan a un conjunto de actividades relacionadas; los entornos ayudan a todas o a la mayoría de las actividades del proceso del software.

Fig. 5.4 Herramientas, Bancos de Trabajo y Entornos. Actividad 1 Objetivo. Que el alumno organice una versión propia de una taxonomía de herramientas CASE, como resultado de la consulta de al menos tres referencias. Especificaciones. E1. Revisa la taxonomía de herramientas CASE en las referencias [1] [2] [3].

65

E2. Organiza en una tabla una taxonomía que resulte de la unión de los diferentes tipos de herramientas CASE que se consideran en las taxonomías de las referencias [1] [2] y [3]. Ejemplo de resultados. Tomar como referencia alguna de las taxonomías incluidas en [1] [2] y [3]. Actividad 2 Objetivo. Que el alumno conozca que existen muy diversos tipos de herramientas CASE y que pueden ser de diferentes tipos, propósitos y alcances. Especificaciones. E1) Realiza una búsqueda por Internet y toma como referencia la taxonomía de herramientas CASE que se ha revisado en este capítulo. Desarrolla una breve documentación sobre cinco herramientas de diferentes tipos. Incluye al menos la siguiente información: Nombre. Empresa. Propósito.

Puedes organizar tus resultados en una tabla.

Ejemplo de Tipo de Resultados. Nombre Herramienta

Empresa Propósito

MySQLWorkbench. Oracle. Entorno integrado de herramientas para el diseño, administración y desarrollo de bases de datos SQL.

Recursos. R1) Conexión a internet.

66

Actividad 3 Objetivo. Que el alumno esté informado sobre las facilidades básicas de un entorno integrado / banco de Trabajo CASE. Especificaciones. E1) Toma como referencia la investigación realizada en la actividad anterior, selecciona un entorno integrado de herramientas CASE que sea de tu interés, realiza un breve reporte (3-5 cuartillas) sobre sus características generales y facilidades básicas. Ejemplo de Tipo de Resultados. (Complementar información de Caso de Estudio de la Sig. sección)

5.3.4Caso de Estudio. Introducción a una Herramienta de Ingeniería de Software Asistida por Computadora. Se propone revisar las facilidades básicas y a nivel de introducción de alguna herramienta de Ingeniería de Software Asistida por Computadora. Ej. Para el diseño de Bases de Datos, Para Especificación de Requisitos/ Casos de Uso, Generador de Reportes, entre otros.

Ejemplo. Introducción al entorno de herramientas MySQLWorkbench para el caso de diseño de bases de Datos. Se propone revisar las características generales del producto, Fig. 5.5. y a continuación ofrecer un panorama general de las facilidades básicas para el diseño de base de datos de la herramienta, Fig. 5.6.

Fig. 5.6 Herramientas para diseño visual de bases de datos en MysqlWorkbench.

Fig. 5.5Workbench Central.

Herramientas para diseño visual de bases de datos en MysqlWorkbench.

67

Herramientas para diseño visual de bases de datos en MysqlWorkbench.

68

Actividad 1. Objetivo. Que el alumno realice una experimentación básica con alguna herramienta CASE, en este caso para el diseño de bases de datos mediante las herramientas de Mysql Workbench. Especificaciones. E1. Considera la base de datos experimental cuyo diseño desarrollaste en la actividad 1 de la Sección 5.1. E2. Desarrolla el diseño de tu base de datos experimental mediante las facilidades para el diseño de bases de datos de Mysql Workbench.

5.4 Comentarios, Conclusiones y Actividades Complementarias sobre los Antecedentes y Conceptos Básicos de Ingeniería de SoftwareAsistida por Computadora. -Se propone dar continuidad a las actividades de investigación y experimentación realizadas previamente.

-Se propone continuar experimentando con la herramienta CASE que se ha abordado como caso de estudio. -Se propone realizar investigación y experimentación complementaria sobre otro tipo de herramientas CASE más especializadas, tales como para la Admon. De Proyectos o Ingeniería Web. -Realizar una discusión grupal sobre las posibles ventajas del desarrollo de proyectos individuales y/o grupales mediante el apoyo de la tecnología CASE.

5.5 Referencias, Capítulo 5 Referencias Bibliográficas.

[1] Capítulo 29 / 31 Pressman Roger S. Ingeniería de Software, Un Enfoque Práctico. McGraw Hill.

69

[2] Pags. 11,79-82, 225,280. Ian Sommerville. Ingeniería de Software Addison Wesley. Recursos Electrónicos. [3]López-Quesada, Juan Antonio. Herramientas CASE http://dis.um.es/~lopezquesada/documentos/tema%2013.ppt [4] MySQL Workbench www.mysql.com/products/workbench/ [5] Domínguez D., R. García. “Ejemplo de Casos de Uso, Gestión de un Video Club”. http://www.dsic.upv.es/asignaturas/facultad/si/trabajos/032000.doc

70

Capítulo 6

Modelos Ágiles de Procesos.

Josefina Guerrero García Juan Manuel González Calleros

Introducción

La ingeniería de software ha evolucionado en los últimos años y se ha adaptado al entorno dinámico donde es usada y como tal sus métodos han evolucionado. Es ahí donde nacen los métodos ágiles que promueven, entre otras cosas, la adaptación constante y efectiva a los cambios que ocurren con las necesidades del cliente. Este capítulo introduce brevemente los conceptos de los métodos ágiles como una invitación al alumno a descubrirlos a lo largo del curso.

El docente tiene como objetivo motivar la importancia actual que tienen los métodos ágiles y que favorecen la retención de los conceptos relevantes al tema. La asignación de actividades dinámicas que ayuden a retener los conceptos aquí presentados es el objetivo de esta unidad.

El alumno se tendrá que involucrar en las actividades grupales e individuales de tal forma que vaya adquiriendo el conocimiento asociado a los métodos ágiles.

En el presente capítulo se propone una serie de actividades de aprendizaje para que el docente pueda desarrollar en su clase los siguientes aspectos:

71

o Modelos Ágiles de Proceso o Programación Extrema o Metodologías Cristal o Scrum

6.1 Propuesta de actividades de motivación y diagnóstica para el estudio de modelos ágiles de proceso.

Actividades Propuestas. Actividad 1. Identificación de limitantes de métodos actuales de ingeniería de software Objetivo. El alumno será capaz de identificar las limitantes de los métodos de desarrollo de software tradicionales y proponer mejoras. Especificaciones. Plantear un caso de estudio simple, donde sean muy notorias las limitantes del uso de un método tradicional. Dar oportunidad al alumno a la reflexión considerando el conocimiento ya adquirido sobre procesos de desarrollo de software usando una lista de fallas en el software para que puedan identificar las causas de las fallas. Ver video de Ariane 5. Disponible en http://www.youtube.com/watch?v=gp_D8r-2hwk

El 4 de junio de 1996, el primer vuelo de la nueva Agencia Aeroespacial Europea lanzó

el cohete Ariane 5, mismo que falló poco después del lanzamiento, lo que resultó en una pérdida estimada de mil quinientos millones de dólares. El problema:

72

La altitud y trayectoria del cohete es medía por un equipo de referencia inercial computarizado. Este transmitía los comandos a los motores para mantener la altitud y la dirección.

a. El software falló y este sistema y el sistema de soporte se apagaron b. Los comandos de diagnóstico fueron transmitidos a los motores lo cuales

fueron interpretados como datos reales e hicieron girar el cohete a una posición extrema

Falla de software: Un Fallo de software se produjo cuando se intentó hacer una conversión de un número de 64 bits de punto flotante, a un entero con signo de 16 bits, lo que hizo que se desbordara la memoria.

a. No había manejador de excepciones asociado con la conversión de números. Por seguridad, ésto apagó la computadora.

b. La aplicación de respaldo tenía el mismo error así que, también falló. Se pudo evitar la catástrofe El software que falló fue rehusado del sistema del Ariane 4. El cálculo computacional que falló no fue usado en el Ariane 5. Se tomaron decisiones en su momento:

a. No quitar esta facilidad ya que podría producir errores no controlados b. No poner a prueba las excepciones de desbordamiento de memoria ya que el

procesador estaba muy cargado. Por razones de fiabilidad, se pensaba que era deseable tener un poco de capacidad del procesador de repuesto

c. En el Ariane 4 nunca se hubiera generado este error pues la velocidad nunca sería tan rápida como la del Ariane 5.

La cadena de omisiones Esta funcionalidad del Ariane 4 no era necesaria en el Ariane 5 por lo tanto nunca fue un requerimiento. Dado que no era requerimiento nunca se probó su funcionalidad ni correcta operación durante las pruebas. La simulación nunca llego a este escenario ya que no estaba en la lista de pruebas. Lección aprendida Todo software debe ser revisado y probar que funcione No ejecutar software en sistemas críticos a menos que sea realmente necesario (por eso los aviones no llevan computadoras para controlar el avión, sino puros controles y sensores) Así como se prueba lo que el sistema debe hacer se debe probar lo escenarios donde el sistema hace lo que no debe hacer

Tomar en cuenta todas las variantes de excepciones que pueden ocurrir y no recaer en el uso del gestor por default de excepciones

En cálculos computacionales críticos, siempre tener clara la alternativa numérica a asignar en caso de error al sistema

En la medida de la posibilidad hacer pruebas reales y no solo simulaciones

73

Mejorar el proceso de revisión incluyendo participantes externos y revisando todas las suposiciones que se hacen en el código

El diseñador del Ariane 5 cometió un error elemental pero critico. Diseño un sistema complejo donde la falla de un componente simple lo hizo fallar. Errores muy graves pese a que el software estaba dirigido por método formal, rígido.

Ahora el alumno debe identificar en los siguientes casos las causas posibles del error de software.

Ejemplo de Resultados.

1. En febrero de 2008, problemas de software en el sistema automático de clasificación de equipajes en un aeropuerto importante, impidieron la partida de miles de pasajeros al no poder documentar su equipaje para sus respectivos vuelos Se informó que la falla se produjo durante una actualización de software, a pesar de la pre-prueba del mismo. El sistema continuó teniendo problemas en los meses siguientes. Pruebas no exhaustivas.

2. Informes de prensa en diciembre de 2007 indicaban que seguían ocurriendo problemas importantes de software en un nuevo sistema de nóminas ERP para un sistema escolar urbano. Se pensaba que en varias ocasiones, más de un tercio de los empleados, había recibido cheques de pago incorrectos, desde que el nuevo sistema se puso en marcha en enero, lo que dio lugar a pagos en exceso por 53 millones de dólares, además de otros pagos erróneos. El sindicato de trabajadores presentó una demanda contra el sistema escolar, se espera que el costo del sistema ERP aumente en un 40%, y la parte que no pertenece a la nómina del sistema de ERP se retrasó. Según los informes, pruebas inadecuadas han contribuido a los problemas.

3. En noviembre de 2007 un gobierno regional interpuso una demanda multimillonaria en contra de un proveedor de servicios de software, afirmando que èste "minimizó la calidad del software " de un gran sistema de información sobre justicia penal y que por lo tanto, el sistema no cumplía los requisitos. El vendedor también demandó a su subcontratista en el proyecto. Fallo de comunicación, ausencia de interacción con el cliente ya que seguramente al ser subcontratado no trabajaba directamente con los actores involucrados.

4. Según informes periodísticos, en abril de 2007, un problema de software contribuyó a un incendio de vagones de ferrocarril, en un importante sistema de metro. Se comunicó que el software no funcionó como era de esperarse para detectar y prevenir el exceso de consumo de energía en los equipos de un vagón de pasajeros nuevo, ocasionando un sobrecalentamiento y fuego en dicho vagón,

74

la consecuente evacuación y el cierre de parte del sistema. Falta de pruebas, liberación temprana del sistema.

E1) Identificar problemas a partir de la lista arriba descrita Recursos. R1) Caso de estudio de experiencia de desarrollo de software fallida. Material descriptivo de métodos tradicionales de ingeniería de software. Lista de errores de software.

6.2 Planeación Didáctica de modelos agiles de proceso. Tiempo. Se propone cubrir el tema en un intervalo de 5 hrs.

• 2 h. para la introducción a los métodos ágiles (sección x.2.3)

• 2 h. para la descripción de los diferentes procesos (sección x.2.4)

• 1h. para consolidar el conocimiento adquirido (sección x.2.5) Contenido. 9. Modelo Ágiles de proceso 10. Programación Extrema 11. Cristal 12. Scrum 13. Melé

Materiales. Texto en este capítulo. Metodos-Agiles.PDF nerur.pdf carlos-reynoso-metodos-agiles-academia.ppt

Referencias Bibliográficas.

[1] SridharNerur, RadhaKantaMahapatra, George Mangalaraj Challenges of migrating to agile methodologies Communications of the ACM - Adaptive complex enterprises Volume 48 Issue 5, May 2005

75

[2] Desarrollo de Software mediante Metodologías Ágiles. http://www.snip.gob.ni/Xdc/Agile/Agile.htm [3] Capitulo1 Ken Schwaber, Mike Beedle Agile Software Development with Scrum Prentice Hall [4] Carlos Reynoso Métodos Ágiles en desarrollo de software UNIVERSIDAD DE BUENOS AIRES http://carlosreynoso.com.ar/archivos/arquitectura/Metodos-Agiles.PDF [7] GrigoriMelnik Microsoft p&p summit, 2007 Empirical Evidence Of Agile Methods http://www.slideshare.net/melnik/empirical-evidence-of-agile-methods-190997 6.3 Desarrollo de las Actividades de Introducción a los métodos ágiles de la Ingeniería de Software.

6.3.1 Introducción a los modelos ágiles. Material de Referencia. Síntesis y extracción de [4]: “Los modelos de los métodos clásicos difieren bastante en su conformación y en su naturaleza, pero exaltan casi siempre las virtudes del planeamiento y poseen un espíritu normativo. Comienzan con la licitación y el análisis completo de los requerimientos del usuario. Después de un largo período de intensa interacción con usuarios y clientes, los ingenieros establecen un conjunto definitivo y exhaustivo de rasgos, requerimientos funcionales y no funcionales. Esta información se documenta en forma de especificaciones para la segunda etapa, el diseño, en el que los arquitectos, trabajando junto a otros expertos en temas puntuales (como ser estructuras y bases de datos), generan la arquitectura del sistema. Luego los programadores implementan ese diseño bien documentado y finalmente, el sistema completo se prueba y se despacha. ”

76

Castigando sobre todo al modelo en cascada se ha publicado:

“Gran parte de los procedimientos actuales de adquisición de software reposan en el supuesto de que se puede especificar de antemano un sistema satisfactorio, obtener requisitos para su construcción, construirlo e instalarlo. Pienso que este supuesto es fundamentalmente equivocado y que muchos de los problemas de adquisición se originan en esta falacia.”

Descrédito de los procesos en cascada (1988) Department of Defense Standard 2167A), titled "Defense Systems

Software Development → MIL STD 498 "establish uniform requirements for software development and documentation." (1994)

Crisis de confianza en los procesos regidos por metodologías prescriptivas con análisis completo de requerimientos y planificación detallada

CMM, CMMI, Spice, Bootstrap, TickIt, ISO 9000 CMM no es una metodología ni un modelo en cascada, pero “coincide con su espíritu” Legislación negativa sobre conformidad con estándares de calidad

Ante esa evidencia los expertos, en masa, aconsejaron el abandono de los métodos

en cascada y las normativas fuertes. Trabajaron en sus propias alternativas dinámicas, iterativas, evolutivas y en suma, ágiles. Reforzado por el entorno donde se trabaja Nerur [1] expone:

“Software development methodologies are constantly evolving due to changing technologies and new demands from users. Today’s dynamic business

77

environment has given rise to emergent organizations that continuously adapt their structures, strategies, and policies to suit the new environment1. Such organizations need information systems that constantly evolve to meet their changing requirements—but the traditional, plan-driven software development methodologies lack the flexibility to dynamically adjust the development process.”

A comienzos del siglo XXI ante el descrédito de los métodos tradicionales se daban las condiciones para los 17 proponentes de métodos ágiles se juntaran en marzo de 2001 en Salt Lake City para discutir los nuevos métodos. Lo que surgió de su reunión fue el Manifiesto Ágil de Desarrollo de Software. De donde surgen ideas como:

De hecho, muchos de nosotros deseamos restaurar credibilidad a la palabra metodología. Queremos recuperar un equilibrio. Promovemos el modelado, pero no con el fin de archivar algún diagrama en un polvoriento repositorio corporativo. Promovemos la documentación, pero no cientos de páginas en tomos nunca mantenidos y rara vez usados. Planificamos, pero reconocemos los límites de la planificación en un entorno turbulento.

• Los individuos y la interacción por encima de los procesos y

herramientas.La gente es el principal factor de éxito de un proyecto software. No se necesitan desarrolladores brillantes, sino desarrolladores que se adapten bien al trabajo en equipo. Así mismo, las herramientas (compiladores, depuradores, control de versiones, etc.) son importantes para mejorar el rendimiento del equipo, pero el disponer de más recursos que los estrictamente necesarios también puede afectar negativamente.

• El software que funciona por encima de la documentación abarcadora. Aunque se parte de la base de que el software sin documentación es un desastre, 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 por encima de la negociación contractual. 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.

• La respuesta al cambio por encima del seguimiento de 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 puesto que hay muchas variables en juego, debe ser flexible para poder adaptarse a los cambios que puedan surgir.

1Truex, D.P., Baskerville, R. and Klein, H. Growing systems in emergent organizations. Commun. ACM 42, 8 (Aug. 1999), 117–123.

78

Aunque hay valor en los elementos a la derecha, valorizamos más los de la izquierda.

Los principios que rigen a la comunidad de métodos ágiles:

1. Nuestra prioridad más alta es satisfacer al cliente a través de la entrega temprana y continua de software valioso.

2. Los requerimientos cambiantes son bienvenidos, incluso cuando llegan tarde en el desarrollo. Los procesos ágiles se pliegan al cambio en procura de una ventaja competitiva para el cliente.

3. Entregar con frecuencia software que funcione, desde un par de semanas hasta un par de meses, con preferencia por las escalas de tiempo más breves.

4. La gente de negocios y los desarrolladores deben trabajar juntos cotidianamente a través de todo el proyecto.

5. Construir proyectos en torno de individuos motivados. Darles la oportunidad y el respaldo que necesitan y procurarles confianza para que realicen la tarea.

6. La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara.

7. El software que funciona es la medida primaria de progreso. 8. Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores,

desarrolladores y usuarios deben mantener un ritmo constante indefinidamente.

9. La atención continua a la excelencia técnica enaltece la agilidad. 10. La simplicidad (el arte de maximizar la cantidad de trabajo que no se hace)

es esencial. 11. Las mejores arquitecturas, requerimientos y diseños emergen de equipos

que se auto organizan. 12. A intervalos regulares, el equipo reflexiona sobre la forma de ser más

efectivo, y ajusta su conducta en consecuencia. Nerur [1] realza las diferencias entre métodos ágiles y tradicionales en el siguiente gráfico.

79

Los modelos ágiles se pueden describir como aquellos modelos que son lo suficientemente buenos, donde cumplen con las siguientes características: satisfacen un propósito, son inteligentes, son lo suficientemente precisos, son lo suficientemente detallados, aportan valor positivo y son lo más simple posible. Para poder tener más clara las ideas un modelo ágil es más eficiente que los modelos tradicionales, un prototipo de papel podría ser un modelo ágil, un dibujo de pizarra podría ser un modelo ágil, un diagrama de Visio puede ser un modelo ágil o un modelo de datos físicos podría ser un modelo ágil. El tipo de modelo, o herramienta con la que se creó en realidad no importa, lo importante es que el modelo sólo sea sólo lo suficientemente bueno para obtener su máximo provecho.

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. Existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en lapsos cortos de tiempo. El software desarrollado en una unidad de tiempo es llamado una iteración, la cual debe durar de una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, 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. La mayoría de los equipos ágiles están localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento". La oficina debe incluir revisores, escritores de documentación y ayuda, diseñadores de iteración y directores de proyecto. Los métodos ágiles también enfatizan que el software funcional es la primera medida del progreso.

80

Actividades Propuestas. Actividad 1. Requerimientos para cambiar de un paradigma clásico a uno ágil Objetivo. Que el alumno proponga los cambios organizacionales necesarios para adoptar un proceso de desarrollo ágil. Especificación. E1) Llena la siguiente tabla en equipos de 4 indicando los cambios necesarios para adoptar un proceso iterativo. Cambio organizacional y en la administración Cambio en la gente Cambio en los procesos Cambio en la tecnología (técnicas y herramientas)

Ejemplo tipo de Resultados. Cambio organizacional y en la administración

• Cultura organizacional • Estilo de administración • Forma organizacional

• Manejo del conocimiento de desarrollo de software • Sistemas de recompensas

Cambio en la gente

• Trabajo efectivo en equipo • Alto nivel de competencias • Relaciones con clientes – compromiso, conocimiento, proximidad, confianza, respeto

Cambio en los procesos

• Cambio de un proceso centralizado a uno guiado por características, centrado en la persona

81

• Guiado por elementos como ser: corto, iterativo, evaluativo con énfasis en la adaptabilidad • Manejo de proyectos grandes y escalables • Selección del proceso ágil adecuado a la empresa

Cambio en la tecnología (técnicas y herramientas) Revisar que herramientas y tecnología sean apropiadas Desarrollo de nuevas habilidades - Recursos. R1) Referencia [1] R2) Material de esta sección

6.4 Desarrollo de las actividades de métodos ágiles de la ingeniería de software.

6.4.1 PROGRAMACIÓN EXTREMA [extreme programming( XP)] Kent Beck [5] sentó las bases de los patrones de diseño y XP en 1999. XP es la primera metodología ágil y la que le dio conciencia al movimiento actual de metodologías ágiles, se centra en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en retroalimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios [6]. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico.

Los principios y prácticas son de sentido común pero llevadas al extremo, de ahí proviene su nombre.

Las características esenciales de XP se pueden organizar en: historias de usuario, roles, proceso y prácticas.

A. Las Historias de Usuario [Tarjetas de historia (StoryCards)] Son la técnica utilizada para especificar los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las características que el sistema debe poseer, sean requisitos funcionales o no funcionales. Las tarjetas se usan para estimar prioridades, alcance y tiempo de realización; en caso de discrepancia, gana la estimación más optimista. El tratamiento de las historias de usuario es muy dinámico y flexible. Cada historia de usuario es lo suficientemente comprensible y delimitada para que los programadores puedan implementarla en unas semanas. Un ejemplo de ficha presenta los siguientes contenidos: fecha, tipo de actividad (nueva, corrección, mejora), prueba funcional, número de historia, prioridad técnica y del cliente, referencia a otra historia previa, riesgo, estimación técnica, descripción, notas y una lista de seguimiento con la

82

fecha, estado, cosas por terminar y comentarios. A efectos de planificación, las historias pueden ser de una a tres semanas de tiempo de programación (para no superar el tamaño de una iteración). Las historias de usuario son descompuestas en tareas de programación (taskcard) y asignadas a los programadores para ser implementadas durante una iteración.

B. Roles XP Los roles de acuerdo con la propuesta original de Beck son: - Programador. El programador escribe las pruebas unitarias y produce el código del sistema. - Cliente. Escribe las historias de usuario y las pruebas funcionales para validar su implementación. Además, asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar mayor valor al negocio. - Encargado de pruebas (Tester). Ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas. - Encargado de seguimiento (Tracker). Proporciona realimentación al equipo. Verifica el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, para mejorar futuras estimaciones. Realiza el seguimiento del progreso de cada iteración. - Entrenador (Coach). Es responsable del proceso global. Debe proveer guías al equipo de forma que se apliquen las prácticas XP y se siga el proceso correctamente. - Consultor. Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto, en el que puedan surgir problemas. - Gestor (Big boss). Es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación.

C. Proceso XP Un proyecto XP tiene éxito cuando el cliente selecciona el valor de negocio a implementar basado en la habilidad del equipo para medir la funcionalidad que puede entregar a través del tiempo. El ciclo de desarrollo consiste en los siguientes pasos:

1. El cliente define el valor de negocio a implementar. 2. El programador estima el esfuerzo necesario para su implementación. 3. El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones de tiempo. 4. El programador construye ese valor de negocio. 5. Vuelve al paso 1. En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No

se debe presionar al programador a realizar más trabajo que el estimado, ya que se perderá calidad en el software o no se cumplirán los plazos. De la misma forma el cliente tiene la obligación de manejar el ámbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteración.

83

El ciclo de vida ideal de XP consiste de seis fases: Exploración, Planificación de la Entrega (Release), Iteraciones, Producción, Mantenimiento y Muerte del Proyecto.

Figura 1 Ciclo de vida de XP, fuente [8]

D. Prácticas XP La principal suposición que se realiza en XP es la posibilidad de disminuir la mítica curva exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el diseño evolutivo funcione. Esto se consigue gracias a las tecnologías disponibles para ayudar en el desarrollo de software y a la aplicación disciplinada de las siguientes prácticas. • Juego de Planeamiento. Busca determinar rápidamente el alcance de la versión

siguiente, combinando prioridades de negocio definidas por el cliente con las estimaciones técnicas de los programadores. Éstos estiman el esfuerzo necesario para implementar las historias del cliente y éste decide sobre el alcance y la agenda de las entregas. Las historias se escriben en pequeñas fichas, que algunas veces se tiran. Cuando esto sucede, lo único restante que se parece a un requerimiento es una multitud de pruebas automatizadas, las pruebas de aceptación.

• Entregas pequeñas y frecuentes. Se “produccioniza” un pequeño sistema rápidamente, al menos uno cada dos o tres meses. Pueden liberarse nuevas versiones diariamente (como es práctica en Microsoft); se agregan pocos rasgos cada vez.

• Metáforas del sistema. El sistema de define a través de una metáfora o un conjunto de metáforas, una “historia compartida” por clientes, managers y programadores que orienta todo el sistema describiendo como funciona. Una metáfora puede interpretarse como una arquitectura simplificada.

• Diseño simple. El énfasis se deposita en diseñar la solución más simple susceptible de implementarse en el momento. Se eliminan complejidades innecesarias y código extra, y se define la menor cantidad de clases posible. No debe duplicarse el código.

• Prueba continua. El desarrollo está orientado por las pruebas. Los clientes ayudan a escribir las pruebas funcionales antes de que se escriba el código. El propósito del código real no es cumplir un requerimiento, sino pasar las pruebas. Las pruebas y el código son escritas por el mismo programador, pero la prueba debería realizarse sin intervención humana, y es a todo o nada. Hay dos clases de prueba: 1) la prueba unitaria, que verifica una sola clase, o un pequeño conjunto de clases y2) la prueba de aceptación que verifica todo el sistema, o una gran parte.

84

• Refactorízación continua. Se refactoriza el sistema eliminando duplicación, mejorando la comunicación y agregando flexibilidad sin cambiar la funcionalidad La práctica también se conoce como Mejora Continua de Código o Refactorízación implacable.

• Programación en pares. Todo el código está escrito por pares de programadores. Dos personas escriben código en una computadora, turnándose en el uso del ratón y el teclado. El que no está escribiendo, piensa desde un punto de vista más estratégico y realiza lo que podría llamarse revisión de código en tiempo real. Los roles pueden cambiarse varias veces al día.

• Propiedad colectiva del código. Cualquiera puede cambiar cualquier parte del código en cualquier momento, siempre que escriba antes la prueba correspondiente.

• Integración continua. Cada pieza se integra a la base de código apenas está lista, varias veces al día. Debe correrse la prueba antes y después de la integración. Hay una máquina (solamente) dedicada a este propósito.

• Ritmo sostenible, trabajando un máximo de 8 horas por día. Antes se llamaba a esta práctica Semana de 40 horas. Dado que el desarrollo de software se considera un ejercicio creativo, se estima que hay que estar fresco y descansado para hacerlo eficientemente; con ello se motiva a los participantes, se evita la rotación del personal y se mejora la calidad del producto.

• Todo el equipo en el mismo lugar. El cliente debe estar presente y disponible a tiempo completo para el equipo. También se llama El Cliente en el Sitio. Como esto parecía no cumplirse, se especificó que el representante del cliente debe ser preferentemente un analista.

• Estándares de codificación. Se deben seguir reglas de codificación y comunicarse a través del código. Algunos practicantes se ponen de acuerdo en estilos de notación, indentación y nomenclatura, así como en un valor apreciado en la práctica, el llamado “código revelador de intenciones”.

• Espacio abierto. Es preferible una sala grande con pequeños cubículos o, mejor todavía, sin divisiones. Los pares de programadores deben estar en el centro. En la periferia se ubican las máquinas privadas.

• Reglas justas. El equipo tiene sus propias reglas a seguir, pero se pueden cambiar en cualquier momento. En XP se piensa que no existe un proceso que sirva para todos los proyectos; lo que se hace habitualmente es adaptar un conjunto de prácticas simples a las características de cada proyecto.

El mayor beneficio de las prácticas se consigue con su aplicación conjunta y equilibrada

puesto que se apoyan unas en otras. Esto se ilustra en la Figura 2, donde una línea entre dos prácticas significa que las dos prácticas se refuerzan entre sí. La mayoría de las prácticas propuestas por XP no son novedosas sino que en alguna forma ya habían sido propuestas en ingeniería del software e incluso demostrado su valor en la práctica. El mérito de XP es integrarlas de una forma efectiva y complementarlas con otras ideas desde la perspectiva del negocio, los valores humanos y el trabajo en equipo.

85

Figura 2 Las prácticas se refuerzan entre sí.

6.4.2 Metodologías Crystal [Crystal Methodologies (CM)] Las metodologías Crystal fueron creadas por el “antropólogo de proyectos” Alistair Cockburn en 1998.Se trata de un conjunto de metodologías para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo (de ellas depende el éxito del proyecto) y la reducción al máximo del número de artefactos producidos. La familia Crystal dispone un código de color para marcar la complejidad de una metodología: cuanto más oscuro un color, más “pesado” es el método. Cuanto más crítico es un sistema, más rigor se requiere. El código cromático se aplica a una forma tabular elaborada por Cockburn que se usa en muchos MAs para situar el rango de complejidad al cual se aplica una metodología. En la figura se muestra una evaluación de las pérdidas que puede ocasionar la falla de un sistema y el método requerido según este criterio. Los parámetros son Comodidad (C), Dinero Discrecional (D), Dinero Esencial (E) y Vidas (L). En otras palabras, la caída de un sistema que ocasione incomodidades indica que su nivel de criticalidad es C, mientras que si causa pérdidas de vidas su nivel es L. Los números del cuadro indican el número de personas afectadas a un proyecto, ±20%.

Los métodos se llaman Crystal evocando las facetas de una gema: cada faceta es otra versión del proceso, y todas se sitúan en torno a un núcleo idéntico. Hay cuatro variantes de metodologías: Crystal Clear (“Claro como el cristal”) para equipos de 8 o menos integrantes; Amarillo, para 8 a 20; Naranja, para 20 a 50; Rojo, para 50 a 100. Se promete seguir con Marrón, Azul y Violeta.

86

Figura 3 Familia de CrystalMethods [Crystalmethodologies.org]

La más exhaustivamente documentada es Crystal Clear (CC), puede ser usado en proyectos pequeños de categoría D6, aunque con alguna extensión se aplica también aniveles E8 a D10. El otro método elaborado en profundidad es el Naranja, apto para proyectos de duración estimada en 2 años, los otros dos aún se están desarrollando. Como casi todos los otros métodos, CC consiste en valores, técnicas y procesos.

A. Valores de cristal clear Los siete valores o propiedades de CC [9] son: 1. Entrega frecuente. Consiste en entregar, con frecuencia, software a los clientes con frecuencia, no solamente en compilar el código. La frecuencia dependerá del proyecto, pero puede ser diaria, semanal, mensual o lo que fuere. La entrega puede hacerse sin despliegue, si es que se consigue algún usuario cortés o curioso que suministre realimentación. 2. Comunicación osmótica. Todos juntos en el mismo cuarto. Una variante especial es disponer en la sala de un diseñador senior; eso se llama Experto al Alcance de la Oreja. Una reunión separada para que los concurrentes se concentren mejor es descrita como El Cono del Silencio. 3. Mejora reflexiva. Tomarse un pequeño tiempo (unas pocas horas cada algunas semanas o una vez al mes) para pensar bien qué se está haciendo, cotejar notas, reflexionar, discutir. 4. Seguridad personal. Hablar cuando algo molesta: decirle amigablemente al manager que la agenda no es realista, o a un colega que su código necesita mejorarse, o que sería conveniente que se bañase con mayor frecuencia. Esto es importante porque el equipo puede descubrir y reparar sus debilidades. No es provechoso encubrir los desacuerdos con gentileza y conciliación. Técnicamente, estas cuestiones se han caracterizado como una importante variable de confianza y han sido estudiadas con seriedad en la literatura. 5. Foco. Saber lo que se está haciendo y tener la tranquilidad y el tiempo para hacerlo. Lo primero debe venir de la comunicación sobre dirección y prioridades, típicamente con el Patrocinador Ejecutivo. Lo segundo, de un ambiente en que la gente no se vea compelida a hacer otras cosas incompatibles.

87

6. Fácil acceso a usuarios expertos. No hay un dogma de vida o muerte sobre esto, como sí lo hay en XP. Un encuentro semanal o semi-semanal con llamadas telefónicas adicionales parece ser una buena pauta. Otra variante es que los programadores se entrenen para ser usuarios durante un tiempo. El equipo de desarrollo, de todas maneras, incluye un Experto en Negocios. 7. Ambiente técnico con prueba automatizada, management de configuración e integración frecuente. Microsoft estableció la idea de los builds(se refiere tanto al proceso de conversión de archivos de código fuente en los artefactos de software independiente(s)que se pueden

ejecutar en una computadora, o el resultado de hacerlo) cotidianamente, y no es una mala práctica. Muchos equipos ágiles compilan e integran varias veces al día.

B. Técnicas En cuanto a las técnicas, se favorecen: 1. Entrevistas de proyectos. Se suele entrevistar a más de un responsable para tener visiones más ricas. La idea es averiguar cuáles son las prioridades, obtener una lista de rasgos deseados, saber cuáles son los requerimientos más críticos y cuáles los más negociables. Si se trata de una actualización o corrección, saber cuáles son las cosas que se hicieron bien y merecen preservarse y los errores que no se quieren repetir. 2. Talleres de reflexión. El equipo debe detenerse treinta minutos o una hora para reflexionar sobre sus convenciones de trabajo, discutir inconvenientes y mejoras y planear para el período siguiente. 3. Planeamiento Blitz. Una técnica puede ser el Juego de Planeamiento de XP. En este juego, se ponen tarjetas indexadas en una mesa, con una historia de usuario o función visible en cada una. El grupo finge que no hay dependencias entre tarjetas, y las alinea en secuencias de desarrollo preferidas. Los programadores escriben en cada tarjeta el tiempo estimado para desarrollar cada función. El patrocinador o embajador del usuario escribe la secuencia de prioridades, teniendo en cuenta los tiempos referidos y el valor de negocio de cada función. Las tarjetas se agrupan en períodos de tres semanas llamados iteraciones que se agrupan en entregas (releases), usualmente no más largas de tres meses. Pueden usarse tarjetas CRC. Cockburn propone otras variantes del juego, las diferencias entre la versión de Cockburn y el juego de XP son varias: en XP las tarjetas tienen historias, en CC listas de tareas; el juego de XP asume que no hay dependencias, el de CC que sí las hay; en XP hay iteraciones de duración fija, en CC no se presupone nada sobre la longitud de la iteración. 4. Estimación Delphi con estimaciones de pericia. La técnica se llama así por analogía con el oráculo de Delfos. En el proceso Delphi se reúnen los expertos responsables y proceden como en un remate para proponer el tamaño del sistema, su tiempo de ejecución, la fecha de las entregas según dependencias técnicas y de negocios y para equilibrar las entregas en paquetes de igual tamaño. 5. Encuentros diarios de pie. La palabra clave es “brevedad”, cinco a diez minutos como máximo. No se trata de discutir problemas, sino de identificarlos. Los problemas sólo se discuten en otros encuentros posteriores, con la gente que tiene que ver en ellos.

88

6. Miniatura de procesos. La “Hora Extrema” fue inventada por Peter Merel para introducir a la gente en XP en 60 minutos (http://c2.com/cgi/wiki?ExtremeHour) y proporciona lineamientos canónicos que pueden usarse para articular esta práctica. Una forma de presentar Crystal Clear puede consumir entre 90 minutos y un día. La idea es que la gente pueda “degustar” la nueva metodología. 7. Gráficos de quemado. Su nombre viene de los gráficos de quemado de calorías de los regímenes dietéticos; se usan también en Scrum. Se trata de una técnica de graficación para descubrir demoras y problemas tempranamente en el proceso, evitando que se descubra demasiado tarde aún que todavía no se sabe cuánto falta. Para ello se hace una estimación del tiempo faltante para programar lo que resta al ritmo actual, lo cual sirve para tener dominio de proyectos en los que las prioridades cambian bruscamente y con frecuencia. 8. Programación lado a lado. Mucha gente siente que la programación en pares de XP involucra una presión excesiva; la versión de Crystal Clear establece proximidad, pero cada quien se aboca a su trabajo asignado, prestando un ojo a lo que hace su compañero, quien tiene su propia máquina.

C. Procesos El proceso de Crystal Clear se basa en una exploración refinada de los inconvenientes de los modelos clásicos. Dice Cockburn que la mayoría de los modelos de proceso propuestos entre 1970 y 2000 se describían como secuencias de pasos. Aún cuando se recomendaran iteraciones e incrementos (que no hacían más que agregar confusión a la interpretación) los modelos parecían dictar un proceso en cascada, por más que los autores aseguraran que no era así. El problema con estos procesos es que realmente están describiendo un workflow requerido, un grafo de dependencia: el equipo no puede entregar un sistema hasta que está integrado y corre. No puede integrar y verificar hasta que el código no está escrito y corriendo. Y no puede diseñar y escribir el código hasta que se le dice cuáles son los requerimientos. Un grafo de dependencia se interpreta necesariamente en ese sentido, aunque no haya sido la intención original. En lugar de esta interpretación lineal, Crystal Clear enfatiza el proceso como un conjunto de ciclos anidados. En la mayoría de los proyectos se perciben siete ciclos: (1) el proyecto, (2) el ciclo de entrega de una unidad, (3) la iteración (nótese que CCrequiere múltiples entregas por proyecto pero no muchas iteraciones por entrega), (4)la semana laboral, (5) el período de integración, de 30 minutos a tres días, (6) el día de trabajo, (7) el episodio de desarrollo de una sección de código, de pocos minutos apocas horas. Los métodos Crystal no prescriben las prácticas de desarrollo, las herramientas o los productos que pueden usarse, pudiendo combinarse con otros métodos como Scrum, XP y Microsoft Solutions Framework.

89

Figura 4 Ciclos anidados de Crystal Clear

D. Roles Hay ocho roles nominados en cristal clear: 1. Patrocinador. Produce la Declaración de Misión con Prioridades de

Compromiso(Tradeoff). Consigue los recursos y define la totalidad del proyecto. 2. Usuario Experto. Junto con el Experto en Negocios produce la Lista de Actores- Objetivos y el Archivo de Casos de Uso y Requerimientos. Debe familiarizarse con el uso del sistema, sugerir atajos de teclado, modos de operación, información a visualizar simultáneamente, navegación, etcétera. 3. Diseñador Principal. Produce la Descripción Arquitectónica. Se supone que debe ser al menos un profesional de Nivel 3. (En métodos ágiles se definen tres niveles de experiencia: Nivel 1 es capaz de “seguir los procedimientos”; Nivel 2 es capaz de “apartarse de los procedimientos específicos” y encontrar otros distintos; Nivel 3 es capaz de manejar con fluidez, mezclar e inventar procedimientos). El Diseñador Principal tiene roles de coordinador, arquitecto, mentor y programador más experto. 4. Diseñador-Programador. Produce, junto con el Diseñador Principal, los Borradores de Pantallas, el Modelo Común de Dominio, las Notas y Diagramas de Diseño, el Código Fuente, el Código de Migración, las Pruebas y el Sistema Empaquetado. Cockburn no distingue entre diseñadores y programadores. Un programa en CC es “diseño y programa”; sus programadores son diseñadores-programadores. En CC un diseñador que no programe no tiene cabida. 5. Experto en Negocios. Junto con el Usuario Experto produce la Lista de Actores-Objetivos y el Archivo de Casos de Uso y Requerimientos. Debe conocer las reglas y políticas del negocio. 6. Coordinador. Con la ayuda del equipo, produce el Mapa de Proyecto, el Plan de Entrega, el Estado del Proyecto, la Lista de Riesgos, el Plan y Estado de Iteración y la Agenda de Visualización. 7. Verificador. Produce el Reporte de Bugs. Puede ser un programador en tiempo parcial, o un equipo de varias personas. 8. Escritor. Produce el Manual de Usuario. 6.4.3 SCRUM Scrum define un proceso empírico, iterativo e incremental de desarrollo que intenta obtener ventajas respecto a los procesos definidos (cascada, espiral, prototipos, etc.) mediante la aceptación de la naturaleza caótica del desarrollo de software, y la utilización de prácticas tendientes a manejar lo impredecible y el riesgo a niveles aceptables. El mismo surge en 1986, de un artículo de la Harvard Business Review titulado “The New New Product

90

Development Game” de Hirotaka Takeuchi e Ikujiro Nonaka, que introducía las mejores prácticas más utilizadas en 10 compañías japonesas altamente innovadoras. A partir de ahí y tomando referencias al juego de rugby, Ken Scwaber y Jeff Sutherland formalizan el proceso conocido como Scrum en el año 1995. La intención de Scrum es la de maximizar la realimentación sobre el desarrollo pudiendo corregir problemas y mitigar riesgos de forma temprana. Su uso se está extendiendo cada vez más dentro de la comunidad de Metodologías Ágiles, siendo combinado con otras – como XP – para completar sus carencias. Cabe mencionar que Scrum no propone el uso de ninguna práctica de desarrollo en particular; sin embargo, es habitual emplearlo como un framework ágil de administración de proyectos que puede ser combinado con cualquiera de las metodologías mencionadas.

A. Roles Scrum define seis roles: 1. El Scrum Master. Interactúa con el cliente y el equipo. Es responsable de asegurarse que el proyecto se lleve a cabo de acuerdo con las prácticas, valores y reglas de Scrum y que progrese según lo previsto. Coordina los encuentros diarios, formula lastres preguntas canónicas y se encarga de eliminar eventuales obstáculos. Debe ser miembro del equipo y trabajar a la par de sus integrantes. 2. Propietario del Proyecto. Es el responsable oficial del proyecto, gestión, control y visibilidad de la lista de acumulación o lista de retraso del producto (productbacklog). Es elegido por el Scrum Master, el cliente y los ejecutivos a cargo. Toma las decisiones finales de las tareas asignadas al registro y convierte sus elementos en rasgos a desarrollar. 3. Equipo de Scrum. Tiene autoridad para reorganizarse y definir las acciones necesarias o sugerir la remoción de impedimentos. 4. Cliente. Participa en las tareas relacionadas con los ítems del registro. 5. Management. Está a cargo de las decisiones fundamentales y participa en la definición de los objetivos y requerimientos. Por ejemplo, selecciona al Dueño del Producto, evalúa el progreso y reduce el registro de acumulación junto con el Scrum Master. 6. Usuario. La dimensión del equipo total de Scrum no debería ser superior a diez ingenieros. El número ideal es siete, más o menos dos, una cifra canónica en ciencia cognitiva. Si hay más, lo más recomendable es formar varios equipos.

B. Ciclo de Vida El ciclo de vida de Scrum es el siguiente: 1. Pre-Juego: Planeamiento. El propósito es establecer la visión, definir expectativas y asegurarse el financiamiento. Las actividades son la escritura de la visión, el presupuesto, el registro de acumulación o retraso (backlog) del producto inicial y los ítems estimados, así como la arquitectura de alto nivel, el diseño exploratorio y los prototipos. El registro de acumulación es de alto nivel de abstracción. 2. Pre-Juego: Montaje (Staging). El propósito es identificar más requerimientos y priorizar las tareas para la primera iteración. Las actividades son planificación, diseño exploratorio y prototipos.

91

3. Juego o Desarrollo. El propósito es implementar un sistema listo para entrega en una serie de iteraciones de treinta días llamadas “corridas” (sprints). Las actividades son un encuentro de planeamiento de corridas en cada iteración, la definición del registro de acumulación de corridas y los estimados, y encuentros diarios de Scrum. 4. Pos-Juego: Liberación. El propósito es el despliegue operacional. Las actividades, documentación, entrenamiento, mercadeo y venta.

Figura 5 Ciclo de Scrum, basado en [10]

Usualmente los registros de acumulación se llevan en planillas de cálculo comunes, antes que en una herramienta sofisticada de gestión de proyectos. Los elementos del registro pueden ser prestaciones del software, funciones, corrección de bugs, mejoras requeridas y actualizaciones de tecnología. Hay un registro total del producto y otro específico para cada corrida de 30 días. En la jerga de Scrum se llaman “paquetes” a los objetos o componentes que necesitan cambiarse en la siguiente iteración.

Figura 6 Ciclo de Carrera (Sprint) de Scrum, basado en [http://www.Controlchaos.com]

92

La lista de Acumulación del Producto contiene todos los rasgos, tecnología, mejoras y lista de bugs que, a medida que se desenvuelven, constituyen las futuras entregas del producto. Los rasgos más urgentes merecerán mayor detalle, los que pueden esperar se tratarán de manera más sumaria. La lista se origina a partir de una variedad de fuentes. El grupo de mercadeo genera los rasgos y la función; la gente de ventas genera elementos que harán que el producto sea más competitivo; los de ingeniería aportarán paquetes que lo harán más robusto; el cliente ingresará debilidades o problemas que deberán resolverse. El propietario de la administración y el control del backlog en productos comerciales bien puede ser el product manager; para desarrollos in-house podría ser el project manager, o alguien designado por él. Se recomienda que una sola persona defina la prioridad de una tarea; si alguien tiene otra opinión, deberá convencer al responsable. Se estima que priorizar adecuadamente una lista de producto puede resultar difícil al principio del desarrollo, pero deviene más fácil con el correr del tiempo. Al fin de cada iteración de treinta días hay una demostración a cargo del Scrum Master. Las presentaciones en PowerPoint están prohibidas. Todos tienen que ser puntuales; si alguien llega tarde, se le cobra una multa que se destinará a obras de caridad. Es permitido usar artefactos de los métodos a los que Scrum acompañe, por ejemplo Listas de Riesgos si se utiliza UP o los Planes de Proyecto sugeridos en la disciplina de Gestión de Proyectos de Microsoft Solutions Framework. No es legal, en cambio, el uso de instrumentos tales como diagramas PERT, porque éstos parten del supuesto de que las tareas de un proyecto se pueden identificar y ordenar; en Scrum el supuesto dominante es que el desarrollo es semi-caótico, cambiante y tiene demasiado ruido como para que se le aplique un proceso definido. Algunos textos sobre Scrum establecen una arquitectura global en la fase de pre-juego; otros dicen que no hay una arquitectura global en Scrum, sino que la arquitectura y el diseño emanan de múltiples corridas [SB02]. No hay una ingeniería del software prescrita para Scrum; cada quien puede escoger entonces las prácticas de automatización, inspección de código, prueba unitaria, análisis o programación en pares que le resulten adecuadas. Es habitual que Scrum se complemente con XP; en estos casos, Scrum suministra un marco de management basado en patrones organizacionales, mientras XP constituye la práctica de programación, usualmente orientada a objetos y con fuerte uso de patrones de diseño. Uno de los nombres que se utiliza para esta alianza es XP@Scrum. Actividades para el Estudio de Modelos Ágiles de Procesos.

Actividad 1

Objetivo. Que el alumno aprecie las convergencias y divergencias en la definición de los modelos ágiles resumiendo sus características claves, los nombres de los promotores iniciales y sus fechas de aparición. Especificación. -Revisar el capitulo.

93

-Hacer una tabla mencionando los acrónimos, el tipo de modelo, las características claves, los nombres de los promotores iniciales y sus fechas de aparición de los modelos vistos. Ejemplo de Resultados.

Metodología Acrónimo Creación Tipo de modelo Característica Programación extrema

XP Beck, 1999 “Disciplina en prácticas de ingeniería”

Método ágil radical

Crystal Methods CM Cockburn, 1998 “Familia de metodologías”

Método ágil con énfasis en modelo de ciclos

Scrum Scrum Sutherland - Schwaber, 1995

“Proceso” (framework de management)

Complemento de otros métodos, ágiles o no

Actividad 2

Objetivo. Que el alumno comprenda las cualidades y características de los modelos ágiles. Especificación. -Revisar y analizar el capitulo. -Hacer un resumen de los valores, prácticas y principios de los modelos ágiles. Ejemplo de Resultados. Los Valores de AM

• Comunicación.

• Valentía.

• Retroalimentación.

• Humildad.

• Simplicidad.

Principios centrales de AM • Asumir simplicidad. • Bienvenido el cambio. • Permitir el siguiente esfuerzo es el objetivo secundario. • Cambio incremental. • Maximizar la inversión de las partes interesadas en el proyecto. • Modelar con un propósito. • Múltiples modelos. • Trabajo de calidad. • Rápida retroalimentación. • El software es el objetivo primario.

Prácticas centrales de AM • Participación activa de todos aquellos que soportan el proyecto. • Aplicar los artefactos correctos. • Propiedad colectiva. • Considerar la puesta a prueba del sistema.

94

• Crear varios modelos en paralelo. • Crear contenidos simples. • Representar los modelos de manera simple. • Presentar los modelos públicamente. • Iterar a otros artefactos. • Modelar en pequeños incrementos. • Modelar con otros. • Demuéstrelo con código. • Use las herramientas más simples.

Referencias Bibliográficas.

[1] Sridhar Nerur, Radha Kanta Mahapatra, George Mangalaraj, Challenges of migrating to agile methodologies. Communications of the ACM - Adaptive complex enterprises Volume 48 Issue 5, May 2005 [5] Kent Beck. Extreme Programming Explained: Embrace Change. Reading, Addison Wesley, 1999. [6] Letelier P., Penadés C., Metodologías ágiles para el desarrollo de Software:eXtremeProgramming (XP), Universidad Politécnica de Valencia Disponible en: http://www.willydev.net/descargas/masyxp.pdf [8] Carlos Reynoso – Método heterodoxos en Desarrollo de Software (Survey de Métodos Ágiles) [9] Alistair Cockburn. “Crystal Clear. A human-powered methodology for small teams, including The Seven Properties of Effective Software Projects”.Borrador. Humans and Technology, versión del 27 de febrero de 2002. [10]Pekka Abrahamsson. “Agile Software development methods: A minitutorial”. VTT Technical Research Centre of Finland,http://www.vtt.fi/virtual/agile/seminar2002/Abrahamsson_agile_methods_minitutorial.pdf, 2002.

6.5 Comentarios, conclusiones y actividades complementarias sobre los antecedentes y conceptos básicos de la ingeniería de software.

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 al 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

95

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 práctica a. Zona amplia libre de mediciones

• Pocos experimentos

• 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.

96

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

97

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.

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

Boeing. El

98

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

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

visionarios, al parecer ha pasado esa barrera.

99

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

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

100

Actividad 1. Reflexión sobre uso de métodos ágiles Objetivo. El alumno reflexionará sobre la eficacia de los métodos ágiles. 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 sólo 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, ya que 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 afectará la moral de los desarrolladores no-áiles.

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

101

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 al 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 a participar, de manera activa, 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 para encontrar, sobre todo en sistemas complejos.

6. ¿Enumerar 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.

• Los modelos ágiles son una manera efectiva de trabajar en conjunto para alcanzarlas necesidades de las partes interesadas en el proyecto.

• Se puede decir que el modelo ágil, es una metodología muy práctica a la hora de tener que diseñar modelados y documentación, ya que proporciona documentación, e información sobre 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. ¿Enumerar algunas limitantes de los métodos ágiles? Algunas debilidades de este modelo son:

• Combinado con la preferencia por las comunicaciones frente a frente, 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, la implementación del sistema, las operaciones del sistema, el 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 en la documentación necesarios.

102

• Sólo 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 puede 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í solas no pueden hacer que el desarrollo de software con éxito. En una organización la tecnología existente puede afectar los esfuerzos para emigrar hacia las metodologías ágiles. Para las empresas que confían únicamente en tecnologías de mainframe puede resultar difícil la emigración hacia los métodos ágiles en comparación con los que utilizan en el desarrollo Orientado a Objetos.

9. ¿Cuál de las siguientes aseveraciones es verdadera? 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

Recursos. R1) Quiz. Material descriptivo de métodos ágiles de ingeniería de software. R2) Referencia [7] R3) Internet

103

6.6 Referencias Capítulo 6. Referencias Bibliográficas. [1] SridharNerur, RadhaKantaMahapatra, George Mangalaraj Challenges of migrating to agile methodologies Communications of the ACM - Adaptive complex enterprises Volume 48 Issue 5, May 2005 [2] Desarrollo de Software mediante Metodologías Ágiles. http://www.snip.gob.ni/Xdc/Agile/Agile.htm [3] Capitulo1 Ken Schwaber, Mike Beedle Agile Software Development with Scrum Prentice Hall [4] Carlos Reynoso Métodos Ágiles en desarrollo de software UNIVERSIDAD DE BUENOS AIRES http://carlosreynoso.com.ar/archivos/arquitectura/Metodos-Agiles.PDF [5] Kent Beck. Extreme Programming Explained: Embrace Change. Reading, Addison Wesley, 1999. [6] Letelier P., Penadés C., Metodologías ágiles para el desarrollo de Software: eXtremeProgramming (XP), Universidad Politécnica de Valencia Disponible en: http://www.willydev.net/descargas/masyxp.pdf [7] GrigoriMelnik Microsoft p&p summit, 2007 Empirical Evidence Of Agile Methods http://www.slideshare.net/melnik/empirical-evidence-of-agile-methods-190997 [8] Carlos Reynoso Método heterodoxos en Desarrollo de Software (Survey de Métodos Ágiles) [9] Alistair Cockburn. “Crystal Clear. A human-powered methodology for small teams, including The Seven Properties of Effective Software Projects”.Borrador. Humans and Technology, versión del 27 de febrero de 2002. [10] PekkaAbrahamsson. “Agile Software development methods: A minitutorial”. VTT Technical Research Centre of Finland, http://www.vtt.fi/virtual/agile/seminar2002/Abrahamsson_agile_methods_minitutorial.pdf 2002.

104

Autores de la presente Publicación:

M.C. Alma Delia Ambrosio Vázquez.

ambrosio@cs.buap.mx

C.Dr. Mario Anzures García.

anzures@cs.buap.mx

Dra. Etelvina Archundia Sierra.

etelvina@solarium.cs.buap.mx

M.C. María del Rocío Boone Rojas

rboone@cs.buap.mx

Dra. Maya Carrillo Ruiz.

cmaya@solarium.cs.buap.mx

Dr. Juan Manuel González Calleros

juan.gonzalez@cs.buap.mx

Dra. Josefina Guerrero García

jguerrero@solarium.cs.buap.mx

M.C. María del Consuelo Molina García.

cmolina@cs.buap.mx

Dra. María de la Concepción Pérez de Celis Herrero.

mcpcelish@gmail.com

Dra. María Josefa Somodevilla García.

mariasg@cs.buap.mx

Con la colaboración como autor de:

M.E. María del Carmen Cerón Garnica.

mceron@cs.buap.mx

Otoño 2011

105

Colofón

Tópicos Selectos para la Enseñanza de la Ingeniería de Software: Introducción a la Ingeniería de Software.

Libro publicado electrónicamente, 3.03 MB, almacenado en un CD en formato PDF. Se terminó de reproducir el 19 de Agosto de 2011,

en el laboratorio de Bases de Datos de la Facultad de Ciencias de la Computación, ubicado en la 14 Sur y la Avenida San Claudio, Ciudad Universitaria, Puebla, Pue. Mex.

Teléfono 01-222-229 55 00 Ext. 7208. Responsable de la publicación, M.C. María del Rocío Boone Rojas.

Tiraje 50 ejemplares. No. De Páginas 105