Benemrita Universidad Autnoma de Puebla Facultad de Ciencias de la Computacin

Tpicos Selectos para la Enseanza de la Ingeniera de Software:

Introduccin a la Ingeniera de Software

Academia del rea de Bases de Datos e Ingeniera de Software

Otoo 2011
ISBN: 978-607-487-368-9

Autoridades. Dr. Enrique Agera Ibez Rector de la Benemrita Universidad Autnoma de Puebla Mtro. Jos Jaime Vzquez Lpez Vicerrector de Docencia Dr. Pedro Hugo Hernndez Tejeda Vicerrector de Investigacin y Estudios de Posgrado M.C. Marcos Gonzlez Flores Director de la Facultad de Ciencias de la Computacin Dr. Luis Carlos Altamirano Robles Secretario De investigacin y de Estudios de Posgrado M.C. Yal Galicia Hernndez Secretaria Acadmica Dr. Roberto Contreras Jurez Secretario Administrativo Revisores. M.C. Martn Estrada Analco. Prof. Jos Luis Luna Govea.
Edicin: 1ra, Otoo 2011 ISBN: 978-607-487-368-9 Benemrita Universidad Autnoma de Puebla Direccin de Fomento Editorial 4 sur 104 Puebla, Pue. Mxico. Telfono y fax 0122229-55-00

Autores y Profesores de la Academia del rea de Bases de Datos e Ingeniera de Software participantes:
M.C. Alma Delia Ambrosio Vzquez. C. Dr. Mario Anzures Garca. Dra. Etelvina Archundia Sierra. M.C. Mara del Roco Boone Rojas Dra. Maya Carrillo Ruiz. Dr. Juan Manuel Gonzlez Calleros Dra. Josefina Guerrero Garca M.C. Mara del Consuelo Molina Garca. Dra. Mara de la Concepcin Prez de Celis Herrero. Dra. Mara Josefa Somodevilla Garca.

Coordinadora del rea de Bases de Datos e Ingeniera de Software y Coordinadora de la Publicacin del Libro.
M.C. Mara del Roco Boone Rojas

Autora Colaboradora, P.I. de la Facultad de Ciencias de la Computacin, BUAP.:

M.E. Mara del Carmen Cern Garnica.

Presentacin
La comunidad de la Facultad de Ciencias de la Computacin, se ha distinguido entre cosas, por su constante preocupacin por actualizar los contenidos temticos de los planes y programas de estudio, lo cual se ha reflejado formalmente en la actualizacin de los planes y programas de estudio realizada en diferentes periodos y bajo los diversos modelos establecidos institucionalmente, tales como el modelo de crditos y recientemente el Modelo Minerva. Sin embargo, el desarrollo vertiginoso, propio del mbito de las Ciencias de la Computacin, requiere que se adopten estrategias propias que permitan atender las demandas de actualizacin de los planes y programas de estudio y que bajo las restricciones propias institucionales para oficializar tales cambios, se puedan realizar en la prctica y permitan atender adecuadamente las necesidades de preparacin 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 tpicos selectos correspondientes al desarrollo de las Ciencias de la Computacin. -Contemplar, dentro de los planes y programas de estudio, un conjunto de materias electivas, con programas que permitan la especializacin y actualizacin en las diversas lneas del conocimiento de las Ciencias de la Computacin. -Promover la participacin de los profesores en diversas actividades de actualizacin disciplinaria, profesional y docente. Tales como su incorporacin a programas de especializacin, de diplomado y de certificacin profesional, entre otros. -Promover el desarrollo o la incorporacin del personal docente en diversos proyectos de investigacin de las diferentes reas de las Ciencias de la Computacin as como su participacin activa en los diversos eventos y foros acadmicos especializados y de relevancia tanto a nivel nacional como internacional. 4

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 Ingeniera de Software de la Facultad de Ciencias de la Computacin, se ha organizado el seminario del rea, en el cual se ha propuesto como objetivo fundamental lograr unificar los materiales, mtodos, estrategias y tcnicas en la enseanza 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 educacin, debern 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 sesin de los trabajos del seminario del rea, se abordaron los contenidos de las primeras unidades del programa de la asignatura de Ingeniera de Software correspondiente a los Planes y Programas de Estudio de los Programas de Licenciatura e Ingeniera 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 bsicos de la Ingeniera de Software 2. Antecedentes y Conceptos bsicos de la Ingeniera de Software. 2.1 Propuesta de actividades de motivacin y diagnstica para el estudio de la Ingeniera de Software. 2.2 Planeacin didctica de los antecedentes y conceptos bsicos de la Ingeniera de Software. 2.3 Desarrollo de las actividades de antecedentes y conceptos bsicos de la Ingeniera de Software. 2.3.1 Conceptos y trminos de la Ingeniera de Software. 2.3.2 Antecedentes de la Ingeniera de Software. 2.3.3 El Concepto de Ingeniera de Software. 2.3.4 Factores de Calidad del Software. 5

2.4 Comentarios, Conclusiones y Actividades Complementarias sobre los antecedentes y conceptos bsicos de la Ingeniera de Software. 2.5 Referencias captulo 2.

De acuerdo al esquema de trabajo anterior, el presente texto, consta de seis captulos. Con el propsito de establecer un antecedente al marco de trabajo adoptado para el presente texto, en el captulo 1 se presenta un panorama general sobre los antecedentes y conceptos de Planeacin Didctica. En el captulo 2, se revisan los antecedentes, conceptos y trminos de la Ingeniera de Software. El ciclo de vida y las etapas del proceso de desarrollo de un proyecto de software, se aborda en el captulo 3. En el Captulo 4, se revisan los modelos Desarrollo Rpido de Aplicaciones y de Mtodos Formales. La tecnologa CASE (Ingeniera de Software Asistida por Computadora) se revisa en el Captulo 5. Finalmente y como parte de las tendencias en el desarrollo de la Ingeniera de Software, en el captulo 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 organizacin y mejora de la calidad de los trabajos acadmicos en nuestra Facultad. En particular, agradezco ampliamente la contribucin de la Dra. Etelvina Archundia S., quien nos ha proporcionado la orientacin metodolgica para el desarrollo de los mismos. As mismo, de manera especial, agradezco al M.C. Martn Estrada Analco y al Prof. Jose Luis Luna Govea, su trabajo y disposicin para realizar la revisin general de este reporte. Resalto tambin el valioso apoyo de las autoridades administrativas tanto a nivel institucional como de la Facultad que hacen posible la divulgacin y oficializacin de los resultados de estos trabajos. A cada uno ellos, expreso mi agradecimiento.

M.C. Mara del Roco Boone Rojas. Coordinadora del rea de Bases de Datos e Ingeniera de Software Facultad de Ciencias de la Computacin. Otoo 2011

Contenido
Portada Pgina Legal Autores Presentacin Captulo 1 Perspectivas de la Reforma Integral Educativa en Mxico. Etelvina Archundia Sierra, Mara del Carmen Cern Garnica. 1.1 Comentarios sobre el Proyecto Tuning en Amrica Latina.
1.2 Experiencias en Espacios Comunes en Mxico ECOES. 1.2.1Planeacin didctica en la Educacin Superior 1.2.2 Actividades de aprendizaje 1.3 Evaluacin sumativa y formativa 1.4 Referencias Captulo 1 1 2 3 4 10

12 13 13 14 15 16 17

Captulo 2 Antecedentes y Conceptos Bsicos de la Ingeniera de Software. Etelvina Archundia Sierra, Mara del Roco Boone Rojas.
2.1 Propuesta de actividades de motivacin y diagnstico para el estudio de la Ingeniera de Software. 2.2 Planeacin didctica de los antecedentes y conceptos bsicos de la Ingeniera de Software. 2.3 Desarrollo de las actividades de antecedentes y conceptos bsicos de la Ingeniera de Software. 2.3.1 Conceptos y trminos de la Ingeniera de Software. 2.3.2 Antecedentes de la Ingeniera de Software. 2.3.3 El Concepto de Ingeniera de Software. 2.3.4Factores de Calidad del Software. 2.4 Comentarios, Conclusiones y Actividades Complementarias sobre los antecedentes y conceptos bsicos de la Ingeniera de Software. 2.5 Referencias Captulo 2

18 19 21 21 22 26 27 29 29

Captulo 3 Ciclo de Vida. Alma Delia Ambrosio Vzquez, Ma. del Consuelo Molina Garca. 3.1 Propuesta de Actividades de Motivacin y Diagnstico para el Estudio de el Ciclo de vida del software. 3.2 Planeacin Didctica de Ciclo de vida en la Ingeniera de Software. 3.3 Desarrollo de las Actividades de ciclo de vida del software. 3.3.1 Conceptos y Trminos de ciclo de vida, las P`s de la Ingeniera de Software.
3.4 Comentarios, Conclusiones y Actividades Complementarias del ciclo de vida del software.

31

32 33 35 35 40 41 42

3.5 Referencias Captulo 3

Captulo 4 Los Modelos DRA y de Mtodos Formales

Mario Anzures Garca, Maya Carrillo Ruiz.

4.1 Planeacin Didctica del Modelo de Desarrollo Rpido de Aplicaciones. 4.2 Propuesta de Actividades del Modelo de Desarrollo Rpido de Aplicaciones. 4.3 Planeacin Didctica del Modelo de Mtodos Formales. 4.4 Propuesta de Actividades del Modelo de Mtodos Formales. 4.5 Referencias Captulo 4 43 44 47 48 51 52

Captulo 5 Herramientas de Ingeniera de Software Asistida por Computadora. Mara Josefa Somodevilla Garca, Mara de la Concepcin Prez de Celis Herrero, Mara del Roco Boone Rojas.
5.1 Propuesta de actividades de motivacin y diagnstico para el estudio de las Herramientas de la Ingeniera de Software Asistida por Computadora. 5.2 Planeacin didctica de los antecedentes y conceptos bsicos de las Herramientas de la Ingeniera de Software Asistida por Computadora. 5.3 Desarrollo de las actividades de antecedentes y conceptos bsicos de las Herramientas de la Ingeniera de Software Asistida por Computadora. 5.3.1 El Concepto CASE. 5.3.2 Componentes bsicos de CASE. 5.3.3 Taxonoma de Herramientas CASE. 5.3.4 Caso de Estudio. Introduccin a una Herramienta de Ingeniera de Software Asistida por Computadora. 5.4 Comentarios, Conclusiones y Actividades Complementarias sobre los antecedentes y conceptos bsicos de las Herramientas de la Ingeniera de Software Asistida por Computadora. 5.5 Referencias Captulo 5

53 57 58 58 60 61 66 68

68

Captulo 6 Modelos giles de Procesos. Josefina Guerrero Garca, Juan Manuel Gonzlez Calleros.

70

6.1 Propuesta de actividades de motivacin y diagnstico para el estudio de modelos giles de proceso. 6.2 Planeacin Didctica de modelos giles de proceso. 6.3 Desarrollo de las Actividades de Introduccin a los mtodos giles de la Ingeniera de Software. 6.3.1Introduccin a los modelos giles. 6.4 Desarrollo de las actividades de mtodos giles de la Ingeniera de Software. 6.4.1 Programacin Extrema [Extreme Programming ( XP)] 6.4.2 Metodologas Crystal [CrystalMethodologies (CM)] 6.4.3 SCRUM 6.5 Comentarios, conclusiones y actividades complementarias sobre los antecedentes y conceptos bsicos de la ingeniera de software. 6.6 Referencias Captulo 6

71 74 75 75 81 81 85 89 94 103

Captulo 1 Antecedentes y Conceptos de Planeacin Didctica.

Etelvina Archundia Sierra Mara del Carmen Cern Garnica

1. Perspectivas de la Reforma Integral Educativa en Mxico

La Secretara de Educacin Pblica ha emitido documentos para la formacin docente como lo son el desarrollo de proyectos didcticos, los cuales permiten atender diferentes aspectos que se vinculen con los aprendizajes, las relaciones docente/alumno, la organizacin de actividades y los intereses educativos en general. De esta manera, los proyectos didcticos 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 espaol favorecern el desarrollo de competencias comunicativas. Los proyectos didcticos se conforman de cuatro elementos fundamentales para su desarrollo: propsito, actividades a desarrollar, productos y evaluacin. [1]. Basndose en las investigaciones educativas y el consenso del camino que debe de seguir el sistema educativo mexicano, se han establecido acuerdos para la 10

implementacin del enfoque en competencias, el cual incide desde el nivel bsico, medio superior y superior, en donde cada nivel contempla las competencias a desarrollar, en el caso del nivel bsico se promueve la comunicacin y las habilidades del pensamiento como observar, analizar, razonar, aprender y el ser a travs de la socializacin. En el nivel medio superior se contempla: la comunicacin, el pensamiento crtico y creativo, la responsabilidad social y cvica. En la educacin superior el estudio de la propia disciplina y su relacin con el campo laboral (Vase figura 1).

Figura 1. Competencias a desarrollar de acuerdo a los niveles de estudio Fuente: Elaboracin propia de los autores

Con lo anterior se busca la articulacin curricular, en el marco de la Reforma Integral de la Educacin Bsica (RIEB), basndose 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 mltiples competencias a los maestros, de modo que stos sean agentes de cambio que contribuyan a elevar los aprendizajes en los nios, en dotarles de herramientas para el pensamiento complejo y para un desarrollo humano pleno e integral, as como competencias cvicas 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 educacin bsica y media superior se debe de continuar en la educacin 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 enseanza aprendizaje requiere de la profesionalizacin del docente para atender los retos de la educacin hoy en da, por lo que el docente universitario debe de ser competente en el dominio de los contenidos de enseanza del currculo y que desarrolle las capacidades intelectuales de pensamiento abstracto y complejo en los alumnos universitarios. Para el proceso de enseanza aprendizaje el docente debe de estudiar la forma en la cual planea, el cmo imparte y evala sus actividades en el aula. Debe de relacionar en el conocimiento disciplinar los beneficios de las corrientes pedaggicas a travs de los estudiosos como los 11

son: Jean Piaget, Bruner, Lev Vigotsky y Gagne; adems del uso de recursos de vanguardia como lo son las Tecnologas de Informacin TICs(Vase figura 2).

Figura 2: Esquema aprendizaje para el docente en la imparticin de su prctica profesional Fuente: Elaboracin propia de los autores

1.1 Comentarios sobre el Proyecto Tuning en Amrica Latina

El enfoque en competencias presentado desde las Reflexiones y Perspectivasde la Educacin Superioren Amrica Latina en el Informe Final del Proyecto Tuningen Amrica Latina durante los aos 2004-2007, muestra las propuestas de las competencias genricas, disciplinares y laborales en las diversas reas del conocimiento. Las competencias genricas son los criterios generales que se desarrollan durante los procesos de aprendizaje y su autogestin, por ejemplo: la comunicacin, aprender a aprender, aprender ser, aprender a hacer (habilidades procedimentales y tcnicas). Las competencias disciplinares se construyen por la integracin de los saberes disciplinares y su aplicacin contextual en un marco de conciencia social. La competencias laborales se relacionan con las disciplinares para la formacin y desempeo 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 participacin de 62 universidades latinoamericanas debatiendo en 4 grupos de trabajo: Administracin de Empresas, Educacin, Historia y Matemticas. En un segundo momento, dada la repercusin que alcanzaronlas actividades realizadas en el marco del proyecto y respondiendo a una demanda de los pases latinoamericanos, se incorporaron 120 nuevas universidades en 8 reas del conocimiento: Arquitectura, Derecho, Enfermera, Fsica, Geologa, Ingeniera, Medicina y Qumica. Estas 182 universidades, provenientes de 18 pases de Amrica Latina (Argentina, Brasil, Bolivia, Colombia, Costa Rica, Cuba, Chile, Ecuador, El Salvador, Guatemala, Honduras, Mxico, Nicaragua, Panam, Paraguay, Per, Uruguay y Venezuela)[3].

12

1.2 Experiencias en espacios comunes en Mxico

Las acciones mencionadas en el Proyecto Tuning se plasman en el Proyecto Experiencias en Espacios Comunes de Educacin Superior ECOES, donde participan la Universidad Nacional Autnoma de Mxico UNAM, Instituto Politcnico Nacional IPN y la Universidad Autnoma de Mxico UAM, propiciando el intercambio y la movilidad estudiantil. La colaboracin se da tambin en la educacin a distancia y en el enlace de las bibliotecas digitales [4]. Si bien el compartir experiencias docentes entre las Universidades tambin deben de crear estrategias que les permita aplicar el enfoque en competencias en la Educacin Superior en Mxico por lo que se requiere integrar los estudios realizados a la fecha en un modelo a seguir en los aspectos de: Diseo curricular, formacin docente, desarrollo de programas acadmicos, planeacin didctica, actividades de aprendizaje y evaluacin de los programas acadmicos y curriculares (vase figura 3).

Figura 3. Aspectos a atender en la Educacin Superior en Mxico Fuente: Elaboracin propia de los autores

1.2.1 Planeacin didctica en la Educacin Superior

El intercambio de experiencias entre los docentes de distintas Universidades Pblicas Mexicanas aportara en el proceso de enseanza aprendizaje una oportunidad de enriquecer la prctica 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 propiciara en los alumnos, el inters por las asignaturas de los programas acadmico y un aprecio al esfuerzo docente vislumbrado en el poder hacer para incidir en la sociedad y transformacin de la misma (Vase figura 4). 13

Figura 4 Formas de aprendizaje en educacin superior Fuente: Elaboracin propia de los autores

La planeacin didctica en la Educacin Superior requiere en un primer momento de un diagnstico que nos permita ubicar los conocimientos, experiencias y prcticas que el alumno ha generado en las asignaturas anteriores. En un segundo momento el docente debe despertar el inters y motivacin 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 tcnicas de aprendizaje y de los conocimiento disciplinares para llevarlas a cabo durante el desarrollo y ejecucin en el aula de los contenidos plasmados en los programas acadmicos. Otro aspecto a considerar es la evaluacin de las actividades de aprendizaje y de los objetivos y propsitos plasmados al principio. Las actividades de aprendizaje requieren de los recursos de vanguardia especializados en la educacin a travs de las Tecnologas de Informacin y Comunicacin TICs.

1.2.2 Actividades de aprendizaje

Para las actividades de aprendizaje se requiere del estudio de las estrategias y tcnicas en la enseanza, aunado al conocimiento disciplinar de las asignaturas. Por lo que se recomienda utilizar los mapas conceptuales, mapa mental, cuadros sinpticos, esquemas, grficos, diagramas; tambin durante las actividades de aprendizaje se sugieren tcnicas de dinmicas grupales como el Panel, Philips 6/6, Trabajos en pequeos grupos y debates. En la planeacin didctica se destacan las actividades desarrolladas en la motivacin e inters respecto al tema de estudio y en el desarrollo del mismo (vase figura 5). La actividad inicial motivacional se considera como un diagnstico a partir de los conocimientos previos del alumno mediante los recursos de un video, el dilogo, texto o 14

una imagen. En este momento el clima de confianza en el aula propicia un medio de investigacin e inters por parte del alumno respecto del tema. Para las actividadesen el desarrollo del tema se considera la bsqueda de los conocimientos disciplinarios del tema de diversas fuentes, a partir de datos, investigaciones, solucin de problemas y estudio de casos.

Actividad de desarrollo
Motivacin Diagnstica
Trabajo en equipo. Estudio de casos Solucin de problemas Investigaciones Lecturas

Conclusiones Evaluacin

Actividad inicial

Cierre

Figura 5. Actividades de inicio y desarrollo en la Planeacin didctica Fuente. Elaboracin propia de los autores

En el proceso de desarrollo el docente debe pensar en la organizacin de las actividades a travs de equipos de trabajo y de prcticas 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 transformacin de los conocimientos previos a los nuevos. El pensamiento analgico, crtico y reflexivo representa la funcionalidad del aprendizaje del tema establecido [5].

1.3

Evaluacin sumativa y formativa

La evaluacin de los aprendizajes es un proceso complejo puesto que considera la implicacin de diversas variables presentes en el aula como lo es la relacin entre el docente-alumno, las evidencias del aprendizaje, la relacin entre los alumnos, los recursos, las estrategias de aprendizaje aplicadas y la planeacin didctica. Cuando el docente integra las dimensiones mencionada debe de contemplar que la evaluacin 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 prctica profesional. A continuacin se presentan los dos tipos de evaluacin esenciales a considerar en el proceso de aprendizaje: la evaluacin sumativa y la formativa. La evaluacin sumativa debe de ser coherente con las actividades de aprendizaje establecidas durante el desarrollo de la Planeacin didctica. La evaluacin sumativa se

15

puede establecer mediante rbricas, enseanza asistida por el grupo, lista de cotejo o nota tcnica. En la evaluacin formativa el docente deber crear una gua que permita al alumno integrar sus conocimientos, habilidades y actitudes en la solucin de problemas disciplinares y aprendizaje basado en proyectos. El docente establecer los tiempos de revisin y de rbricas que le permita al alumno conocer su progreso y retroalimentacin. El ambiente que se propicia en la evaluacin formativa es de confianza y logros, permitiendo al alumno el pensamiento creativo para la innovacin.

1.4 Referencias Captulo 1

[1] Secretara de Educacin Pblica, (2009) Programas de estudio 2009. Primer grado. Educacin bsica. Primaria, Segunda edicin, 2009, Primera reimpresin, 2010, D. R. Mxico, DF pg. 31. [2] Curso Bsico de Formacin Continua para Maestros en Servicio, Planeacin didctica para el desarrollo de competencias en el aula 2010 fue elaborado en la Direccin General de Formacin Continua de Maestros en Servicio de la Subsecretara de Educacin Bsica, de la Secretara de Educacin Pblica. [3] Reflexiones y perspectivas de la Educacin Superior en Amrica Latina. Informe Final Proyecto Tuning Amrica Latina. 2004-2007.Tuning Amrica Latina: http://tuning.unideusto.org/tuningal [4] Rositas, J. y Torres, G. Diseo de planes educativos bajo un enfoque de competencias. Ed. Trillas, Mxico, 2011. [5] Garca, A. y Gmez, E. Notas del Diplomado en Planeacin y organizacin de secuencias e intervencin didcticas en torno a aprendizajes cognitivos, BUAP. Mxico, Puebla, 2011

16

Captulo 2 Antecedentes y Conceptos Bsicos de la Ingeniera de Software.

Etelvina Archundia Sierra Mara del Roco Boone Rojas

Introduccin
Los programas de estudio en computacin cuentan, actualmente, con la asignatura de Ingeniera de Software. Los docentes que imparten la asignatura estn convencidos de que a los alumnos se les debe motivar el inters por conocer y practicar las metodologas para el desarrollo de sistemas de calidad en computacin. Para que el alumno se interese en el estudio de la Ingeniera de Software el docente deber realizar una planificacin docente para que el alumno comprenda: Cul es el objeto de su estudio y por lo tanto, la necesidad de aprender su aplicacin en el campo de desarrollo de sistemas de cmputo de calidad. 17

Los aspectos que debe identificar el alumno son: el ingenio del sujeto capaz de transformar mediante la Ingeniera de Software, sistemas de cmputo de calidad al servicio de las personas y de los diversos campos de la sociedad. En el presente captulo se propone una serie de actividades de aprendizaje para que el docente pueda desarrollar en su clase los siguientes aspectos: o o o o Conceptos y trminos de la Ingeniera de Software. Antecedentes de la Ingeniera de Software. El Concepto de Ingeniera de Software. Factores de Calidad del Software.

2.1 Propuesta de Actividades de Motivacin y Diagnstico para el Estudio de la Ingeniera de Software.

Actividades Propuestas. Actividad 1 Objetivo. Que el alumno identifique, a priori, algunas de las actividades y ventajas inherentes a la Ingeniera de Software. Especificaciones. E1) Selecciona un producto de programacin 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.

18

Programa que encuentre los caminos de costo mnimo que hay entre cada par de nodos de una digrfica pesada. Requisito 2. Considerar como datos de entrada: n nmero 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 podran mejorar. Ejemplo de Resultados. Realizar una mejor planeacin de mis actividades. -Interactuar con el profesor para aclarar los requisitos. Recursos. R1) Producto de Programacin desarrollado previamente, de preferencia en un lenguaje de alto nivel.

2.2 Planeacin Didctica de los Antecedentes y Conceptos Bsicos de la Ingeniera de Software.

19

Tiempo. Se propone cubrir el tema en un intervalo de 4 hrs. Contenido. 1. 2. 3. 4. Conceptos y Trminos de la Ingeniera de Software. Antecedentes de la Ingeniera de Software. El Concepto de Ingeniera de Software. Factores de Calidad del Software.

Materiales. Referencias Bibliogrficas.

[1] Fairley Ingeniera de Software. Prentice Hall. IEEE Trans. on Software Engineering.

[2] Captulo 1
Pressman Roger S. Ingeniera de Software, Un Enfoque Prctico. Mc Graw Hill.

[3] Captulo 1
IanSommerville. Ingeniera de Software Addison Wesley.

Recursos Electrnicos. [4] Gabriel Buades Rubio. Concepto de Calidad Ingeniera de Software III Depto. De Ciencias Matemticas e Informtica. Universidad de las Islas Balares http://dmi.uib.es/~bbuades/calidad/sld016.htm Consulta: Junio 2011 [5] Xavier Ferr Grau Principios Bsicos de Usabilidad para Ingenieros Software 20

Facultad de Informtica Universidad Politcnica de Madrid http://is.ls.fi.upm.es/miembros/xavier/papers/usabilidad.pdf Consulta: Junio 2011 [6] Moiss Rodrguez 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 Bsicos de la Ingeniera de Software. 2.3.1 Conceptos y Trminos de la Ingeniera de Software.
Material de Referencia. De Pressman [2] se incluye el siguiente material:

Ingeniera.

Profesin que posee conocimientos cientficos, actividades y criterios (ingenio) para crear dispositivos, mtodos y sistemas para transformar los recursos y satisfacer mejor las necesidades de una sociedad. Conjunto de programas que se pueden ejecutar en una computadora, as como toda la informacin, utileras y recursos necesarios para su diseo, instalacin, operacin, mantenimiento y refinamiento. Disciplina que establece el uso de principios de ingeniera robustos, orientados a obtener software econmico que sea confiable y funcione de manera eficiente.

Software.

Ingeniera de Software.

Perfil del Ingeniero de Software. Diferencia entre programador e 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.

La Ingeniera de Software difiere de la programacin tradicional en que se utilizan tcnicas de ingeniera para especificar, disear, codificar, validar y mantener los productos dentro del tiempo y presupuesto establecidos para el proyecto. Adems, la ingeniera se preocupa por aspectos administrativos que quedan fuera del dominio normal de la programacin. El trmino programador se emplea para denominar a la persona preocupada y abocada a las tareas y detalles de la codificacin, empacado y modificacin de los algoritmos y estructuras de datos codificados en algn lenguaje de programacin particular. Los Ingenieros de Software estn, adems, capacitados para hacer frente a aspectos de anlisis, diseo, verificacin, prueba de programas, documentacin, mantenimiento y administracin del proyecto.

21

Actividades Propuestas. Actividad 1 Objetivo. Que el alumno identifique los trminos y conceptos elementales de la Ingeniera de software. Especificacin. E1) Revisa las referencias [1] y [2], y realiza tu propia investigacin sobre los conceptos y trminos de la ingeniera de software. -Elabora un mapa conceptual que involucre los principales trminos y conceptos de la ingeniera de software. Ejemplo tipo de Resultados. (Ver mapa conceptual en Programa de curso de la asignatura de Ingeniera de Software, Modelo MUM). Recursos. R1) Referencias [1] y [2] R2) Conexin a Internet.

2.3.2 Antecedentes de la Ingeniera de Software.

Material de Referencia. Recomendacin: Revisar Refs. [1] y [2]. A continuacin se incluye material de Pressman [2]:

22

La Crisis del Software se denomina una etapa en la que todos los programas desarrollados, se corregan cuando haba fallos o eran modificados debido a necesidades cambiantes, y que requeran de grandes esfuerzos para mantenerlos, con un costo mayor, a medida que la complejidad del software creca. En las pasadas dcadas los ejecutivos y desarrolladores se hacan 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 difcil constatar el progreso del desarrollo del software? Estas y otras preguntas manifiestan el carcter del software y la forma en que se desarrolla, estos problemas hacen necesaria la adopcin de tcnicas de Ingeniera 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 compaa de otra, es la suficiencia, exactitud y oportunidad de la informacin proporcionada por el software.

23

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. Slo que uno de ellos, cuenta con un dispositivo especial conectado a la computadora y con un Software para obtener radiografas de piezas dentales por computadora. En un par de minutos la muestra radiogrfica est en pantalla y el mdico puede obtener diferentes vistas de la placa usando este software. Adems, puede establecer una conexin a travs de internet o va modem, para enviar el archivo de la radiografa 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 radiogrfica estara lista en un par de das. El desarrollo de software se ha convertido en una industria con crecimiento vertical en los ltimos aos, hoy por hoy uno de los hombres ms ricos del mundo es el dueo de una casa de software, Microsoft. Hace un par de dcadas se sostena la teora de que los pases que posean los mejores recursos naturales estaban destinados a ser los ms ricos y poderosos del mundo, en Mxico por ejemplo, se manej la idea de que el petrleo era la gran puerta de entrada al mundo desarrollado. Indudablemente los recursos naturales tienen un papel importante en la economa de los pases, sin embargo, poco a poco se fue acuando una nueva ideologa que se sintetiza en lo siguiente: Aqul que posee la informacin y el conocimiento y hace mejor uso de l, es el que tiene el poder. Problemas del software. La planificacin y estimacin 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 insatisfaccin y falta de confianza por parte de los clientes. Los problemas anteriores son slo manifestacin 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 slo una vaga indicacin 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 ingeniera al desarrollo de software.

24

Actividades Propuestas. Actividad 1 Objetivo. Que el alumno identifique el tipo de productos de software desarrollados a partir de la segunda generacin de computadoras, cuyo tamao y complejidad result imposible de manejar sin una metodologa adecuada. Especificacin. -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 generacin de computadoras. Ejemplo de Resultados. -Sistemas de tiempo compartido. -Sistemas con multiprogramacin. -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 ingeniera de software. Especificacin. -Revisar el Cap.1 de las refs. [1] y [2]. (Ver II Planeacin, Materiales.) -Proporcionar una lista de los problemas que surgieron durante el desarrollo de los productos de programacin 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. 25

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

2.3.3 El Concepto de Ingeniera de Software.

Material de Referencia. Ref.[1]. En [1] se incluyen algunas definiciones de la Ingeniera de Software: Definicin 1 Ingeniera de Software es el estudio de los principios y metodologas para desarrollo y mantenimiento de sistemas de software [Zelkovitz, 1978] Definicin 2 Ingeniera del Software es la aplicacin prctica del conocimiento cientfico en el diseo y construccin de programas de computadora, as como de la documentacin asociada, requerida para desarrollar, operar (funcionar) y mantenerlos. Se conoce tambin como desarrollo de software o produccin de software [Bohem, 1976] ' Definicin 3 Ingeniera del Software trata del establecimiento de principios y mtodos de ingeniera, con el fin de obtener software de modo rentable, que sea fiable y trabaje en mquinas reales [Bauer,1972]. Definicin 4 La aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo, operacin (funcionamiento) y mantenimiento del software; es decir, la aplicacin de ingeniera 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, nm. 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. 26

Actividades Propuestas. Actividad 1 Objetivo: Identificar los conceptos clave asociados a la Ingeniera de Software. Especificacin. E1) Realizar una revisin y anlisis grupal de las diferentes definiciones de ingeniera de software presentadas previamente. En cada caso, sealar 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] -Descripcin de Factores. [1], Cap. 18 y en [4] y [5]. Actividad 1 Objetivo. Que el alumno identifique atributos de calidad en un producto de Programacin. Especificacin. E1) Selecciona un producto de programacin 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 mquina virtual. Recursos. 27

R1) Referencias [4] y [5]. R2) Un producto de programacin desarrollado previamente, de preferencia en un lenguaje de programacin de alto nivel. R3) Conexin a Internet. Actividad 2 Objetivo. Que el alumno identifique que es posible mejorar la calidad de sus productos de programacin. Especificaciones. E1) Desde el punto de vista del programador, indica al menos tres caractersticas de tu producto de programacin que consideres se podran mejorar. Ejemplo de Resultados. -Utilizar estructuras de datos dinmicas para la implementacin de los archivos indizados. E2) Desde el punto de vista del usuario, indica al menos tres caractersticas de tu producto de programacin que consideres se podran mejorar. Ejemplo de Resultados. -Mejorar la interfaz del usuario. -Dar ms opciones para generar otro tipo de reportes. Recursos. R1) Referencias [6] y [7]. R2) Un producto de programacin desarrollado previamente, de preferencia en un lenguaje de programacin de alto nivel. R3) Conexin 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 captulo, Mtricas, se espera que sea capaz de experimentar con al menos una de ellas). Especificaciones. E1) Realiza una bsqueda por Internet y desarrolla una breve documentacin sobre tres herramientas para evaluar factores de calidad de un producto de software. Incluye al menos los siguientes aspectos: Nombre. 28

Empresa. Propsito. Puedes organizar tus resultados en una tabla. Ejemplo de Tipo de Resultados. Nombre. KEMISKybele Environment Mesaurement Information System Empresa.KybeleConsulting. Propsito. Facilitar la medicin automatizada de la calidad de los productos software. Ej. Factores relacionados con capacidad de un producto para ser probado, de soportar actualizaciones. Recursos. R1) Conexin a internet. R2) Referencias disponibles en [6].

2.4 Comentarios, Conclusiones y Actividades Complementarias sobre los Antecedentes y Conceptos Bsicos de la Ingeniera de Software.
Se propone realizar una actividad grupal de anlisis y reflexin, relacionada con las siguientes cuestiones. -Cul es el objetivo fundamental de la Ingeniera de software? -Consideras que el desarrollo de tus productos de software que has desarrollado hasta la fecha, ha sido metodolgico y disciplinado? -Tus productos de programacin cumplen con algunos o la mayora de los factores de calidad que se han revisado? 2.5 Referencias Captulo 2
[1] Fairley Ingeniera de Software. Prentice Hall. IEEE Trans. on Software Engineering.

[2] Captulo 1

29

Pressman Roger S. Ingeniera de Software, Un Enfoque Prctico. Mc Graw Hill.

[3] Captulo 1
IanSommerville. Ingeniera de Software Addison Wesley.

Recursos Electrnicos. [4] Gabriel Buades Rubio. Concepto de Calidad Ingeniera de Software III Depto. De Ciencias Matemticas e Informtica. Universidad de las Islas Balares http://dmi.uib.es/~bbuades/calidad/sld016.htm Consulta: Junio 2011 [5] Xavier Ferr Grau Principios Bsicos de Usabilidad para Ingenieros Software Facultad de Informtica Universidad Politcnica de Madrid http://is.ls.fi.upm.es/miembros/xavier/papers/usabilidad.pdf Consulta: Junio 2011 [6] Moiss Rodrguez 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

30

Captulo 3 Ciclo de Vida.

Alma Delia Ambrosio Vzquez Ma. del Consuelo Molina Garca

Introduccin
Un modelo de ciclo de vida define el estado de las fases a travs 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.

31

Uno de los objetivos de la asignatura de ingeniera de software, es conseguir que el alumno conozca el concepto de calidad del software, que comprenda, conozca y valore la importancia del uso de metodologas de la ingeniera de software, as como de que le confiera un seguimiento durante todo el ciclo de vida del software. Tomando en cuenta que la Ingeniera de Software es el resultado de llevar la tradicional disciplina de las ingenieras al mundo de la construccin de sistemas de software es necesario el estudio de los principios y metodologas 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 intervencin didctica, que planifique las tareas de aprendizaje en los temas involucrados. En el presente captulo se propone una serie de actividades de aprendizaje para que el docente pueda desarrollar en su clase los siguientes aspectos: o Paradigmas de Programacin o Las 4 P`s de la Ingeniera de software (Proceso, Producto, Proyecto y Personas) o Metodologas de la Ingeniera de software o Ciclo de vida del software.

3.1 Propuesta de Actividades de Motivacin y Diagnstico para el Estudio del Ciclo de vida del software .

Dentro de las actividades diagnsticas en esta materia, es trascendental que el alumno conozca las conceptos bsicos como paradigmas de programacin, las 4 Ps de la Ingeniera de Software, Ciclo de Vida, Modelo, Metodologa, Calidad del Software, Planeacin y Administracin de Proyectos, Factibilidad, Viabilidad, Prototipos, y la Certificacin de Procesos.

Actividades Propuestas. Actividad 1 Objetivo. Que el alumno identifique las ventajas de aplicar las metodologas de la ingeniera de software. 32

Especificaciones. E1) Que el alumno realice una investigacin sobre el conjunto de mtodos, tcnicas y herramientas relacionadas con las metodologas de desarrollo de software. E2) Que el alumno realice una investigacin sobre las diferencias en los paradigmas de programacin. E3) Con base en un anlisis crtico-objetivo el alumno basado en un andamiaje, resuma las condiciones apropiadas para la aplicacin de metodologas de la Ingeniera de Software estructurada u orientada hacia objetos. E4) Resuelva el siguiente cuestionario: 1. Cules son las cuatro componentes P de la ingeniera de software? 2. Qu es el proceso en cascada? 3. Qu estndares existen para documentacin? 4.-Establezca las diferencias entre aplicar, o no, una metodologa de la Ingeniera de Software en el desarrollo de software. Justifica tu respuesta. Recursos. R1) Consultar bibliografa.

3.2 Planeacin Didctica de Ciclo de vida en la Ingeniera de Software.

Tiempo. Se propone cubrir el tema en un intervalo de 4 hrs. Contenido. Paradigmas de Programacin Las 4 P`s de la Ingeniera de software Metodologas de la ingeniera de software 33

 Materiales.

Ciclo de vida del software.

Referencias Bibliogrficas. [1] Captulo 1 Braude Ingeniera de Software Una perspectiva orientada a objetos Alfaomega 2003 IEEE Trans. on Software Engineering. [2] Captulo 1 Pressman Roger S. Ingeniera del Software, Un Enfoque Prctico. Mc Graw Hill. [3] Captulo 1 Ian Sommerville. Ingeniera de Software Addison Wesley. Recursos Electrnicos. [4] Gabriel Buades Rubio. Concepto de Calidad Ingeniera de Software III Depto. De Ciencias Matemticas e Informtica. Universidad de las Islas Balares http://dmi.uib.es/~bbuades/calidad/sld016.htm Consulta: Junio 2011 [5] Xavier Ferr Grau Principios Bsicos de Usabilidad para Ingenieros Software Facultad de Informtica Universidad Politcnica de Madrid http://is.ls.fi.upm.es/miembros/xavier/papers/usabilidad.pdf Consulta: Junio 2011 [6] Moiss Rodrguez Monje Calidad de Procesos y Productos Software, ISO/IEC 25000 Alarcos Quality Center 34

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 Trminos de ciclo de vida, las P`s de la Ingeniera de Software.

Material de Referencia. De Braude [1] se incluye el siguiente material: Ciclo de Vida El ciclo de vida de desarrollo de sistemas informticos puede dividirse en actividades o fases que, en general, se ajustan al esquema mostrado en el grfico. Este esquema grfico es el ciclo de vida tpico, dado que existen gran cantidad de variantes que dependen de la organizacin, del tipo de sistema que se realizar, de los gustos de los administradores, de los tiempos, etc. Las actividades tpicas del ciclo de vida son: 1- Estudio de factibilidad. 2- Anlisis (de requerimientos). 3- Diseo 4.1- Creacin de prototipos 4.2- Implementacin 5 - Validacin y prueba 6 - Operacin y mantenimiento

35

La Ingeniera de Software es el resultado de llevar la tradicional disciplina de las ingenieras al mundo de la construccin de sistemas de software. Es el estudio de los principios y metodologas para el desarrollo y mantenimiento de sistemas software.

Los desafios de la Ingenieria de Software son:

La Ing. Sw es una tecnologa estratificada

Enfoque de calidad La IS debe estar sustentada en un compromiso con la calidad (Gestin de Calidad Total, Sigma Seis, etc.) que fomente una cultura de mejora continua del proceso. 36

Procesos Define un marco de trabajo que debe establecerse para la entrega efectiva, la gestin de proyectos, el contexto en el cual se aplican los mtodos tcnicos, se generan los productos del trabajo, se establecen los fundamentos, se asegura la calidad y el manejo adecuado de cambios Mtodos: Definen los cmo para construir el software desde el punto de vista tcnico. Herramientas: Proporcionan un soporte automtico o semi-automtico para los mtodos. Herramientas CASE Mtodos: Planificacin y estimacin de proyectos. Anlisis de requisitos. Diseo. Codificacin. 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 gestin de proyectos de SW y establecen el contexto en que se aplican los mtodos tcnicos, se producen los resultados del trabajo, se asegura la calidad, etc Los mtodos: Indican cmo construir tcnicamente el SW. Las tareas que incluye son: Anlisis de requisitos. Diseo (estructuras de datos, arquitectura de programacin y procedimientos algortmicos). Pruebas. Mantenimiento. Procedimientos: Relacionan mtodos y herramientas desde un punto de vista formal. Entre otras cosas, se define la secuencia en que se aplican los mtodos 37

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 diseador sin saber de tecnologas No se puede disear el proceso sin tener en cuenta la Arquitectura El proceso tiene que ir apoyado por metodologas No se puede ser un buen director de proyecto sin saber del resto No se puede ser un buen arquitecto sin saber de tecnologa No basta con saber de tecnologa 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 bsicos relacionados con el ciclo de vida de la Ingeniera de software. Especificacin. E1) Revisar las referencias [1], [2] y [3] para realizar una investigacin sobre los conceptos y trminos de ciclo de vida. -Elaborar un mapa conceptual que represente las metodologas de la ingeniera de software. 38

Ejemplo tipo de Resultados. (Ver mapa conceptual en Programa de curso de la asignatura de Ingeniera de Software). Recursos. R1) Referencias [1] y [2] R2) Conexin a Internet. Actividad 2

Objetivo. Comprender los conceptos bsicos de la Ingeniera de software

Especificacin. E1) Revisar las referencias [1], [2] y [3] 1. Se expone por parte del profesor los conceptos bsicos de Ingeniera de Software Proceso, Producto, Personas, Proyecto, Modelo y Metodologa. 2. Se reproducir el video de Apolo 13 a partir de la escena 8 donde inicia el problema de bixido de carbono y en tierra se dan instrucciones a un equipo que trabaje con el material a disposicin de la tripulacin a fin de hacer algo para solucionar el problema. 3. Los estudiantes se renen en equipos comentan el video examinado y cada equipo se le entregan unas preguntas tales como: Es importante el proceso para la solucin de un problema? La organizacin del equipo de trabajo ayuda a la solucin? 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 verificacin 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 Ingeniera de Software). Recursos. R1) Referencias [1] y [2] 39

R2)Video, Laptop, can, plumones, pizarrn, resumen de la clase y prueba de verificacin del aprendizaje Distribucin de tiempo 25 min. Inicio de la clase (Introduccin al conocimiento) Exposicin por el profesor 35 min. Ver las escenas del video 10 min. Actividad de cada uno de los equipos genera respuestas. 20 min. Presentacin de resultados por un alumno de cada equipo 10 min. Realizar la prueba de verificacin 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 caractersticas durante el desarrollo de software. Asimismo har conciencia de la importancia de las Ps de la ingeniera de software.

Se propone realizar una actividad grupal de anlisis y reflexin, relacionada con las siguientes cuestiones. - Cul es la diferencia entre aplicar o no una metodologa de la Ingeniera de software? - Para un caso dado, es posible aplicar indistintamente paradigma estructurado u orientado a objetos? - Cmo garantizaras la calidad de tu producto de software?

40

3.5 Referencias Captulo 3

Referencias Bibliogrficas. [1] Fairley Ingeniera de Software. Prentice Hall. IEEE Trans. on Software Engineering. [2] Captulo 1 Pressman Roger S. Ingeniera de Software, Un Enfoque Prctico. Mc Graw Hill. [3] Captulo 1 IanSommerville. Ingeniera de Software Addison Wesley.

41

Captulo 4 Los Modelos DRA y de Mtodos Formales

Mario Anzures Garca Maya Carrillo Ruiz

Introduccin
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 ingeniera de software. Se selecciona un modelo de proceso para la ingeniera del software de acuerdo a la naturaleza del proyecto y de la aplicacin, los mtodos y las herramientas que se utilizan, as como los controles y entregas que se requieren. En este captulo se abordan el modelo de Desarrollo Rpido de Aplicaciones (DRA/RAD) y el Modelo de Mtodos Formales.

42

4.1 Planeacin Didctica del Modelo de Desarrollo Rpido de Aplicaciones.

Tiempo. Se propone cubrir el tema en un intervalo de 2 hrs. Contenido. Materiales. R1) Consultar bibliografa. [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. Ingeniera del Software, Un Enfoque Prctico. Mc Graw Hill. [5] Ian Sommerville. Ingeniera de Software Addison Wesley. Recursos Electrnicos. [5] Vdeo tutorial RDA en http://www.youtube.com/watch?v=gPgsKLtwJ68 Introduccin a RAD. Definiciones y elementos fundamentales de RAD.

43

Fig. 4.1 Tutorial RAD

4.2 Propuesta de Actividades del Modelo de Desarrollo Rpido de Aplicaciones.

Actividades Propuestas. Las acciones que se llevarn a cabo tienen como fin incentivar la utilizacin del modelo DRA. Actividad 1. Objetivo. Estudiar el enfoque DRA. Especificaciones. E1) Que el alumno entienda el modelo DRA Ejemplo de Resultados. En la formacin del alumno es significativo, que ste estudie, comprenda y utilice diversos modelos o metodologas relacionadas con el desarrollo de los diferentes modelos de procesos existentes en la actualidad. Uno de estos es el Modelo de Desarrollo Rpido de Aplicaciones (DRA) o RAD (Rapid Application Development), que es un proceso de desarrollo de software, creado inicialmente por James Martin en 44

1980. El mtodo comprende el desarrollo iterativo, la construccin de prototipos y el uso de utilidades CASE, enfatizando un ciclo de desarrollo extremadamente corto utilizando un enfoque de construccin 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 investigacin y redaccin de las etapas que comprende el modelo DRA. Ejemplo de Resultados. Modelado de gestin: el flujo de informacin entre las funciones de gestin se modela de forma que responda a las siguientes preguntas: Qu informacin conduce el proceso de gestin? Qu informacin se genera? Quin la genera? A dnde va la informacin? Quin la procesa? Modelado de datos: el flujo de informacin definido como parte de la fase de modelado de gestin se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las caractersticas (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 informacin necesario que implemente una funcin de gestin. Las descripciones del proceso se crean para aadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicacin entre los objetos. Generacin de aplicaciones: El DRA asume la utilizacin de tcnicas de cuarta generacin. En lugar de crear software con lenguajes de programacin de tercera generacin, 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 automticas para facilitar la construccin del software. Pruebas de entrega: Como el proceso DRA enfatiza la reutilizacin, 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.

45

Fig. 4.2 Modelo DRA E3) Que el alumno realice una investigacin sobre las ventajas y desventajas del modelo DRA. Ejemplo de Resultados. Ventajas de RAD Comprar puede ahorrar dinero en comparacin con construir. Los entregables pueden ser fcilmente trasladados a otra plataforma. El desarrollo se realiza a un nivel de abstraccin mayor. Visibilidad temprana. Mayor flexibilidad. Menor codificacin manual. Mayor involucramiento de los usuarios. Posiblemente menos fallas. Posiblemente menor costo. Ciclos de desarrollo ms pequeos. Interfaz grfica estndar. Desventajas de RAD Comprar puede ser ms caro que construir. 46

Costo de herramientas integradas y equipo necesario. Progreso ms difcil de medir. Menos eficiente. Menor precisin cientfica. Riesgo de revertirse a las prcticas sin control de antao. Ms fallas. Prototipos pueden no escalar. Funciones reducidas (por "timeboxing"). Dependencia en componentes de terceros. E3) Con base en un anlisis crtico-objetivo el alumno debe resumir las condiciones apropiadas para la aplicacin de modelos DRA. RAD se aplica cuando: La aplicacin funcionar de manera independiente. Se pueden usar principalmente bibliotecas existentes. Desempeo no crtico. Distribucin limitada, interna o vertical. Alcance del proyecto limitado. Confiabilidad no crtica. El sistema puede dividirse en muchos mdulos independientes. El producto est dirigido a un mercado altamente especializado. El proyecto cuenta con fuertes limitantes de tiempos parciales La tecnologa requerida tiene ms de un ao en el mercado. E4) Resuelva el siguiente cuestionario: 1. Qu es el Modelo de Desarrollo Rpido de Aplicaciones? 2. Cules son las Fases del Modelo del Desarrollo Rpido de Aplicaciones? 3. Mencione algunas de las caractersticas del Modelo de Desarrollo rpido de Aplicaciones? 4. Cules son las ventajas del modelo de Desarrollo Rpido de Aplicaciones? 5. Cules son las desventajas del modelo de Desarrollo Rpido de Aplicaciones?

4.3 Planeacin Didctica del Modelo de Mtodos Formales.

Tiempo. Se propone cubrir el tema en un intervalo de 4 hrs. 47

Contenido. Introduccin Modelo de Mtodos Formales Formalismos matemticos usados en el Modelo de Mtodos Formales

Materiales. Referencias Bibliogrficas. [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 Electrnicos. [5] Formal Methods http://www.afm.sbu.ac.uk/

4.4 Propuesta de Actividades del Modelo de Mtodos Formales.

Actividades Propuestas. Las acciones que se llevarn a cabo tienen como fin incentivar la utilizacin del modelo de Mtodos Formales. 48

Actividad 1. Objetivo. Estudiar el modelo de Mtodos Formales. Especificaciones. E1) Que el alumno realice una investigacin y redaccin sobre el modelo de Mtodos Formales. Ejemplo de Resultados. Los mtodos formales son un conjunto de tendencias de desarrollo de software en donde la especificacin, verificacin y diseo de componentes se realiza mediante notaciones, lenguajes, herramientas y tcnicas basadas en teoras con slido fundamento matemtico 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 travs de generar especificaciones que definen el comportamiento en trminos del qu debe hacer y no del cmo lo hace. Gracias al proceso correcto de especificacin, propiedades derivadas de cada mdulo, se pueden verificar mediante tcnicas de razonamiento asociadas a los modelos formales, tales como, probadores de teoremas y verificadores de modelos. A partir de las especificaciones, la implementacin de un sistema puede ser generada de manera casi automtica. En este proceso, denominado diseo formal, es necesario garantizar que cada nivel de abstraccin generado, cumpla con las propiedades verificadas en las abstracciones de ms alto nivel. En los procesos de especificacin, los lenguajes de especificacin formal ms conocidos y utilizados son Z y VDM, los cuales han sido recomendados como un estndar oficial para la especificacin en la construccin de sistemas de software.

E2) Que el alumno realice una investigacin sobre en qu tipos de formalismo matemticos se basan los Modelos de Mtodos Formales. Ejemplo de Resultados. Los mtodos formales son un conjunto de tendencias de desarrollo de software en donde la especificacin, verificacin y diseo de componentes se realiza mediante notaciones, lenguajes, herramientas y tcnicas basadas en teoras con slido fundamento matemtico completamente funcional" dentro de periodos cortos de tiempo.

49

El trmino formal queda caracterizado por la categora de modelos matemticos utilizados. Ejemplos de formalismos son: lgica de primer orden, lgebras, redes de Petri y lgica temporal. Los formalismos basados en lgica de primer orden y teora de conjuntos permiten especificar el sistema mediante un concepto formal de estado y operaciones sobre estados. Con este propsito, datos y relaciones/funciones se describen en detalle y sus propiedades se expresan en lgica de primer orden. La semntica de los lenguajes est basada en la teora de conjuntos. Durante el diseo e implementacin del sistema, los elementos descritos matemticamente pueden modificarse preservando las caractersticas esenciales de la especificacin inicial. Los formalismos algebraicos proponen la descripcin de estructuras de datos estableciendo el nombre de los diferentes conjuntos de datos, funciones bsicas y propiedades. No hay concepto de estado modificable en el tiempo. Las propiedades se escriben mediante frmulas, generalmente, ecuaciones. Diferentes modelos semnticos se han propuesto para caracterizarlas especificaciones algebraicas: modelos iniciales, finales y laxos. Los modelos iniciales identifican trminos cuya igualdad puede ser probada desde los axiomas. Los modelos finales identifican trminos diferentes cuya desigualdad puede ser probada desde sus axiomas y los modelos laxos identifican todas las lgebras cuyos elementos pueden denotarse con trminos sin variables. Para describir sistemas (de estructuras de datos) se propone una amplia gama de operadores de composicin y parametrizacin. Los formalismos basados en redes de Petri establecen la nocin de estado de un sistema mediante lugares que pueden contener marcas. Un conjunto de transiciones (con pre y post-condiciones) describe la evolucin del sistema entendida como consumo y produccin de marcas en varios puntos de la red. Existe una extensa literatura sobre las redes de Petri y sus caracterizaciones semnticas: semntica de entrelazado y semntica basada en concurrencia real. Los formalismos basados en lgica temporal se usan para describir sistemas concurrentes y reactivos. Un aspecto comn asociado a las diferentes lgicas temporales es la nocin de tiempo y estado. Una especificacin escrita en lgica temporal describe las secuencias admisibles de estados (incluyendo estados concurrentes) para el sistema especificado. E3) Con base en un anlisis crtico-objetivo el alumno debe resumir las condiciones apropiadas para utilizar cada formalismo matemtico. E4) Resuelva el siguiente cuestionario: 1. Qu es el Modelo de Mtodos Formales? 2. Cul es la diferencia del Mtodo Formal basado en lgica de primer orden y aquel basado en lgica temporal? 50

3. Cul es la diferencia del Mtodo Formal basado en lgica de primer orden y aquel basado en redes de Petri? 4. Cul es la diferencia del Mtodo Formal basado en lgebras y aquel basado en redes de Petri? 5. Cul es la diferencia del Mtodo Formal basado en redes de Petri y aquel basado en lgica temporal?. Recursos. R1) Consultar bibliografa. 4.5 Referencias Captulo 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. Ingeniera del Software, Un Enfoque Prctico. Mc Graw Hill. [5] Ian Sommerville. Ingeniera de Software Addison Wesley.

51

Captulo 5 Herramientas de Ingeniera de Software Asistida por Computadora

Mara Josefa Somodevilla Garca Mara de la Concepcin Prez de Celis Herrero Mara del Roco Boone Rojas

Introduccin
En trminos generales, la Ingeniera de Software Asistida por Computadora (CASE) identifica al software que se utiliza para asistir a las actividades del proceso del software, tales como la Ingeniera de Requerimientos, el diseo, el desarrollo de programas y las pruebas. De tal forma que las herramientas CASE incluyen, herramientas de diseo, compiladores, herramientas para construccin de sistemas, etc.

52

La tecnologa CASE proporciona ayuda al proceso del software al automatizar algunas de sus actividades y al proporcionar informacin acerca del proceso desarrollado. Esto permite algunas mejoras en la calidad y productividad del software. En el presente captulo se revisa el objetivo y el concepto de Herramientas de Ingeniera de Software Asistida por Computadora. Para los componentes de CASE, se incluye una taxonoma de herramientas CASE y ejemplos especficos. Como caso de estudio se considera, el entorno de herramientas integradas para el diseo, administracin y desarrollo de bases de datos SQL, MySqlWorkbench.

5.1 Propuesta de Actividades de Motivacin y Diagnstica para el Estudio de las Herramientas de Ingeniera 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 Ingeniera de Software Asistida por Computadora. Especificaciones. E1) Desarrolla el diseo de una base de datos elemental, mediante el modelo ER y por medio de las facilidades de diseo o de dibujo de una herramienta de edicin bsica. Ejemplo. Considera la siguiente porcin de una Base de Datos para la Administracin de una cadena de Talleres-Mecnicos. Los talleres se identifican mediante un Nmero de Taller (NTall), tienen un Supervisor y se ubican en una Ciudad. Cada taller puede tener varios Mecnicos, los cuales se identifican por una clave NMec, y se registra su nombre y edad. Los mecnicos tienen varias Especialidades, tales como (Afinacin, Ajuste de Motor, Sistema Hidrulico, ) pero con diferentes aos de experiencia.

53

Ejemplo de Resultados.

Fig. 5.1 Diseo ER, Base de Datos Mecnicos Mecnicos-Talleres. E2) Resuelve el siguiente cuestionario: 1. Consideras que la herramienta que utilizaste fue la ms adecuada para apoyar el proceso de diseo de tu base de datos? 2. Por medio de esta herramienta y con respecto al diseo de tu base de datos, se distinguen claramente las entidades, llaves, atributos y las relaciones de tu base de datos? 3. A partir del diseo ER de tu base de datos, podras fcilmente traducirlo a un nivel lgico, 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 diseo.

54

Actividad 2

Objetivo. Que el alumno identifique, a priori, algunas de las ventajas inherentes de utilizar Herramientas de la Ingeniera de Software Asistida por Computadora. As como en este caso, el apoyo que pueden ofrecer en la formalizacin y documentacin del proceso de desarrollo de un proyecto. Considera la siguiente porcin del documento en [5], relacionado con la especificacin de Requisitos funcionales mediante la tcnica de casos de uso y para un sistema de gestin de un video club. Requisitos relacionados con el Almacenamiento de Informacin. RI03 Objetivos asociados Requisitos asociados Informacin sobre cuentas de socios OBJ02 Gestionar los socios RF01 Alta de socio RF02 Baja de socio RF05 Alquiler de cinta de vdeo RF08 Devolucin de cintas de vdeo RF09 Ingreso a cuenta RF11 Consulta de un socio RF12 Consulta de socios con pagos pendientes El sistema deber almacenar la informacin correspondiente a las cuentas de los socios del vdeoclub. En concreto: 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 tambin la pelcula alquilada y la fecha del alquiler slo presente Alta Un socio puede hacer ingresos a cuenta, por ejemplo para enviar a sus hijos por pelculas sin que stos tengan que llevar dinero

Descripcin Datos especficos

Intervalo temporal Estabilidad Comentarios

55

Fig. 5.2 Diagrama de casos de uso del subsistema Gestin de socios Especificaciones. E1. Realiza la especificacin 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 ms adecuada para apoyar la especificacin de requisitos desarrollada mediante esta tcnica? 2. Por medio de tu herramienta, y con respecto a la especificacin realizada, se podra fcilmente dar seguimiento y durante el proceso de desarrollo del proyecto a los requisitos establecidos? 3. Por medio de esta especificacin, podras fcilmente, continuar con el proceso de desarrollo del proyecto?

56

5.2 Planeacin Didctica de los Antecedentes y Conceptos Bsicos de Ingeniera de Software Asistida por Computadora.
Tiempo. Se propone cubrir el tema en un intervalo de 4 hrs. Contenido. 5. 6. 7. 8. El Concepto CASE. Componentes bsicos de CASE. Taxonoma de Herramientas CASE. Caso de Estudio. Introduccin a una Herramienta de Ingeniera de Software Asistida por Computadora.

Materiales. Referencias Bibliogrficas. [1] Captulo 29

Pressman Roger S. Ingeniera de Software, Un Enfoque Prctico. McGraw Hill.

[2] Pags. 11,79-82, 225,280.

Ian Sommerville. Ingeniera de Software Addison Wesley.

Recursos Electrnicos. [3]Lpez Quesada Juan Antonio. Herramientas CASE http://dis.um.es/~lopezquesada/documentos/tema%2013.ppt Alguna herramienta CASE. Ejemplo.MySQLWorkbench www.mysql.com/products/workbench/

57

5.3 Desarrollo de las Actividades de Antecedentes y Conceptos Bsicos de Ingeniera de Software Asistida por Computadora. 5.3.1 El Concepto CASE.
Material de Referencia. De Pressman [2]: El mejor taller de un artesano -sea mecnico, carpintero o ingeniero del software- tiene tres caractersticas fundamentales: (1) una coleccin de herramientas tiles que le ayudarn en todos los pasos de la construccin de un producto; (2) una disposicin organizada que permitir hallar rpidamente 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 ms herramientas y ms variadas, junto con un taller eficiente y organizado en el que puedan ubicarlas. El taller de ingeniera del software se denomina un entorno de apoyo integrado a proyectos y el conjunto de herramientas que llena ese taller se denomina ingeniera del software asistida por computadora (CASE). CASE proporciona al ingeniero la posibilidad de automatizar actividades manuales y de mejorar su visin general de la ingeniera. Al igual que las herramientas de ingeniera y de diseo asistidos por computadora que utilizan los ingenieros de otras disciplinas, las herramientas CASE ayudan a garantizar que la calidad se disee antes de llegar a construir el producto. En [3] se establece: Objetivos de la tecnologa CASE. INCREMENTAR Productividad del equipo. Calidad del Software. Reusabilidad del software. REDUCIR Costes de desarrollo y mantenimiento. AUTOMATIZAR Gestin del proyecto. Desarrollo del software. mantenimiento del software (Incluyendo la automatizacin y estandarizacin de la documentacin y de su mantenimiento) AUTOMATIZACIN DEL DESARROLLO DE SW.: Productividad del equipo Calidad del Software 58

INCREMENTAR Reusabilidad del software. REDUCIR Costos de desarrollo y mantenimiento. AUTOMATIZAR/SIMPLIFICAR Gestin del proyecto. Desarrollo del sw. (permitir aplicacin met. estructuradas; prototipos; desarrollo visual) Mantenimiento del software (Incluyendo la automatizacin y estandarizacin de la documentacin y de su mantenimiento) Concepto CASE (Computed Aided Software Engineering) Conjunto de herramientas y mtodos asociados que proporcionan asistencia automatizada en el proceso de desarrollo del software a lo largo de su ciclo de vida. Gestin del proyecto. (planificacin, estimacin y control) Desarrollo del software. (anlisis, diseo, implementacin, validacin) Mantenimiento del software.

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

R2) Conexin a Internet.

5.3.2Componentes bsicos de CASE.

Material de Referencia. Revisar Referencias [1] y [2]. De acuerdo a Lpez-Quesada [3]:

Fig. 5.3 Componentes CASE Interfaz grfica. Editor de textos y grficos. BD de soporte (BD del proyecto, depsito o repositorio CASE) Mecanismos de control para: acceso a componentes. (datos, cdigo, documentos, dispositivos) Compatibilidad de las herramientas. Consistencia de los productos. Deteccin de olvidos. Trazado de modificaciones. Donde la BD de soporte: 60

Rene las funciones de: Catlogo central de archivos y BDs. Diccionario de datos y procesos. Biblioteca de programas y documentacin. y es la base para: La integracin de herramientas. El mantenimiento de la integridad del sistema. La coordinacin y comparticin de informacin entre usuarios, con controles de seguridad y privilegios de acceso. El control de cambios y versiones. La estandarizacin de la documentacin. La reutilizacin del software. La gestin del proyecto (incluyendo auditoras). La incorporacin a otro sistema informtico. De una forma ms especfica en [1] se indica: Aunque se pueden obtener beneficios individualmente de las herramientas CASE que abarcan actividades de ingeniera del software por separado, la verdadera potencia de CASE solamente se puede lograr mediante la integracin. Entre los beneficios del CASE integrado (I-CASE) se incluyen: (1) una transferencia regular de informacin (modelos, programas, documentos, datos) entre una herramienta y otra, y entre un paso de ingeniera y el siguiente; (2) una reduccin del esfuerzo necesario para efectuar actividades globales tales como la gestin de configuracin de software, el control de calidad y la produccin de documentos; ( 3 ) un aumento del control del proyecto que se logra mediante una mejor planificacin, monitorizacin y comunicacin; (4) una mejor coordinacin entre los miembros del personal que estn trabajando en grandes proyectos de software.

5.3.3Taxonoma de Herramientas CASE.

Material de Referencia. De acuerdo a [1] Existe un cierto nmero de riesgos que son inherentes siempre que se intenta efectuar una categorizacin de las herramientas CASE. Existe una sutil implicacin que consiste en que para crear un entorno CASE efectivo se debern implementar todas las categoras de herramientas esto no es ni sencillo, ni cierto-. Cuando hay personas que creen que una herramienta pertenece a una categora, se puede crear cierta confusin (o contradiccin) al ubicar una herramienta especfica dentro de otra categora. Es posible que algunos lectores piensen que se ha omitido una categora completa -e1iminando por tanto un conjunto de herramientas completo e incluirlo as en el entorno CASE global-. Adems, 61

una categorizacin sencilla tiende a ser plana - esto es, no se muestra la interaccin jerrquica de las herramientas o las relaciones que existen entre ellas-. A pesar de estos riesgos, es necesario crear una taxonoma 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 funcin, por su papel como instrumentos para administradores o personal tcnico, por su utilizacin en los distintos pasos del proceso de ingeniera del software, por la arquitectura del entorno (hardware y software) que les presta su apoyo, o incluso por su origen o costo. La clasificacin de la taxonoma que se presenta a continuacin utiliza como criterio principal la funcin. Herramientas de ingeniera de procesos de negocio. Modelado de procesos y herramientas de gestin. Modelado de procesos y herramientas de gestin. Herramientas de anlisis de riesgos. Herramientas de gestin de proyectos. Herramientas de seguimiento de requisitos. Herramientas de mtricas y de gestin. Herramientas de documentacin. Herramientas de software de sistema. Herramientas de control de calidad. Herramientas de gestin de bases de datos del proyecto. Herramientas de gestin de configuracin de software. Herramientas de anlisis y diseo. Herramientas PRO/SIM. (De construccin de prototipos y simulacin). Herramientas de desarrollo y diseo de interfaz. Herramientas de construccin de prototipos. Herramientas de programacin. Herramientas de desarrollo de Webs. Herramientas de integracin y pruebas. Herramientas de anlisis esttico. Herramientas de anlisis dinmico. Herramientas de gestin de pruebas. Herramientas de pruebas cliente/servidor. Herramientas de reingeniera. En la taxonoma de [3] se incluyen ejemplos especficos dentro de algunas de sus categoras: Herramientas de anlisis y diseo.

62

Permiten crear y verificar DFDs, diagramas E/R, de clase, de estructura... Herramientas de prototipado: Diseadores de pantallas Generadores de mens Generadores de informes Lenguajes de especificacin 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 gestin de proyectos ayudan a la planificacin y seguimiento del proyecto Planificacin: agenda de desarrollo. Estimacin: costes, duracin, esfuerzo. Control: productividad, calidad. Herramientas de anlisis y diseo. Herramientas de prototipado y simulacin. Herramientas de programacin. Editores dirigidos por la sintaxis (cabeceras de subrutinas, palabras clave, indentacin, nomenclatura de variables, ...) Generadores de estructuras de programas. Entornos integrados de desarrollo para soporte de un lenguaje (editor, compilador, depurador). Herramientas de integracin y pruebas. Analizadores estticos. Depuradores. Generadores de datos. Comparadores (e.g. de archivos). Herramientas de soporte. Herramientas de mantenimiento. Ingeniera inversa. 63

Reingeniera.

En [2] se presenta un ejemplo ilustrativo de una posible clasificacin de la tecnologa CASE como ayuda para el proceso del software. Se puntualiza que la tecnologa 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 mayora de las actividades del proceso del software.

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

64

E2. Organiza en una tabla una taxonoma que resulte de la unin de los diferentes tipos de herramientas CASE que se consideran en las taxonomas de las referencias [1] [2] y [3]. Ejemplo de resultados. Tomar como referencia alguna de las taxonomas 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, propsitos y alcances. Especificaciones. E1) Realiza una bsqueda por Internet y toma como referencia la taxonoma de herramientas CASE que se ha revisado en este captulo. Desarrolla una breve documentacin sobre cinco herramientas de diferentes tipos. Incluye al menos la siguiente informacin: Nombre. Empresa. Propsito. Puedes organizar tus resultados en una tabla. Ejemplo de Tipo de Resultados.
Nombre Herramienta MySQLWorkbench. Empresa Oracle. Propsito Entorno integrado de herramientas para el administracin y desarrollo de bases de datos SQL. diseo,

Recursos. R1) Conexin a internet.

65

Actividad 3 Objetivo. Que el alumno est informado sobre las facilidades bsicas de un entorno integrado / banco de Trabajo CASE. Especificaciones. E1) Toma como referencia la investigacin realizada en la actividad anterior, selecciona un entorno integrado de herramientas CASE que sea de tu inters, realiza un breve reporte (3-5 cuartillas) sobre sus caractersticas generales y facilidades bsicas. Ejemplo de Tipo de Resultados. (Complementar informacin de Caso de Estudio de la Sig. seccin)

5.3.4Caso de Estudio. Introduccin a una Herramienta de Ingeniera de Software Asistida por Computadora.
Se propone revisar las facilidades bsicas y a nivel de introduccin de alguna herramienta de Ingeniera de Software Asistida por Computadora. Ej. Para el diseo de Bases de Datos, Para Especificacin de Requisitos/ Casos de Uso, Generador de Reportes, entre otros.

Ejemplo. Introduccin al entorno de herramientas MySQLWorkbench para el caso de diseo de bases de Datos. Se propone revisar las caractersticas generales del producto, Fig. 5.5. y a continuacin ofrecer un panorama general de las facilidades bsicas para el diseo de base de datos de la herramienta, Fig. 5.6.

66

Fig. 5.5Workbench Central.

Fig. 5.6 Herramientas para diseo visual de bases de datos en MysqlWorkbench.

67

Actividad 1. Objetivo. Que el alumno realice una experimentacin bsica con alguna herramienta CASE, en este caso para el diseo de bases de datos mediante las herramientas de Mysql Workbench. Especificaciones. E1. Considera la base de datos experimental cuyo diseo desarrollaste en la actividad 1 de la Seccin 5.1. E2. Desarrolla el diseo de tu base de datos experimental mediante las facilidades para el diseo de bases de datos de Mysql Workbench.

5.4 Comentarios, Conclusiones y Actividades Complementarias sobre los Antecedentes y Conceptos Bsicos de Ingeniera de SoftwareAsistida por Computadora.
-Se propone dar continuidad a las actividades de investigacin y experimentacin realizadas previamente. -Se propone continuar experimentando con la herramienta CASE que se ha abordado como caso de estudio. -Se propone realizar investigacin y experimentacin complementaria sobre otro tipo de herramientas CASE ms especializadas, tales como para la Admon. De Proyectos o Ingeniera Web. -Realizar una discusin grupal sobre las posibles ventajas del desarrollo de proyectos individuales y/o grupales mediante el apoyo de la tecnologa CASE.

5.5 Referencias, Captulo 5

Referencias Bibliogrficas. [1] Captulo 29 / 31
Pressman Roger S. Ingeniera de Software, Un Enfoque Prctico. McGraw Hill.

68

[2] Pags. 11,79-82, 225,280.

Ian Sommerville. Ingeniera de Software Addison Wesley.

Recursos Electrnicos. [3]Lpez-Quesada, Juan Antonio. Herramientas CASE http://dis.um.es/~lopezquesada/documentos/tema%2013.ppt [4] MySQL Workbench www.mysql.com/products/workbench/ [5] Domnguez D., R. Garca. Ejemplo de Casos de Uso, Gestin de un Video Club. http://www.dsic.upv.es/asignaturas/facultad/si/trabajos/032000.doc

69

Captulo 6 Modelos giles de Procesos.

Josefina Guerrero Garca Juan Manuel Gonzlez Calleros

Introduccin
La ingeniera de software ha evolucionado en los ltimos aos y se ha adaptado al entorno dinmico donde es usada y como tal sus mtodos han evolucionado. Es ah donde nacen los mtodos giles que promueven, entre otras cosas, la adaptacin constante y efectiva a los cambios que ocurren con las necesidades del cliente. Este captulo introduce brevemente los conceptos de los mtodos giles como una invitacin al alumno a descubrirlos a lo largo del curso. El docente tiene como objetivo motivar la importancia actual que tienen los mtodos giles y que favorecen la retencin de los conceptos relevantes al tema. La asignacin de actividades dinmicas 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 mtodos giles. En el presente captulo se propone una serie de actividades de aprendizaje para que el docente pueda desarrollar en su clase los siguientes aspectos:

70

o o o o

Modelos giles de Proceso Programacin Extrema Metodologas Cristal Scrum

6.1 Propuesta de actividades de motivacin y diagnstica para el estudio de modelos giles de proceso.
Actividades Propuestas. Actividad 1. Identificacin de limitantes de mtodos actuales de ingeniera de software Objetivo. El alumno ser capaz de identificar las limitantes de los mtodos 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 mtodo tradicional. Dar oportunidad al alumno a la reflexin 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 despus del lanzamiento, lo que result en una prdida estimada de mil quinientos millones de dlares. El problema:

71

La altitud y trayectoria del cohete es meda por un equipo de referencia inercial computarizado. Este transmita los comandos a los motores para mantener la altitud y la direccin. a. El software fall y este sistema y el sistema de soporte se apagaron b. Los comandos de diagnstico fueron transmitidos a los motores lo cuales fueron interpretados como datos reales e hicieron girar el cohete a una posicin extrema Falla de software: Un Fallo de software se produjo cuando se intent hacer una conversin de un nmero de 64 bits de punto flotante, a un entero con signo de 16 bits, lo que hizo que se desbordara la memoria. a. No haba manejador de excepciones asociado con la conversin de nmeros. Por seguridad, sto apag la computadora. b. La aplicacin de respaldo tena el mismo error as que, tambin fall. Se pudo evitar la catstrofe El software que fall fue rehusado del sistema del Ariane 4. El clculo computacional que fall no fue usado en el Ariane 5. Se tomaron decisiones en su momento: a. No quitar esta facilidad ya que podra 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 sera tan rpida 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 operacin durante las pruebas. La simulacin nunca llego a este escenario ya que no estaba en la lista de pruebas. Leccin aprendida Todo software debe ser revisado y probar que funcione No ejecutar software en sistemas crticos a menos que sea realmente necesario (por eso los aviones no llevan computadoras para controlar el avin, 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 clculos computacionales crticos, siempre tener clara la alternativa numrica a asignar en caso de error al sistema En la medida de la posibilidad hacer pruebas reales y no solo simulaciones 72

Mejorar el proceso de revisin incluyendo participantes externos y revisando todas las suposiciones que se hacen en el cdigo El diseador del Ariane 5 cometi un error elemental pero critico. Diseo un sistema complejo donde la falla de un componente simple lo hizo fallar. Errores muy graves pese a que el software estaba dirigido por mtodo formal, rgido. 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 automtico de clasificacin 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 actualizacin 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 seguan ocurriendo problemas importantes de software en un nuevo sistema de nminas ERP para un sistema escolar urbano. Se pensaba que en varias ocasiones, ms de un tercio de los empleados, haba 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 dlares, adems de otros pagos errneos. 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 nmina del sistema de ERP se retras. Segn 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 informacin sobre justicia penal y que por lo tanto, el sistema no cumpla los requisitos. El vendedor tambin demand a su subcontratista en el proyecto. Fallo de comunicacin, ausencia de interaccin con el cliente ya que seguramente al ser subcontratado no trabajaba directamente con los actores involucrados. 4. Segn informes periodsticos, 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 energa en los equipos de un vagn de pasajeros nuevo, ocasionando un sobrecalentamiento y fuego en dicho vagn, 73

la consecuente evacuacin y el cierre de parte del sistema. Falta de pruebas, liberacin 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 mtodos tradicionales de ingeniera de software. Lista de errores de software.

6.2 Planeacin Didctica de modelos agiles de proceso.

Tiempo. Se propone cubrir el tema en un intervalo de 5 hrs. 2 h. para la introduccin a los mtodos giles (seccin x.2.3) 2 h. para la descripcin de los diferentes procesos (seccin x.2.4) 1h. para consolidar el conocimiento adquirido (seccin x.2.5) Contenido. 9. Modelo giles de proceso 10. Programacin Extrema 11. Cristal 12. Scrum 13. Mel Materiales. Texto en este captulo. Metodos-Agiles.PDF nerur.pdf carlos-reynoso-metodos-agiles-academia.ppt

Referencias Bibliogrficas.
[1] SridharNerur, RadhaKantaMahapatra, George Mangalaraj Challenges of migrating to agile methodologies

Communications of the ACM - Adaptive complex enterprises Volume 48 Issue 5, May 2005

74

[2] Desarrollo de Software mediante Metodologas 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 Mtodos 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 Introduccin a los mtodos giles de la Ingeniera de Software.

6.3.1 Introduccin a los modelos giles.

Material de Referencia. Sntesis y extraccin de [4]: Los modelos de los mtodos clsicos difieren bastante en su conformacin y en su naturaleza, pero exaltan casi siempre las virtudes del planeamiento y poseen un espritu normativo. Comienzan con la licitacin y el anlisis completo de los requerimientos del usuario. Despus de un largo perodo de intensa interaccin con usuarios y clientes, los ingenieros establecen un conjunto definitivo y exhaustivo de rasgos, requerimientos funcionales y no funcionales. Esta informacin se documenta en forma de especificaciones para la segunda etapa, el diseo, 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 diseo bien documentado y finalmente, el sistema completo se prueba y se despacha.

75

Castigando sobre todo al modelo en cascada se ha publicado: Gran parte de los procedimientos actuales de adquisicin de software reposan en el supuesto de que se puede especificar de antemano un sistema satisfactorio, obtener requisitos para su construccin, construirlo e instalarlo. Pienso que este supuesto es fundamentalmente equivocado y que muchos de los problemas de adquisicin se originan en esta falacia. Descrdito 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 metodologas prescriptivas con anlisis completo de requerimientos y planificacin detallada CMM, CMMI, Spice, Bootstrap, TickIt, ISO 9000 CMM no es una metodologa ni un modelo en cascada, pero coincide con su espritu Legislacin negativa sobre conformidad con estndares de calidad Ante esa evidencia los expertos, en masa, aconsejaron el abandono de los mtodos en cascada y las normativas fuertes. Trabajaron en sus propias alternativas dinmicas, 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. Todays dynamic business 76

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 requirementsbut the traditional, plan-driven software development methodologies lack the flexibility to dynamically adjust the development process.

A comienzos del siglo XXI ante el descrdito de los mtodos tradicionales se daban las condiciones para los 17 proponentes de mtodos giles se juntaran en marzo de 2001 en Salt Lake City para discutir los nuevos mtodos. Lo que surgi de su reunin fue el Manifiesto gil de Desarrollo de Software. De donde surgen ideas como: De hecho, muchos de nosotros deseamos restaurar credibilidad a la palabra metodologa. Queremos recuperar un equilibrio. Promovemos el modelado, pero no con el fin de archivar algn diagrama en un polvoriento repositorio corporativo. Promovemos la documentacin, pero no cientos de pginas en tomos nunca mantenidos y rara vez usados. Planificamos, pero reconocemos los lmites de la planificacin en un entorno turbulento. Los individuos y la interaccin 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 ms recursos que los estrictamente necesarios tambin puede afectar negativamente. El software que funciona por encima de la documentacin abarcadora. Aunque se parte de la base de que el software sin documentacin es un desastre, la regla a seguir es no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisin importante. Estos documentos deben ser cortos y centrarse en lo fundamental. La colaboracin con el cliente por encima de la negociacin contractual. Se propone que exista una interaccin constante entre el cliente y el equipo de desarrollo. Esta colaboracin 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 tecnologa, en el equipo, etc.) determina tambin el xito o fracaso del mismo. Por lo tanto, la planificacin no debe ser estricta puesto que hay muchas variables en juego, debe ser flexible para poder adaptarse a los cambios que puedan surgir.

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

77

Aunque hay valor en los elementos a la derecha, valorizamos ms los de la izquierda. Los principios que rigen a la comunidad de mtodos giles: 1. Nuestra prioridad ms alta es satisfacer al cliente a travs 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 ms breves. 4. La gente de negocios y los desarrolladores deben trabajar juntos cotidianamente a travs 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 ms eficiente y efectiva de comunicar informacin de ida y vuelta dentro de un equipo de desarrollo es mediante la conversacin 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 atencin continua a la excelencia tcnica 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 diseos emergen de equipos que se auto organizan. 12. A intervalos regulares, el equipo reflexiona sobre la forma de ser ms efectivo, y ajusta su conducta en consecuencia.

Nerur [1] realza las diferencias entre mtodos giles y tradicionales en el siguiente grfico.

78

Los modelos giles se pueden describir como aquellos modelos que son lo suficientemente buenos, donde cumplen con las siguientes caractersticas: satisfacen un propsito, son inteligentes, son lo suficientemente precisos, son lo suficientemente detallados, aportan valor positivo y son lo ms simple posible. Para poder tener ms clara las ideas un modelo gil es ms eficiente que los modelos tradicionales, un prototipo de papel podra ser un modelo gil, un dibujo de pizarra podra ser un modelo gil, un diagrama de Visio puede ser un modelo gil o un modelo de datos fsicos podra 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 slo sea slo lo suficientemente bueno para obtener su mximo provecho. El desarrollo gil de software es un marco de trabajo conceptual de la ingeniera de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos mtodos de desarrollo gil; la mayora minimiza riesgos desarrollando software en lapsos cortos de tiempo. El software desarrollado en una unidad de tiempo es llamado una iteracin, la cual debe durar de una a cuatro semanas. Cada iteracin del ciclo de vida incluye: planificacin, anlisis de requerimientos, diseo, codificacin, revisin y documentacin. Una iteracin 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 iteracin. Al final de cada iteracin el equipo vuelve a evaluar las prioridades del proyecto. La mayora de los equipos giles estn localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento". La oficina debe incluir revisores, escritores de documentacin y ayuda, diseadores de iteracin y directores de proyecto. Los mtodos giles tambin enfatizan que el software funcional es la primera medida del progreso. 79

Actividades Propuestas. Actividad 1. Requerimientos para cambiar de un paradigma clsico a uno gil Objetivo. Que el alumno proponga los cambios organizacionales necesarios para adoptar un proceso de desarrollo gil. Especificacin. E1) Llena la siguiente tabla en equipos de 4 indicando los cambios necesarios para adoptar un proceso iterativo.
Cambio organizacional y en la administracin

Cambio en la gente

Cambio en los procesos

Cambio en la tecnologa (tcnicas y herramientas)

Ejemplo tipo de Resultados.

Cambio organizacional y en la administracin Cultura organizacional Estilo de administracin 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 caractersticas, centrado en la persona 80

 Guiado por elementos como ser: corto, iterativo, evaluativo con nfasis en la adaptabilidad Manejo de proyectos grandes y escalables Seleccin del proceso gil adecuado a la empresa
Cambio en la tecnologa (tcnicas y herramientas) Revisar que herramientas y tecnologa sean apropiadas Desarrollo de nuevas habilidades -

Recursos. R1) Referencia [1] R2) Material de esta seccin

6.4 Desarrollo de las actividades de mtodos giles de la ingeniera de software.

6.4.1 PROGRAMACIN EXTREMA [extreme programming( XP)]

Kent Beck [5] sent las bases de los patrones de diseo y XP en 1999. XP es la primera metodologa gil y la que le dio conciencia al movimiento actual de metodologas giles, se centra en potenciar las relaciones interpersonales como clave para el xito en desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en retroalimentacin continua entre el cliente y el equipo de desarrollo, comunicacin 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 tcnico. Los principios y prcticas son de sentido comn pero llevadas al extremo, de ah proviene su nombre. Las caractersticas esenciales de XP se pueden organizar en: historias de usuario, roles, proceso y prcticas. A. Las Historias de Usuario [Tarjetas de historia (StoryCards)] Son la tcnica utilizada para especificar los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las caractersticas que el sistema debe poseer, sean requisitos funcionales o no funcionales. Las tarjetas se usan para estimar prioridades, alcance y tiempo de realizacin; en caso de discrepancia, gana la estimacin ms optimista. El tratamiento de las historias de usuario es muy dinmico 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, correccin, mejora), prueba funcional, nmero de historia, prioridad tcnica y del cliente, referencia a otra historia previa, riesgo, estimacin tcnica, descripcin, notas y una lista de seguimiento con la 81

fecha, estado, cosas por terminar y comentarios. A efectos de planificacin, las historias pueden ser de una a tres semanas de tiempo de programacin (para no superar el tamao de una iteracin). Las historias de usuario son descompuestas en tareas de programacin (taskcard) y asignadas a los programadores para ser implementadas durante una iteracin. B. Roles XP Los roles de acuerdo con la propuesta original de Beck son: - Programador. El programador escribe las pruebas unitarias y produce el cdigo del sistema. - Cliente. Escribe las historias de usuario y las pruebas funcionales para validar su implementacin. Adems, asigna la prioridad a las historias de usuario y decide cules se implementan en cada iteracin centrndose 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 realimentacin 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 iteracin. - Entrenador (Coach). Es responsable del proceso global. Debe proveer guas al equipo de forma que se apliquen las prcticas XP y se siga el proceso correctamente. - Consultor. Es un miembro externo del equipo con un conocimiento especfico en algn tema necesario para el proyecto, en el que puedan surgir problemas. - Gestor (Big boss). Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinacin. 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 travs 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 implementacin. 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 ms trabajo que el estimado, ya que se perder calidad en el software o no se cumplirn los plazos. De la misma forma el cliente tiene la obligacin de manejar el mbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteracin. 82

El ciclo de vida ideal de XP consiste de seis fases: Exploracin, Planificacin de la Entrega (Release), Iteraciones, Produccin, Mantenimiento y Muerte del Proyecto.

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

D. Prcticas XP La principal suposicin que se realiza en XP es la posibilidad de disminuir la mtica curva exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el diseo evolutivo funcione. Esto se consigue gracias a las tecnologas disponibles para ayudar en el desarrollo de software y a la aplicacin disciplinada de las siguientes prcticas. Juego de Planeamiento. Busca determinar rpidamente el alcance de la versin siguiente, combinando prioridades de negocio definidas por el cliente con las estimaciones tcnicas 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 pequeas 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 aceptacin. Entregas pequeas y frecuentes. Se produccioniza un pequeo sistema rpidamente, al menos uno cada dos o tres meses. Pueden liberarse nuevas versiones diariamente (como es prctica en Microsoft); se agregan pocos rasgos cada vez. Metforas del sistema. El sistema de define a travs de una metfora o un conjunto de metforas, una historia compartida por clientes, managers y programadores que orienta todo el sistema describiendo como funciona. Una metfora puede interpretarse como una arquitectura simplificada. Diseo simple. El nfasis se deposita en disear la solucin ms simple susceptible de implementarse en el momento. Se eliminan complejidades innecesarias y cdigo extra, y se define la menor cantidad de clases posible. No debe duplicarse el cdigo. Prueba continua. El desarrollo est orientado por las pruebas. Los clientes ayudan a escribir las pruebas funcionales antes de que se escriba el cdigo. El propsito del cdigo real no es cumplir un requerimiento, sino pasar las pruebas. Las pruebas y el cdigo son escritas por el mismo programador, pero la prueba debera realizarse sin intervencin humana, y es a todo o nada. Hay dos clases de prueba: 1) la prueba unitaria, que verifica una sola clase, o un pequeo conjunto de clases y2) la prueba de aceptacin que verifica todo el sistema, o una gran parte. 83

Refactorzacin continua. Se refactoriza el sistema eliminando duplicacin, mejorando la comunicacin y agregando flexibilidad sin cambiar la funcionalidad La prctica tambin se conoce como Mejora Continua de Cdigo o Refactorzacin implacable. Programacin en pares. Todo el cdigo est escrito por pares de programadores. Dos personas escriben cdigo en una computadora, turnndose en el uso del ratn y el teclado. El que no est escribiendo, piensa desde un punto de vista ms estratgico y realiza lo que podra llamarse revisin de cdigo en tiempo real. Los roles pueden cambiarse varias veces al da. Propiedad colectiva del cdigo. Cualquiera puede cambiar cualquier parte del cdigo en cualquier momento, siempre que escriba antes la prueba correspondiente. Integracin continua. Cada pieza se integra a la base de cdigo apenas est lista, varias veces al da. Debe correrse la prueba antes y despus de la integracin. Hay una mquina (solamente) dedicada a este propsito. Ritmo sostenible, trabajando un mximo de 8 horas por da. Antes se llamaba a esta prctica 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 rotacin 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. Tambin se llama El Cliente en el Sitio. Como esto pareca no cumplirse, se especific que el representante del cliente debe ser preferentemente un analista. Estndares de codificacin. Se deben seguir reglas de codificacin y comunicarse a travs del cdigo. Algunos practicantes se ponen de acuerdo en estilos de notacin, indentacin y nomenclatura, as como en un valor apreciado en la prctica, el llamado cdigo revelador de intenciones. Espacio abierto. Es preferible una sala grande con pequeos cubculos o, mejor todava, sin divisiones. Los pares de programadores deben estar en el centro. En la periferia se ubican las mquinas 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 prcticas simples a las caractersticas de cada proyecto.

El mayor beneficio de las prcticas se consigue con su aplicacin conjunta y equilibrada puesto que se apoyan unas en otras. Esto se ilustra en la Figura 2, donde una lnea entre dos prcticas significa que las dos prcticas se refuerzan entre s. La mayora de las prcticas propuestas por XP no son novedosas sino que en alguna forma ya haban sido propuestas en ingeniera del software e incluso demostrado su valor en la prctica. El mrito 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.

84

Figura 2 Las prcticas se refuerzan entre s.

6.4.2 Metodologas Crystal [Crystal Methodologies (CM)]

Las metodologas Crystal fueron creadas por el antroplogo de proyectos Alistair Cockburn en 1998.Se trata de un conjunto de metodologas 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 reduccin al mximo del nmero de artefactos producidos. La familia Crystal dispone un cdigo de color para marcar la complejidad de una metodologa: cuanto ms oscuro un color, ms pesado es el mtodo. Cuanto ms crtico es un sistema, ms rigor se requiere. El cdigo cromtico 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 metodologa. En la figura se muestra una evaluacin de las prdidas que puede ocasionar la falla de un sistema y el mtodo requerido segn este criterio. Los parmetros son Comodidad (C), Dinero Discrecional (D), Dinero Esencial (E) y Vidas (L). En otras palabras, la cada de un sistema que ocasione incomodidades indica que su nivel de criticalidad es C, mientras que si causa prdidas de vidas su nivel es L. Los nmeros del cuadro indican el nmero de personas afectadas a un proyecto, 20%. Los mtodos se llaman Crystal evocando las facetas de una gema: cada faceta es otra versin del proceso, y todas se sitan en torno a un ncleo idntico. Hay cuatro variantes de metodologas: 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 Marrn, Azul y Violeta.

85

Figura 3 Familia de CrystalMethods [Crystalmethodologies.org]

La ms exhaustivamente documentada es Crystal Clear (CC), puede ser usado en proyectos pequeos de categora D6, aunque con alguna extensin se aplica tambin aniveles E8 a D10. El otro mtodo elaborado en profundidad es el Naranja, apto para proyectos de duracin estimada en 2 aos, los otros dos an se estn desarrollando. Como casi todos los otros mtodos, CC consiste en valores, tcnicas 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 cdigo. 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 algn usuario corts o curioso que suministre realimentacin. 2. Comunicacin osmtica. Todos juntos en el mismo cuarto. Una variante especial es disponer en la sala de un diseador senior; eso se llama Experto al Alcance de la Oreja. Una reunin separada para que los concurrentes se concentren mejor es descrita como El Cono del Silencio. 3. Mejora reflexiva. Tomarse un pequeo 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 cdigo necesita mejorarse, o que sera conveniente que se baase con mayor frecuencia. Esto es importante porque el equipo puede descubrir y reparar sus debilidades. No es provechoso encubrir los desacuerdos con gentileza y conciliacin. Tcnicamente, 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 comunicacin sobre direccin y prioridades, tpicamente con el Patrocinador Ejecutivo. Lo segundo, de un ambiente en que la gente no se vea compelida a hacer otras cosas incompatibles. 86

6. Fcil 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 telefnicas 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 tcnico con prueba automatizada, management de configuracin e integracin frecuente. Microsoft estableci la idea de los builds(se refiere tanto al proceso de
conversin de archivos de cdigo 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 prctica. Muchos equipos giles compilan e integran varias veces al da.

B. Tcnicas En cuanto a las tcnicas, se favorecen: 1. Entrevistas de proyectos. Se suele entrevistar a ms de un responsable para tener visiones ms ricas. La idea es averiguar cules son las prioridades, obtener una lista de rasgos deseados, saber cules son los requerimientos ms crticos y cules los ms negociables. Si se trata de una actualizacin o correccin, saber cules son las cosas que se hicieron bien y merecen preservarse y los errores que no se quieren repetir. 2. Talleres de reflexin. El equipo debe detenerse treinta minutos o una hora para reflexionar sobre sus convenciones de trabajo, discutir inconvenientes y mejoras y planear para el perodo siguiente. 3. Planeamiento Blitz. Una tcnica puede ser el Juego de Planeamiento de XP. En este juego, se ponen tarjetas indexadas en una mesa, con una historia de usuario o funcin 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 funcin. El patrocinador o embajador del usuario escribe la secuencia de prioridades, teniendo en cuenta los tiempos referidos y el valor de negocio de cada funcin. Las tarjetas se agrupan en perodos de tres semanas llamados iteraciones que se agrupan en entregas (releases), usualmente no ms largas de tres meses. Pueden usarse tarjetas CRC. Cockburn propone otras variantes del juego, las diferencias entre la versin 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 duracin fija, en CC no se presupone nada sobre la longitud de la iteracin. 4. Estimacin Delphi con estimaciones de pericia. La tcnica se llama as por analoga con el orculo de Delfos. En el proceso Delphi se renen los expertos responsables y proceden como en un remate para proponer el tamao del sistema, su tiempo de ejecucin, la fecha de las entregas segn dependencias tcnicas y de negocios y para equilibrar las entregas en paquetes de igual tamao. 5. Encuentros diarios de pie. La palabra clave es brevedad, cinco a diez minutos como mximo. No se trata de discutir problemas, sino de identificarlos. Los problemas slo se discuten en otros encuentros posteriores, con la gente que tiene que ver en ellos. 87

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 cannicos que pueden usarse para articular esta prctica. Una forma de presentar Crystal Clear puede consumir entre 90 minutos y un da. La idea es que la gente pueda degustar la nueva metodologa. 7. Grficos de quemado. Su nombre viene de los grficos de quemado de caloras de los regmenes dietticos; se usan tambin en Scrum. Se trata de una tcnica de graficacin para descubrir demoras y problemas tempranamente en el proceso, evitando que se descubra demasiado tarde an que todava no se sabe cunto falta. Para ello se hace una estimacin 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. Programacin lado a lado. Mucha gente siente que la programacin en pares de XP involucra una presin excesiva; la versin de Crystal Clear establece proximidad, pero cada quien se aboca a su trabajo asignado, prestando un ojo a lo que hace su compaero, quien tiene su propia mquina. C. Procesos El proceso de Crystal Clear se basa en una exploracin refinada de los inconvenientes de los modelos clsicos. Dice Cockburn que la mayora de los modelos de proceso propuestos entre 1970 y 2000 se describan como secuencias de pasos. An cuando se recomendaran iteraciones e incrementos (que no hacan ms que agregar confusin a la interpretacin) los modelos parecan dictar un proceso en cascada, por ms que los autores aseguraran que no era as. El problema con estos procesos es que realmente estn 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 cdigo no est escrito y corriendo. Y no puede disear y escribir el cdigo hasta que se le dice cules son los requerimientos. Un grafo de dependencia se interpreta necesariamente en ese sentido, aunque no haya sido la intencin original. En lugar de esta interpretacin lineal, Crystal Clear enfatiza el proceso como un conjunto de ciclos anidados. En la mayora de los proyectos se perciben siete ciclos: (1) el proyecto, (2) el ciclo de entrega de una unidad, (3) la iteracin (ntese que CCrequiere mltiples entregas por proyecto pero no muchas iteraciones por entrega), (4)la semana laboral, (5) el perodo de integracin, de 30 minutos a tres das, (6) el da de trabajo, (7) el episodio de desarrollo de una seccin de cdigo, de pocos minutos apocas horas. Los mtodos Crystal no prescriben las prcticas de desarrollo, las herramientas o los productos que pueden usarse, pudiendo combinarse con otros mtodos como Scrum, XP y Microsoft Solutions Framework.

88

Figura 4 Ciclos anidados de Crystal Clear

D. Roles Hay ocho roles nominados en cristal clear: 1. Patrocinador. Produce la Declaracin de Misin 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 ActoresObjetivos y el Archivo de Casos de Uso y Requerimientos. Debe familiarizarse con el uso del sistema, sugerir atajos de teclado, modos de operacin, informacin a visualizar simultneamente, navegacin, etctera. 3. Diseador Principal. Produce la Descripcin Arquitectnica. Se supone que debe ser al menos un profesional de Nivel 3. (En mtodos giles se definen tres niveles de experiencia: Nivel 1 es capaz de seguir los procedimientos; Nivel 2 es capaz de apartarse de los procedimientos especficos y encontrar otros distintos; Nivel 3 es capaz de manejar con fluidez, mezclar e inventar procedimientos). El Diseador Principal tiene roles de coordinador, arquitecto, mentor y programador ms experto. 4. Diseador-Programador. Produce, junto con el Diseador Principal, los Borradores de Pantallas, el Modelo Comn de Dominio, las Notas y Diagramas de Diseo, el Cdigo Fuente, el Cdigo de Migracin, las Pruebas y el Sistema Empaquetado. Cockburn no distingue entre diseadores y programadores. Un programa en CC es diseo y programa; sus programadores son diseadores-programadores. En CC un diseador que no programe no tiene cabida. 5. Experto en Negocios. Junto con el Usuario Experto produce la Lista de ActoresObjetivos y el Archivo de Casos de Uso y Requerimientos. Debe conocer las reglas y polticas 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 Iteracin y la Agenda de Visualizacin. 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 emprico, iterativo e incremental de desarrollo que intenta obtener ventajas respecto a los procesos definidos (cascada, espiral, prototipos, etc.) mediante la aceptacin de la naturaleza catica del desarrollo de software, y la utilizacin de prcticas tendientes a manejar lo impredecible y el riesgo a niveles aceptables. El mismo surge en 1986, de un artculo de la Harvard Business Review titulado The New New Product 89

Development Game de Hirotaka Takeuchi e Ikujiro Nonaka, que introduca las mejores prcticas ms utilizadas en 10 compaas 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 ao 1995. La intencin de Scrum es la de maximizar la realimentacin sobre el desarrollo pudiendo corregir problemas y mitigar riesgos de forma temprana. Su uso se est extendiendo cada vez ms dentro de la comunidad de Metodologas giles, siendo combinado con otras como XP para completar sus carencias. Cabe mencionar que Scrum no propone el uso de ninguna prctica de desarrollo en particular; sin embargo, es habitual emplearlo como un framework gil de administracin de proyectos que puede ser combinado con cualquiera de las metodologas mencionadas. A. Roles Scrum define seis roles: 1. El Scrum Master. Interacta con el cliente y el equipo. Es responsable de asegurarse que el proyecto se lleve a cabo de acuerdo con las prcticas, valores y reglas de Scrum y que progrese segn lo previsto. Coordina los encuentros diarios, formula lastres preguntas cannicas y se encarga de eliminar eventuales obstculos. Debe ser miembro del equipo y trabajar a la par de sus integrantes. 2. Propietario del Proyecto. Es el responsable oficial del proyecto, gestin, control y visibilidad de la lista de acumulacin 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 remocin 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 definicin de los objetivos y requerimientos. Por ejemplo, selecciona al Dueo del Producto, evala el progreso y reduce el registro de acumulacin junto con el Scrum Master. 6. Usuario. La dimensin del equipo total de Scrum no debera ser superior a diez ingenieros. El nmero ideal es siete, ms o menos dos, una cifra cannica en ciencia cognitiva. Si hay ms, lo ms recomendable es formar varios equipos. B. Ciclo de Vida El ciclo de vida de Scrum es el siguiente: 1. Pre-Juego: Planeamiento. El propsito es establecer la visin, definir expectativas y asegurarse el financiamiento. Las actividades son la escritura de la visin, el presupuesto, el registro de acumulacin o retraso (backlog) del producto inicial y los tems estimados, as como la arquitectura de alto nivel, el diseo exploratorio y los prototipos. El registro de acumulacin es de alto nivel de abstraccin. 2. Pre-Juego: Montaje (Staging). El propsito es identificar ms requerimientos y priorizar las tareas para la primera iteracin. Las actividades son planificacin, diseo exploratorio y prototipos.

90

3. Juego o Desarrollo. El propsito es implementar un sistema listo para entrega en una serie de iteraciones de treinta das llamadas corridas (sprints). Las actividades son un encuentro de planeamiento de corridas en cada iteracin, la definicin del registro de acumulacin de corridas y los estimados, y encuentros diarios de Scrum. 4. Pos-Juego: Liberacin. El propsito es el despliegue operacional. Las actividades, documentacin, entrenamiento, mercadeo y venta.

Figura 5 Ciclo de Scrum, basado en [10]

Usualmente los registros de acumulacin se llevan en planillas de clculo comunes, antes que en una herramienta sofisticada de gestin de proyectos. Los elementos del registro pueden ser prestaciones del software, funciones, correccin de bugs, mejoras requeridas y actualizaciones de tecnologa. Hay un registro total del producto y otro especfico para cada corrida de 30 das. En la jerga de Scrum se llaman paquetes a los objetos o componentes que necesitan cambiarse en la siguiente iteracin.

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

91

La lista de Acumulacin del Producto contiene todos los rasgos, tecnologa, mejoras y lista de bugs que, a medida que se desenvuelven, constituyen las futuras entregas del producto. Los rasgos ms urgentes merecern mayor detalle, los que pueden esperar se tratarn de manera ms sumaria. La lista se origina a partir de una variedad de fuentes. El grupo de mercadeo genera los rasgos y la funcin; la gente de ventas genera elementos que harn que el producto sea ms competitivo; los de ingeniera aportarn paquetes que lo harn ms robusto; el cliente ingresar debilidades o problemas que debern resolverse. El propietario de la administracin y el control del backlog en productos comerciales bien puede ser el product manager; para desarrollos in-house podra 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 opinin, deber convencer al responsable. Se estima que priorizar adecuadamente una lista de producto puede resultar difcil al principio del desarrollo, pero deviene ms fcil con el correr del tiempo. Al fin de cada iteracin de treinta das hay una demostracin a cargo del Scrum Master. Las presentaciones en PowerPoint estn 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 mtodos a los que Scrum acompae, por ejemplo Listas de Riesgos si se utiliza UP o los Planes de Proyecto sugeridos en la disciplina de Gestin 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 semicatico, 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 prejuego; otros dicen que no hay una arquitectura global en Scrum, sino que la arquitectura y el diseo emanan de mltiples corridas [SB02]. No hay una ingeniera del software prescrita para Scrum; cada quien puede escoger entonces las prcticas de automatizacin, inspeccin de cdigo, prueba unitaria, anlisis o programacin 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 prctica de programacin, usualmente orientada a objetos y con fuerte uso de patrones de diseo. 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 definicin de los modelos giles resumiendo sus caractersticas claves, los nombres de los promotores iniciales y sus fechas de aparicin. Especificacin. -Revisar el capitulo.

92

-Hacer una tabla mencionando los acrnimos, el tipo de modelo, las caractersticas claves, los nombres de los promotores iniciales y sus fechas de aparicin de los modelos vistos. Ejemplo de Resultados.
Metodologa
Programacin extrema Crystal Methods Scrum XP CM Scrum

Acrnimo

Creacin
Beck, 1999 Cockburn, 1998 Sutherland Schwaber, 1995

Tipo de modelo
Disciplina en prcticas de ingeniera Familia de metodologas Proceso (framework de management)

Caracterstica
Mtodo gil radical Mtodo gil con nfasis en modelo de ciclos Complemento de otros mtodos, giles o no

Actividad 2 Objetivo. Que el alumno comprenda las cualidades y caractersticas de los modelos giles. Especificacin. -Revisar y analizar el capitulo. -Hacer un resumen de los valores, prcticas y principios de los modelos giles. Ejemplo de Resultados. Los Valores de AM
Comunicacin. Valenta. Retroalimentacin. Humildad. Simplicidad. Asumir simplicidad. Bienvenido el cambio. Permitir el siguiente esfuerzo es el objetivo secundario. Cambio incremental. Maximizar la inversin de las partes interesadas en el proyecto. Modelar con un propsito. Mltiples modelos. Trabajo de calidad. Rpida retroalimentacin. El software es el objetivo primario. Participacin activa de todos aquellos que soportan el proyecto. Aplicar los artefactos correctos. Propiedad colectiva. Considerar la puesta a prueba del sistema.

Principios centrales de AM

Prcticas centrales de AM

93

Crear varios modelos en paralelo. Crear contenidos simples. Representar los modelos de manera simple. Presentar los modelos pblicamente. Iterar a otros artefactos. Modelar en pequeos incrementos. Modelar con otros. Demustrelo con cdigo. Use las herramientas ms simples.

Referencias Bibliogrficas. [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., Penads C., Metodologas giles para el desarrollo de Software:eXtremeProgramming (XP), Universidad Politcnica de Valencia Disponible en: http://www.willydev.net/descargas/masyxp.pdf [8] Carlos Reynoso Mtodo heterodoxos en Desarrollo de Software (Survey de Mtodos 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, versin 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_minituto rial.pdf, 2002.

6.5 Comentarios, conclusiones y actividades complementarias sobre los antecedentes y conceptos bsicos de la ingeniera de software.
Se propone realizar una actividad grupal de anlisis y reflexin para cerrar el estudio de mtodos giles. Debido a la novedad de las metodologas giles, muy pocos datos empricos estn disponibles en relacin con cada mtodo. El desafo ms grande para el lder del proyecto, por lo tanto, es la seleccin de un mtodo apropiado dentro de la cantidad de mtodos giles disponibles en la actualidad. Esto es muy parecido a la situacin que enfrentaron los primeros desarrolladores al adoptar la tecnologa de objetos. Aunque todos los mtodos 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 trminos de tamao 94

del equipo, la propiedad del cdigo, la duracin de cada ciclo iterativo, el nfasis de actividades de flujo al frente y de flujo inverso, y los mecanismos para una rpida retroalimentacin y adaptacin al cambio. Melnik [7] hace un estudio emprico para identificar el uso de mtodos giles en la prctica. Algunos de sus resultados son los siguientes: 1. Estado de uso en la prctica a. Zona amplia libre de mediciones Pocos experimentos Incluso menos resultados publicados Foco mnimo en recoleccin de datos Datos existentes generalmente incompletos Consultores de muy alto nivel solo transmiten ancdotas b. Experimentos existentes Muy triviales o Defectos experimentales i) Gran cantidad de variables que no pueden ser controladas ii) Pequeas muestras iii) Sujetos ajenos a la profesin iv) Conducido en un lapso breve de tiempo 2. La adopcin de esta metodologa ha sido lenta en la industria (41%)

3. Poco conocida (54 % no sabe de ella) y de los que la conocen y an no la adoptan (29%) muy pocos se encuentran en la posibilidad (7%) de adoptarla.

95

4. El tamao es importante. Cuando nos referimos al volumen de personas que trabajan en una compaa. Mientras mayor sea el nmero mayor el nivel de conocimiento de los mtodos giles.

5. Los proyecto que usan mtodos giles han logrado un nivel de madurez mayor que solo proyectos piloto

96

6. Los beneficios tangibles que se reportan, 90% incremento de productividad, 85% reduccin de defectos de software, 83% aceleracin de tiempo para poner en el mercado el producto, 66% reduccin de costo.

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

97

8. Tcnicas que son ms usadas, planeacin iterativa (65%), pruebas de unidades de desarrollo (60%), discusin diaria (55%), planeacin de entregables (54%), integracin continua (50%).

9. Las metodologas ms usadas

10. Han logrado pasar el abismo los mtodos giles y no quedar en ser algo para visionarios, al parecer ha pasado esa barrera.

98

11. Veamos ahora que industrias han adoptado los mtodos giles

12. La satisfaccin en el trabajo es mayor en un esquema gil

99

Actividad 1. Reflexin sobre uso de mtodos giles Objetivo. El alumno reflexionar sobre la eficacia de los mtodos giles. Especificaciones. Responder al cuestionario y hacer un debate en clase. Ejemplo de Resultados. 1. Los mtodos giles son buenos por las prcticas 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 mtodo gil slo 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 mtodos giles? Dificultad para conseguir personal, ya que ser muy complicado encontrar equipos de desarrolladores que funcionen en el mdelo gil. Afectar autoestima de tu personal al ser un esquema de seleccin de personal muy elitista lo cual afectar la moral de los desarrolladores no-iles. 3. Cmo se va afectada la toma de decisiones? Los desarrolladores de software y el cliente toman la mayora de las decisiones. Esto crea un ambiente plural de toma de decisiones con diferente historial, actitud, metas, y disposicin cognitiva. La toma de decisiones es ms 100

4.

5.

6.

7.

complicada comparada con un enfoque tradicional donde el administrador del proyecto toma la mayora de las decisiones. Cul es el nivel de dificultad al adoptar esta cultura de toma de decisiones? Una organizacin 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. Cmo 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. Ms an, 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. Enumerar algunas ventajas del uso de mtodos giles? Algunas fortalezas de este modelo son: Los modelos giles enfatizan las comunicaciones cara a cara en vez de la documentacin. 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 metodologa muy prctica a la hora de tener que disear modelados y documentacin, ya que proporciona documentacin, e informacin sobre cmo 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. Enumerar algunas limitantes de los mtodos giles? Algunas debilidades de este modelo son: Combinado con la preferencia por las comunicaciones frente a frente, generalmente los mtodos giles son criticados y tratados como "indisciplinados" por la falta de documentacin tcnica. Es un complemento a los mtodos existentes, no es una metodologa completa. Los modelos giles no son un proceso de desarrollo de software completo, donde no incluye las actividades de programacin, las actividades de prueba, no cubre la gestin de proyectos, la implementacin del sistema, las operaciones del sistema, el soporte del sistema u otros elementos relacionados con la realizacin de proyectos que no sean la documentacin y el modelado. Hay una falta de nfasis en el diseo y en la documentacin necesarios. 101

 Slo 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 organizacin para adoptar un enfoque gil desde el punto de vista tecnolgico? Las herramientas de soporte juegan un papel crtico en el xito de la implementacin de un software basado en la metodologa gil. Las organizaciones que busquen adoptar metodologas giles deben invertir en herramientas que apoyen y faciliten el rpido desarrollo iterativo, gestin de versiones / configuracin, refactorizacin, y otras tcnicas giles. Por supuesto, las herramientas por s solas no pueden hacer que el desarrollo de software con xito. En una organizacin la tecnologa existente puede afectar los esfuerzos para emigrar hacia las metodologas giles. Para las empresas que confan nicamente en tecnologas de mainframe puede resultar difcil la emigracin hacia los mtodos giles en comparacin con los que utilizan en el desarrollo Orientado a Objetos. 9. Cul de las siguientes aseveraciones es verdadera? a) equipos contentos equipos productivos Mito b) equipos contentos baja rotacin de personal Hecho que impacta la economa de la empresa ya que la rotacin de personal tiene un costo de 70% a200% en el salario anual de los empleados. 10. Cul 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 desarrolloFalso El diseo previo implica correccin arquitectnica y/o mejora las cualidades nofuncionales- Falso El diseo previo incide sobre la calidad del cdigo- Falso La semntica de los lenguajes de diseo mapea punto a punto sobre la semntica de los frameworks de programacin- Falso El diseo y el plan documentan el desarrollo real y/o facilitan su mantenimiento o transferencia - Falso Recursos. R1) Quiz. Material descriptivo de mtodos giles de ingeniera de software. R2) Referencia [7] R3) Internet

102

6.6 Referencias Captulo 6.

Referencias Bibliogrficas.
[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 Metodologas 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 Mtodos 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., Penads C., Metodologas giles para el desarrollo de Software: eXtremeProgramming (XP), Universidad Politcnica 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 Mtodo heterodoxos en Desarrollo de Software (Survey de Mtodos 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, versin 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.

103

Autores de la presente Publicacin:

M.C. Alma Delia Ambrosio Vzquez.
ambrosio@cs.buap.mx

C.Dr. Mario Anzures Garca.

anzures@cs.buap.mx

Dra. Etelvina Archundia Sierra.

etelvina@solarium.cs.buap.mx

M.C. Mara del Roco Boone Rojas

rboone@cs.buap.mx

Dra. Maya Carrillo Ruiz.

cmaya@solarium.cs.buap.mx

Dr. Juan Manuel Gonzlez Calleros

juan.gonzalez@cs.buap.mx

Dra. Josefina Guerrero Garca

jguerrero@solarium.cs.buap.mx

M.C. Mara del Consuelo Molina Garca.

cmolina@cs.buap.mx

Dra. Mara de la Concepcin Prez de Celis Herrero.

mcpcelish@gmail.com

Dra. Mara Josefa Somodevilla Garca.

mariasg@cs.buap.mx

Con la colaboracin como autor de:

M.E. Mara del Carmen Cern Garnica. mceron@cs.buap.mx Otoo 2011
104

Colofn

Tpicos Selectos para la Enseanza de la Ingeniera de Software: Introduccin a la Ingeniera de Software. Libro publicado electrnicamente, 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 Computacin, ubicado en la 14 Sur y la Avenida San Claudio, Ciudad Universitaria, Puebla, Pue. Mex. Telfono 01-222-229 55 00 Ext. 7208. Responsable de la publicacin, M.C. Mara del Roco Boone Rojas. Tiraje 50 ejemplares. No. De Pginas 105

105