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

Benemérita Universidad Autónoma de Puebla
Facultad de Ciencias de la Computación
Tópicos Selectos para la Enseñanza de la
Ingeniería de Software:
Introducción a la Ingeniería de Software
Academia del Área de Bases de Datos e
Ingeniería de Software
Otoño 2011
ISBN: 978-607-487-368-9
Autoridades.
Dr. Enrique Agüera Ibáñez
Rector de la Benemérita Universidad Autónoma de Puebla
Mtro. José Jaime Vázquez López
Vicerrector de Docencia
Dr. Pedro Hugo Hernández Tejeda
Vicerrector de Investigación y Estudios de Posgrado
M.C. Marcos González Flores
Director de la Facultad de Ciencias de la Computación
Dr. Luis Carlos Altamirano Robles
Secretario De investigación y de Estudios de Posgrado
M.C. Yalú Galicia Hernández
Secretaria Académica
Dr. Roberto Contreras Juárez
Secretario Administrativo
Revisores.
M.C. Martín Estrada Analco.
Prof. José Luis Luna Govea.
Edición: 1ra, Otoño 2011
ISBN: 978-607-487-368-9
Benemérita Universidad Autónoma de Puebla
Dirección de Fomento Editorial
4 sur 104 Puebla, Pue. México.
Teléfono y fax 0122229-55-00
2
Autores y Profesores de la Academia del Área de Bases de Datos e
Ingeniería de Software participantes:
M.C. Alma Delia Ambrosio Vázquez.
C. Dr. Mario Anzures García.
Dra. Etelvina Archundia Sierra.
M.C. María del Rocío Boone Rojas
Dra. Maya Carrillo Ruiz.
Dr. Juan Manuel González Calleros
Dra. Josefina Guerrero García
M.C. María del Consuelo Molina García.
Dra. María de la Concepción Pérez de Celis Herrero.
Dra. María Josefa Somodevilla García.
Coordinadora del Área de Bases de Datos e Ingeniería de Software y
Coordinadora de la Publicación del Libro.
M.C. María del Rocío Boone Rojas
Autora Colaboradora, P.I. de la Facultad de Ciencias de la
Computación, BUAP.:
M.E. María del Carmen Cerón Garnica.
3
Presentación
La comunidad de la Facultad de Ciencias de la Computación, se ha distinguido
entre cosas, por su constante preocupación por actualizar los contenidos
temáticos de los planes y programas de estudio, lo cual se ha reflejado
formalmente en la actualización de los planes y programas de estudio realizada en
diferentes periodos y bajo los diversos modelos establecidos institucionalmente,
tales como el modelo de créditos y recientemente el Modelo Minerva.
Sin embargo, el desarrollo vertiginoso, propio del ámbito de las Ciencias de
la Computación, requiere que se adopten estrategias propias que permitan
atender las demandas de actualización de los planes y programas de estudio y
que bajo las restricciones propias institucionales para oficializar tales cambios, se
puedan realizar en la práctica y permitan atender adecuadamente las necesidades
de preparación actualizada de nuestros estudiantes.
En particular, en nuestra comunidad se han adoptado un conjunto de
estrategias que pretenden atender los retos anteriores, entre las cuales, se
pueden citar las siguientes:
-Incorporar, dentro de los planes y programas de estudio, asignaturas con
programas abiertos que permitan introducir tópicos selectos correspondientes al
desarrollo de las Ciencias de la Computación.
-Contemplar, dentro de los planes y programas de estudio, un conjunto de
materias electivas, con programas que permitan la especialización y actualización
en las diversas líneas del conocimiento de las Ciencias de la Computación.
-Promover la participación de los profesores en diversas actividades de
actualización disciplinaria, profesional y docente. Tales como su incorporación a
programas de especialización, de diplomado y de certificación profesional, entre
otros.
-Promover el desarrollo o la incorporación del personal docente en diversos
proyectos de investigación de las diferentes áreas de las Ciencias de la
Computación así como su participación activa en los diversos eventos y foros
académicos especializados y de relevancia tanto a nivel nacional como
internacional.
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 Ingeniería de
Software de la Facultad de Ciencias de la Computación, se ha organizado el
seminario del área, en el cual se ha propuesto como objetivo fundamental lograr
unificar los materiales, métodos, estrategias y técnicas en la enseñanza de las
asignaturas del área. Lo cual lleve por una parte a preparar los elementos
necesarios para poder enfrentar las futuras actualizaciones de los programas de
estudio, que de acuerdo a los lineamientos institucionales y propios del desarrollo
de la educación, deberán de tener un enfoque orientado al desarrollo de
competencias. Y por otra, integrar elementos necesarios para conformar a
mediano plazo nuestro repositorio de objetos de aprendizaje para las diversas
asignaturas del área.
Asimismo y con base en el planteamiento realizado en la primera sesión de
los trabajos del seminario del área, se abordaron los contenidos de las primeras
unidades del programa de
la
asignatura de “Ingeniería de Software”
correspondiente a los Planes y Programas de Estudio de los Programas de
Licenciatura e Ingeniería de la Facultad.
En el presente texto, se reportan los resultados de los trabajos
desarrollados en el
citado seminario, las experiencias compartidas y
principalmente el conjunto de actividades propuestas por cada uno de los
profesores participantes.
Para cada uno de los temas desarrollados se ha propuesto adoptar el siguiente
tipo de esquema de trabajo, en este caso correspondiente al tema de
“Antecedentes y Conceptos básicos de la Ingeniería de Software”
2. Antecedentes y Conceptos básicos de la Ingeniería de Software.
2.1 Propuesta de actividades de motivación y diagnóstica para el estudio de
la Ingeniería de Software.
2.2 Planeación didáctica de los antecedentes y conceptos básicos de la
Ingeniería de Software.
2.3 Desarrollo de las actividades de antecedentes y conceptos básicos de
la Ingeniería de Software.
2.3.1 Conceptos y términos de la Ingeniería de Software.
2.3.2 Antecedentes de la Ingeniería de Software.
2.3.3 El Concepto de Ingeniería de Software.
2.3.4 Factores de Calidad del Software.
5
2.4 Comentarios, Conclusiones y Actividades Complementarias sobre los
antecedentes y conceptos básicos de la Ingeniería de Software.
2.5 Referencias capítulo 2.
De acuerdo al esquema de trabajo anterior, el presente texto, consta de
seis capítulos. Con el propósito de establecer un antecedente al marco de trabajo
adoptado para el presente texto, en el capítulo 1 se presenta un panorama general
sobre los antecedentes y conceptos de Planeación Didáctica. En el capítulo 2, se
revisan los antecedentes, conceptos y términos de la Ingeniería de Software. El
ciclo de vida y las etapas del proceso de desarrollo de un proyecto de software,
se aborda en el capítulo 3. En el Capítulo 4, se revisan los modelos Desarrollo
Rápido de Aplicaciones y de Métodos Formales. La tecnología CASE (Ingeniería
de Software Asistida por Computadora) se revisa en el Capítulo 5. Finalmente y
como parte de las tendencias en el desarrollo de la Ingeniería de Software, en el
capítulo 6, se presentan los modelos ágiles de Procesos.
Expreso mi reconocimiento y agradecimiento a cada uno de los profesores
participantes en estos trabajos, sin duda alguna, sus valiosas experiencias en el
ejercicio docente y profesional, reflejadas en este documento, establecen ya un
precedente y referencia para la organización y mejora de la calidad de los trabajos
académicos en nuestra Facultad. En particular, agradezco ampliamente la
contribución de la Dra. Etelvina Archundia S., quien nos ha proporcionado la
orientación metodológica para el desarrollo de los mismos.
Así mismo, de manera especial, agradezco al M.C. Martín Estrada Analco y al
Prof. Jose Luis Luna Govea, su trabajo y disposición para realizar la revisión
general de este reporte.
Resalto también el valioso apoyo de las autoridades administrativas tanto a nivel
institucional como de la Facultad que hacen posible la divulgación y oficialización
de los resultados de estos trabajos. A cada uno ellos, expreso mi agradecimiento.
M.C. María del Rocío Boone Rojas.
Coordinadora del área de Bases de Datos e Ingeniería de Software
Facultad de Ciencias de la Computación.
Otoño 2011
6
Contenido
Portada
1
Página Legal
2
Autores
3
Presentación
4
Capítulo 1 Perspectivas de la Reforma Integral Educativa en México.
Etelvina Archundia Sierra, María del Carmen Cerón Garnica.
10
1.1 Comentarios sobre el Proyecto Tuning en América Latina.
12
13
13
14
15
16
1.2 Experiencias en Espacios Comunes en México ECOES.
1.2.1Planeación didáctica en la Educación Superior
1.2.2 Actividades de aprendizaje
1.3 Evaluación sumativa y formativa
1.4 Referencias Capítulo 1
Capítulo 2 Antecedentes y Conceptos Básicos de la Ingeniería de Software.
Etelvina Archundia Sierra, María del Rocío Boone Rojas.
17
2.1 Propuesta de actividades de motivación y diagnóstico para el estudio de la Ingeniería de
Software.
2.2 Planeación didáctica de los antecedentes y conceptos básicos de la Ingeniería de Software.
2.3 Desarrollo de las actividades de antecedentes y conceptos básicos de la Ingeniería de
Software.
2.3.1 Conceptos y términos de la Ingeniería de Software.
2.3.2 Antecedentes de la Ingeniería de Software.
2.3.3 El Concepto de Ingeniería de Software.
2.3.4Factores de Calidad del Software.
2.4 Comentarios, Conclusiones y Actividades Complementarias sobre los antecedentes y
conceptos básicos de la Ingeniería de Software.
2.5 Referencias Capítulo 2
18
19
21
21
22
26
27
29
29
7
Capítulo 3 Ciclo de Vida.
Alma Delia Ambrosio Vázquez, Ma. del Consuelo Molina García.
31
3.1 Propuesta de Actividades de Motivación y Diagnóstico para el Estudio de el Ciclo
de vida del software.
3.2 Planeación Didáctica de Ciclo de vida en la Ingeniería de Software.
3.3 Desarrollo de las Actividades de ciclo de vida del software.
3.3.1 Conceptos y Términos de ciclo de vida, las P`s de la Ingeniería de Software.
32
3.4 Comentarios, Conclusiones y Actividades Complementarias del ciclo de vida del
software.
33
35
35
40
3.5 Referencias Capítulo 3
41
Capítulo 4 Los Modelos DRA y de Métodos Formales
42
Mario Anzures García, Maya Carrillo Ruiz.
4.1 Planeación Didáctica del Modelo de Desarrollo Rápido de Aplicaciones.
4.2 Propuesta de Actividades del Modelo de Desarrollo Rápido de Aplicaciones.
4.3 Planeación Didáctica del Modelo de Métodos Formales.
4.4 Propuesta de Actividades del Modelo de Métodos Formales.
4.5 Referencias Capítulo 4
43
44
47
48
51
Capítulo 5 Herramientas de Ingeniería de Software Asistida por Computadora.
María Josefa Somodevilla García, María de la Concepción Pérez de Celis Herrero,
María del Rocío Boone Rojas.
52
5.1 Propuesta de actividades de motivación y diagnóstico para el estudio de las Herramientas
de la Ingeniería de Software Asistida por Computadora.
5.2 Planeación didáctica de los antecedentes y conceptos básicos de las Herramientas de la
Ingeniería de Software Asistida por Computadora.
5.3 Desarrollo de las actividades de antecedentes y conceptos básicos de las Herramientas de
la Ingeniería de Software Asistida por Computadora.
5.3.1 El Concepto CASE.
5.3.2 Componentes básicos de CASE.
5.3.3 Taxonomía de Herramientas CASE.
5.3.4 Caso de Estudio. Introducción a una Herramienta de Ingeniería de Software
Asistida por Computadora.
5.4 Comentarios, Conclusiones y Actividades Complementarias sobre los antecedentes y
conceptos básicos de las Herramientas de la Ingeniería de Software Asistida por
Computadora.
5.5 Referencias Capítulo 5
53
57
58
58
60
61
66
68
68
8
Capítulo 6 Modelos Ágiles de Procesos.
Josefina Guerrero García, Juan Manuel González Calleros.
70
6.1 Propuesta de actividades de motivación y diagnóstico para el estudio de modelos ágiles de
proceso.
6.2 Planeación Didáctica de modelos ágiles de proceso.
6.3 Desarrollo de las Actividades de Introducción a los métodos ágiles de la Ingeniería de
Software.
6.3.1Introducción a los modelos ágiles.
6.4 Desarrollo de las actividades de métodos ágiles de la Ingeniería de Software.
6.4.1 Programación Extrema [Extreme Programming ( XP)]
6.4.2 Metodologías Crystal [CrystalMethodologies (CM)]
6.4.3 SCRUM
6.5 Comentarios, conclusiones y actividades complementarias sobre los antecedentes y
conceptos básicos de la ingeniería de software.
6.6 Referencias Capítulo 6
71
74
75
75
81
81
85
89
94
103
9
Capítulo 1
Antecedentes y Conceptos de
Planeación Didáctica.
Etelvina Archundia Sierra
María del Carmen Cerón Garnica
1. Perspectivas de la Reforma Integral Educativa en México
La Secretaría de Educación Pública ha emitido documentos para la formación docente
como lo son el desarrollo de proyectos didácticos, los cuales permiten atender
diferentes aspectos que se vinculen con los aprendizajes, las relaciones docente/alumno,
la organización de actividades y los intereses educativos en general. De esta manera, los
proyectos didácticos son entendidos como actividades planificadas que involucran
secuencias de acciones y reflexiones coordinadas e interrelacionadas para alcanzar los
aprendizajes esperados que, en el caso de la asignatura de español favorecerán el
desarrollo de competencias comunicativas. Los proyectos didácticos se conforman de
cuatro elementos fundamentales para su desarrollo: propósito, actividades a
desarrollar, productos y evaluación. [1].
Basándose en las investigaciones educativas y el consenso del camino que debe de
seguir el sistema educativo mexicano, se han establecido acuerdos para la
10
implementación del enfoque en competencias, el cual incide desde el nivel básico,
medio superior y superior, en donde cada nivel contempla las competencias a
desarrollar, en el caso del nivel básico se promueve la comunicación y las habilidades
del pensamiento como observar, analizar, razonar, aprender y el ser a través de la
socialización. En el nivel medio superior se contempla: la comunicación, el
pensamiento crítico y creativo, la responsabilidad social y cívica. En la educación
superior el estudio de la propia disciplina y su relación con el campo laboral (Véase
figura 1).
Figura 1. Competencias a desarrollar de acuerdo a los niveles de estudio
Fuente: Elaboración propia de los autores
Con lo anterior se busca la articulación curricular, en el marco de la Reforma
Integral de la Educación Básica (RIEB), basándose en el requisito para el cumplimiento del
perfil de egreso, lo que implica integrar los niveles de preescolar, primaria y secundaria
para que exista consistencia entre las competencias a desarrollar, a fin de sentar las bases
para atender las necesidades de la sociedad actual [2].
Hoy la necesidad de educar para la vida demanda múltiples competencias a los
maestros, de modo que éstos sean agentes de cambio que contribuyan a elevar los
aprendizajes en los niños, en dotarles de herramientas para el pensamiento complejo y para
un desarrollo humano pleno e integral, así como competencias cívicas y sociales que
contribuyan a que todas las personas gocen de iguales derechos, libertades y oportunidades,
así como elevar el bienestar general.
Lo mencionado para la educación básica y media superior se debe de continuar en la
educación universitaria en las diversas áreas del conocimiento para desarrollar individuos
con capacidades que les permita incidir en el momento actual y sean transformadores de su
contexto social. Por lo que la actividad del docente en el proceso de enseñanza aprendizaje
requiere de la profesionalización del docente para atender los retos de la educación hoy en
día, por lo que el docente universitario debe de ser competente en el dominio de los
contenidos de enseñanza del currículo y que desarrolle las capacidades intelectuales de
pensamiento abstracto y complejo en los alumnos universitarios. Para el proceso de
enseñanza aprendizaje el docente debe de estudiar la forma en la cual planea, el cómo
imparte y evalúa sus actividades en el aula. Debe de relacionar en el conocimiento
disciplinar los beneficios de las corrientes pedagógicas a través de los estudiosos como los
11
son: Jean Piaget, Bruner, Lev Vigotsky y Gagne; además del uso de recursos de vanguardia
como lo son las Tecnologías de Información TIC´s(Véase figura 2).
Figura 2: Esquema aprendizaje para el docente en la impartición de su práctica profesional
Fuente: Elaboración propia de los autores
1.1 Comentarios sobre el Proyecto Tuning en América Latina
El enfoque en competencias presentado desde las Reflexiones y Perspectivasde la
Educación Superioren América Latina en el Informe Final del Proyecto Tuningen América
Latina durante los años 2004-2007, muestra las propuestas de las competencias genéricas,
disciplinares y laborales en las diversas áreas del conocimiento.
Las competencias genéricas son los criterios generales que se desarrollan durante
los procesos de aprendizaje y su autogestión, por ejemplo: la comunicación, aprender a
aprender, aprender ser, aprender a hacer (habilidades procedimentales y técnicas).
Las competencias disciplinares se construyen por la integración de los saberes
disciplinares y su aplicación contextual en un marco de conciencia social.
La competencias laborales se relacionan con las disciplinares para la formación y
desempeño profesional en un puesto laboral, identificando lo que es capaz de realizar,
juzgar y la aptitud del poseedor de la competencia.
Cabe mencionar de acuerdo al informe Tuning, la participación de 62 universidades
latinoamericanas debatiendo en 4 grupos de trabajo: Administración de Empresas,
Educación, Historia y Matemáticas. En un segundo momento, dada la repercusión que
alcanzaronlas actividades realizadas en el marco del proyecto y respondiendo a una
demanda de los países latinoamericanos, se incorporaron 120 nuevas universidades en 8
áreas del conocimiento: Arquitectura, Derecho, Enfermería, Física, Geología, Ingeniería,
Medicina y Química. Estas 182 universidades, provenientes de 18 países de América Latina
(Argentina, Brasil, Bolivia, Colombia, Costa Rica, Cuba, Chile, Ecuador, El Salvador,
Guatemala, Honduras, México, Nicaragua, Panamá, Paraguay, Perú, Uruguay y
Venezuela)[3].
12
1.2 Experiencias en espacios comunes en México
Las acciones mencionadas en el Proyecto Tuning se plasman en el Proyecto Experiencias
en Espacios Comunes de Educación Superior ECOES, donde participan la Universidad
Nacional Autónoma de México UNAM, Instituto Politécnico Nacional IPN y la
Universidad Autónoma de México UAM, propiciando el intercambio y la movilidad
estudiantil. La colaboración se da también en la educación a distancia y en el enlace de las
bibliotecas digitales [4].
Si bien el compartir experiencias docentes entre las Universidades también deben de
crear estrategias que les permita aplicar el enfoque en competencias en la Educación
Superior en México por lo que se requiere integrar los estudios realizados a la fecha en un
modelo a seguir en los aspectos de: Diseño curricular, formación docente, desarrollo de
programas académicos, planeación didáctica, actividades de aprendizaje y evaluación de los
programas académicos y curriculares (véase figura 3).
Figura 3. Aspectos a atender en la Educación Superior en México
Fuente: Elaboración propia de los autores
1.2.1 Planeación didáctica en la Educación Superior
El intercambio de experiencias entre los docentes de distintas Universidades Públicas
Mexicanas aportaría en el proceso de enseñanza aprendizaje una oportunidad de enriquecer
la práctica docente y generar materiales que permitan aprendizajes basados en problemas y
proyectos, al igual que estudios de casos en contextos reales de excelente calidad, lo cual
propiciaría en los alumnos, el interés por las asignaturas de los programas académico y un
aprecio al esfuerzo docente vislumbrado en el poder hacer para incidir en la sociedad y
transformación de la misma (Véase figura 4).
13
Figura 4 Formas de aprendizaje en educación superior
Fuente: Elaboración propia de los autores
La planeación didáctica en la Educación Superior requiere en un primer momento
de un diagnóstico que nos permita ubicar los conocimientos, experiencias y prácticas que el
alumno ha generado en las asignaturas anteriores. En un segundo momento el docente debe
despertar el interés y motivación por los nuevos conocimientos, los cuales se contemplan
bajo el control del tiempo, los materiales, recursos a utilizar en las actividades de
aprendizaje a realizar para alcanzar las competencias establecidas al inicio. Las actividades
de aprendizaje requieren la transferencia de las técnicas de aprendizaje y de los
conocimiento disciplinares para llevarlas a cabo durante el desarrollo y ejecución en el aula
de los contenidos plasmados en los programas académicos. Otro aspecto a considerar es la
evaluación de las actividades de aprendizaje y de los objetivos y propósitos plasmados al
principio. Las actividades de aprendizaje requieren de los recursos de vanguardia
especializados en la educación a través de las Tecnologías de Información y Comunicación
TIC´s.
1.2.2 Actividades de aprendizaje
Para las actividades de aprendizaje se requiere del estudio de las estrategias y técnicas en la
enseñanza, aunado al conocimiento disciplinar de las asignaturas. Por lo que se recomienda
utilizar los mapas conceptuales, mapa mental, cuadros sinópticos, esquemas, gráficos,
diagramas; también durante las actividades de aprendizaje se sugieren técnicas de
dinámicas grupales como el Panel, Philips 6/6, Trabajos en pequeños grupos y debates.
En la planeación didáctica se destacan las actividades desarrolladas en la
motivación e interés respecto al tema de estudio y en el desarrollo del mismo (véase figura
5). La actividad inicial motivacional se considera como un diagnóstico a partir de los
conocimientos previos del alumno mediante los recursos de un video, el diálogo, texto o
14
una imagen. En este momento el clima de confianza en el aula propicia un medio de
investigación e interés por parte del alumno respecto del tema.
Para las actividadesen el desarrollo del tema se considera la búsqueda de los conocimientos
disciplinarios del tema de diversas fuentes, a partir de datos, investigaciones, solución de
problemas y estudio de casos.
Actividad de
desarrollo
•Motivación
•Diagnóstica
Actividad
inicial
• Trabajo en equipo.
• Estudio de casos
• Solución de problemas
• Investigaciones
• Lecturas
•Conclusiones
•Evaluación
Cierre
Figura 5. Actividades de inicio y desarrollo en la Planeación didáctica
Fuente. Elaboración propia de los autores
En el proceso de desarrollo el docente debe pensar en la organización de las
actividades a través de equipos de trabajo y de prácticas de procesos constructivistas para
enriquecer el proceso cognitivo de aprendizaje.
Posterior a las actividades de desarrollo las conclusiones y cierre donde el alumno
extrae y concreta lo aprendido en el cambio y transformación de los conocimientos previos
a los nuevos. El pensamiento analógico, crítico y reflexivo representa la funcionalidad del
aprendizaje del tema establecido [5].
1.3
Evaluación sumativa y formativa
La evaluación de los aprendizajes es un proceso complejo puesto que considera la
implicación de diversas variables presentes en el aula como lo es la relación entre el
docente-alumno, las evidencias del aprendizaje, la relación entre los alumnos, los recursos,
las estrategias de aprendizaje aplicadas y la planeación didáctica. Cuando el docente integra
las dimensiones mencionada debe de contemplar que la evaluación se puede dar en lo
aprendido del tema, de la asignatura y lo que trasciende en el alumno para continuar con el
aprendizaje en su práctica profesional. A continuación se presentan los dos tipos de
evaluación esenciales a considerar en el proceso de aprendizaje: la evaluación sumativa y la
formativa.
La evaluación sumativa debe de ser coherente con las actividades de aprendizaje
establecidas durante el desarrollo de la Planeación didáctica. La evaluación sumativa se
15
puede establecer mediante rúbricas, enseñanza asistida por el grupo, lista de cotejo o nota
técnica.
En la evaluación formativa el docente deberá crear una guía que permita al alumno
integrar sus conocimientos, habilidades y actitudes en la solución de problemas
disciplinares y aprendizaje basado en proyectos. El docente establecerá los tiempos de
revisión y de rúbricas que le permita al alumno conocer su progreso y retroalimentación. El
ambiente que se propicia en la evaluación formativa es de confianza y logros, permitiendo
al alumno el pensamiento creativo para la innovación.
1.4 Referencias Capítulo 1
[1] Secretaría de Educación Pública, (2009) Programas de estudio 2009. Primer grado.
Educación básica. Primaria, Segunda edición, 2009, Primera reimpresión, 2010, D. R. ©
México, DF pág. 31.
[2] Curso Básico de Formación Continua para Maestros en Servicio, Planeación didáctica
para el desarrollo de competencias en el aula 2010 fue elaborado en la Dirección General
de Formación Continua de Maestros en Servicio de la Subsecretaría de Educación Básica,
de la Secretaría de Educación Pública.
[3] Reflexiones y perspectivas de la Educación Superior en América Latina. Informe Final
– Proyecto Tuning – América Latina. 2004-2007.Tuning – América Latina:
http://tuning.unideusto.org/tuningal
[4] Rositas, J. y Torres, G. Diseño de planes educativos bajo un enfoque de competencias.
Ed. Trillas, México, 2011.
[5] García, A. y Gómez, E. Notas del Diplomado en Planeación y organización de
secuencias e intervención didácticas en torno a aprendizajes cognitivos, BUAP. México,
Puebla, 2011
16
Capítulo 2
Antecedentes y Conceptos Básicos de
la Ingeniería de Software.
Etelvina Archundia Sierra
María del Rocío Boone Rojas
Introducción
Los programas de estudio en computación cuentan, actualmente, con la asignatura de
Ingeniería de Software. Los docentes que imparten la asignatura están convencidos de que a
los alumnos se les debe motivar el interés por conocer y practicar las metodologías para el
desarrollo de sistemas de calidad en computación.
Para que el alumno se interese en el estudio de la Ingeniería de Software el docente
deberá realizar una planificación docente para que el alumno comprenda: Cuál es el objeto
de su estudio y por lo tanto, la necesidad de aprender su aplicación en el campo de
desarrollo de sistemas de cómputo de calidad.
17
Los aspectos que debe identificar el alumno son: el ingenio del sujeto capaz de
transformar mediante la Ingeniería de Software, sistemas de cómputo de calidad al servicio
de las personas y de los diversos campos de la sociedad.
En el presente capítulo se propone una serie de actividades de aprendizaje para que
el docente pueda desarrollar en su clase los siguientes aspectos:
o
o
o
o
Conceptos y términos de la Ingeniería de Software.
Antecedentes de la Ingeniería de Software.
El Concepto de Ingeniería de Software.
Factores de Calidad del Software.
2.1 Propuesta de Actividades de Motivación y Diagnóstico para el Estudio
de la Ingeniería de Software.
Actividades Propuestas.
Actividad 1
Objetivo.
Que el alumno identifique, a priori, algunas de las actividades y ventajas inherentes a la
Ingeniería de Software.
Especificaciones.
E1) Selecciona un producto de programación que hayas desarrollado en un curso
anterior.
Ejemplo de Resultados.
Programa para el curso de algoritmos y estructuras de datos. Profesor. M.C. Marco
Antonio Soriano Ulloa.
E2) Resuelve el siguiente cuestionario:
1.-Proporciona una lista de, al menos, tres especificaciones de requisitos establecidos
por el profesor.
Ejemplo de Resultados.
Requisito1.
18
Programa que encuentre los caminos de costo mínimo que hay entre cada par de nodos
de una digráfica pesada.
Requisito 2.
Considerar como datos de entrada:
n – número de nodos.
N – conjunto de nodos.
R – conjunto de arcos.
P – pesos asignados a cada arco.
Requisito 3.
Utilizar el algoritmo de Dijkstra.
2.- ¿Consideras que el producto que desarrollaste se apegó a los requisitos establecidos?
¿ Por qué?
Ejemplo de Resultados.
- Al principio no entendí el problema.
- Los resultados fueron incorrectos.
3.- ¿Cumpliste en tiempo y forma, con la fecha de entrega? Justifica tu respuesta.
Ejemplo de Resultados.
-Sí se entregó en la fecha establecida pero no era exactamente lo que pidió el profesor.
4.- ¿El tiempo establecido de desarrollo fue suficiente? Justifica tu respuesta.
Ejemplo de Resultados.
-El tiempo sí fue suficiente, pero faltó organizar actividades personales.
5.-Indica, por lo menos, dos aspectos del proceso de desarrollo de tu proyecto que se
podrían mejorar.
Ejemplo de Resultados. Realizar una mejor planeación de mis actividades.
-Interactuar con el profesor para aclarar los requisitos.
Recursos.
R1) Producto de Programación desarrollado previamente, de preferencia en un lenguaje
de alto nivel.
2.2 Planeación Didáctica de los Antecedentes y Conceptos Básicos de la
Ingeniería de Software.
19
Tiempo.
Se propone cubrir el tema en un intervalo de 4 hrs.
Contenido.
1.
2.
3.
4.
Conceptos y Términos de la Ingeniería de Software.
Antecedentes de la Ingeniería de Software.
El Concepto de Ingeniería de Software.
Factores de Calidad del Software.
Materiales.
Referencias Bibliográficas.
[1] Fairley
Ingenierìa de Software.
Prentice Hall.
IEEE Trans. on Software Engineering.
[2] Capítulo 1
Pressman Roger S.
Ingeniería de Software, Un Enfoque Práctico.
Mc Graw Hill.
[3] Capítulo 1
IanSommerville.
Ingeniería de Software
Addison Wesley.
Recursos Electrónicos.
[4] Gabriel Buades Rubio.
“Concepto de Calidad”
Ingeniería de Software III
Depto. De Ciencias Matemáticas e Informática.
Universidad de las Islas Balares
http://dmi.uib.es/~bbuades/calidad/sld016.htm
Consulta: Junio 2011
[5] Xavier Ferré Grau
“Principios Básicos de Usabilidad para Ingenieros Software”
20
Facultad de Informática
Universidad Politécnica de Madrid
http://is.ls.fi.upm.es/miembros/xavier/papers/usabilidad.pdf
Consulta: Junio 2011
[6] Moisés Rodríguez Monje
“Calidad de Procesos y Productos Software, ISO/IEC 25000”
Alarcos Quality Center
http://alarcos.inf-cr.uclm.es/per/fruiz/cur/santander/mrodriguez-iso25000-update.pdf
Consulta: Junio 2011
2.3 Desarrollo de las Actividades de Antecedentes y Conceptos Básicos de
la Ingeniería de Software.
2.3.1 Conceptos y Términos de la Ingeniería de Software.
Material de Referencia.
De Pressman [2] se incluye el siguiente material:
Ingeniería.
Profesión que posee conocimientos científicos, actividades y criterios (ingenio) para crear
dispositivos, métodos y sistemas para transformar los recursos y satisfacer mejor las
necesidades de una sociedad.
Software.
Conjunto de programas que se pueden ejecutar en una computadora, así como toda la
información, utilerías y recursos necesarios para su diseño, instalación, operación,
mantenimiento y refinamiento.
Ingeniería de
Software.
Disciplina que establece el uso de principios de ingeniería robustos, orientados a obtener
software económico que sea confiable y funcione de manera eficiente.
Perfil del
Ingeniero de
Software.
Debe ser capaz de encabezar o ser miembro de grupos multidisciplinarios de desarrollo de
de todo tipo de software y que en equipo logre producir software de alta calidad.
Diferencia entre
programador e
Ingeniero de
Software.
La Ingeniería de Software difiere de la programación tradicional en que se utilizan técnicas
de ingeniería para especificar, diseñar, codificar, validar y mantener los productos dentro
del tiempo y presupuesto establecidos para el proyecto. Además, la ingeniería se preocupa
por aspectos administrativos que quedan fuera del dominio normal de la programación.
El término programador se emplea para denominar a la persona preocupada y abocada a
las tareas y detalles de la codificación, empacado y modificación de los algoritmos y
estructuras de datos codificados en algún lenguaje de programación particular.
Los Ingenieros de Software están, además, capacitados para hacer frente a aspectos de
análisis, diseño, verificación, prueba de programas, documentación, mantenimiento y
administración del proyecto.
21
Actividades Propuestas.
Actividad 1
Objetivo.
Que el alumno identifique los términos y conceptos elementales de la Ingeniería de
software.
Especificación.
E1) Revisa las referencias [1] y [2], y realiza tu propia investigación sobre los conceptos y
términos de la ingeniería de software.
-Elabora un mapa conceptual que involucre los principales términos y conceptos de la
ingeniería de software.
Ejemplo tipo de Resultados.
(Ver mapa conceptual en Programa de curso de la asignatura de Ingeniería de Software,
Modelo MUM).
Recursos.
R1) Referencias [1] y [2]
R2) Conexión a Internet.
2.3.2 Antecedentes de la Ingeniería de Software.
Material de Referencia.
Recomendación: Revisar Refs. [1] y [2].
A continuación se incluye material de Pressman [2]:
22
La “Crisis del Software” se denomina una etapa en la que todos los programas
desarrollados, se corregían cuando había fallos o eran modificados debido a necesidades
cambiantes, y que requerían de grandes esfuerzos para mantenerlos, con un costo mayor, a
medida que la complejidad del software crecía.
En las pasadas décadas los ejecutivos y desarrolladores se hacían las siguientes
preguntas:
¿Por qué lleva tanto tiempo terminar los programas?
¿Por qué es tan elevado el costo?
¿Por qué no podemos detectar los errores antes de entregar el software a los clientes?
¿Por qué resulta tan difícil constatar el progreso del desarrollo del software?
Estas y otras preguntas manifiestan el carácter del software y la forma en que se
desarrolla, estos problemas hacen necesaria la adopción de técnicas de Ingeniería de
Software.
El software es ahora la clave del éxito de muchos de los sistemas basados en
computadora. El software marca la diferencia. Lo que diferencia una compañía de otra, es
la suficiencia, exactitud y oportunidad de la información proporcionada por el software.
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. Sólo que uno de ellos, cuenta con un dispositivo especial
conectado a la computadora y con un Software para obtener radiografías de piezas
dentales por computadora. En un par de minutos la muestra radiográfica está en pantalla y
el médico puede obtener diferentes vistas de la placa usando este software. Además, puede
establecer una conexión a través de internet o vía modem, para enviar el archivo de la
radiografía a otro colega experto, con el fin de consultar y apoyar el diagnostico, todo ello
en la misma cita. En la forma tradicional la placa radiográfica estaría lista en un par de días.
El desarrollo de software se ha convertido en una industria con crecimiento vertical
en los últimos años, hoy por hoy uno de los hombres más ricos del mundo es el dueño de
una casa de software, Microsoft.
Hace un par de décadas se sostenía la teoría de que los países que poseían los mejores
recursos naturales estaban destinados a ser los más ricos y poderosos del mundo, en México
por ejemplo, se manejó la idea de que el petróleo era la gran puerta de entrada al mundo
desarrollado. Indudablemente los recursos naturales tienen un papel importante en la
economía de los países, sin embargo, poco a poco se fue acuñando una nueva ideología que
se sintetiza en lo siguiente:
Aquél que posee la información y el conocimiento y hace mejor uso de él, es el que tiene el
poder.
Problemas del software.
• La planificación y estimación de costos frecuentemente son imprecisas.
• Falta de productividad en la comunidad de software
• La calidad del software, a veces, es inaceptable.
Estos problemas al final crean insatisfacción y falta de confianza por parte de los clientes.
Los problemas anteriores son sólo manifestación de otras dificultades:
• No tenemos tiempo de recoger datos sobre el proceso de desarrollo del software.
• Los proyectos de desarrollo de software se llevan a cabo con sólo una vaga
indicación de los requisitos del cliente.
• La calidad del software es normalmente cuestionable.
• El mantenimiento de software es muy costoso y no se le ha considerado un aspecto
importante.
Los problemas anteriores son corregibles, la clave es: Dar un enfoque de ingeniería al
desarrollo de software.
24
Actividades Propuestas.
Actividad 1
Objetivo. Que el alumno identifique el tipo de productos de software desarrollados a
partir de la segunda generación de computadoras, cuyo tamaño y complejidad resultó
imposible de manejar sin una metodología adecuada.
Especificación.
-Revisar el Cap.1 de las refs. [1] y [2].
-Proporcionar una lista de los tipos de productos de software que se desarrollaron a
partir de la segunda generación de computadoras.
Ejemplo de Resultados.
-Sistemas de tiempo compartido.
-Sistemas con multiprogramación.
-Sistemas multitarea.
Recursos.
R1) Referencias [1] y [2]
Actividad 2
Objetivo. Que el alumno identifique los problemas que surgen cuando los productos de
software se desarrollan sin el enfoque de la ingeniería de software.
Especificación.
-Revisar el Cap.1 de las refs. [1] y [2]. (Ver II Planeación, Materiales.)
-Proporcionar una lista de los problemas que surgieron durante el desarrollo de los
productos de programación durante la etapa llamada “crisis del software.”
Ejemplo de Resultados.
-El Producto se entregó fuera de tiempo.
-El producto no corresponde a los requisitos especificados por el cliente.
-Algunas de las opciones del producto NO funcionan o bien, fallan.
25
Recursos.
R1) Referencias [1] y[2]
2.3.3 El Concepto de Ingeniería de Software.
Material de Referencia.
Ref.[1].
En [1] se incluyen algunas definiciones de la Ingeniería de Software:
Definición 1
Ingeniería de Software es el estudio de los principios y metodologías para desarrollo y
mantenimiento de sistemas de software [Zelkovitz, 1978]
Definición 2
Ingeniería del Software es la aplicación práctica del conocimiento científico en el diseño y
construcción de programas de computadora, así como de la documentación asociada,
requerida para desarrollar, operar (funcionar) y mantenerlos. Se conoce también como
desarrollo de software o producción de software [Bohem, 1976]
'
Definición 3
Ingeniería del Software trata del establecimiento de principios y métodos de ingeniería, con
el fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales
[Bauer,1972].
Definición 4
La aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo,
operación (funcionamiento) y mantenimiento del software; es decir, la aplicación de
ingeniería al software. 2. El estudio de enfoques como en (1) [IEEE, 1993].
ZELKOVITZ, M. V., SHAW, A. C. y GANNON, J. D.: Principles of Software
Engineering and Design. Prentice-Hall, EnglewoodsClif, 1979.
BOEHM, B. W.: Software Engineering., IEEE Transactions on Computers, C-25, núm. 12,
pp. 1226-1241.
BAUER, F. L.: Software Engineering, Information Processing, 71, North Holland
Publishing Co., Amsterdarn, 1972
IEEE: Standards Collection: Software Engineering, IEEE Standard 610.12-1990, IEEE,
1993.
26
Actividades Propuestas.
Actividad 1
Objetivo:
Identificar los conceptos clave asociados a la Ingeniería de Software.
Especificación.
E1) Realizar una revisión y análisis grupal de las diferentes definiciones de ingeniería de
software presentadas previamente. En cada caso, señalar los conceptos clave que se resaltan
en cada una de ellas.
Recursos.
R1) Ref.[2].
2.3.4 Factores de Calidad del Software.
Material de Referencia.
-Concepto de Calidad.
[4], [2], [6], [7]
-Factores de Calidad Estructurales y Derivados. [4]
-Descripción de Factores.
[1], Cap. 18 y en [4] y [5].
Actividad 1
Objetivo.
Que el alumno identifique atributos de calidad en un producto de Programación.
Especificación.
E1) Selecciona un producto de programación que hayas desarrollado en un curso anterior.
E2) Identifica tres factores de calidad que consideres se le pueden atribuir a tu producto.
Justifica tu respuesta.
Ejemplo de Tipo de Resultados.
Es portable, porque se desarrolló en Java, el cual tiene una máquina virtual.
Recursos.
27
R1) Referencias [4] y [5].
R2) Un producto de programación desarrollado previamente, de preferencia en un lenguaje
de programación de alto nivel.
R3) Conexión a Internet.
Actividad 2
Objetivo.
Que el alumno identifique que es posible mejorar la calidad de sus productos de
programación.
Especificaciones.
E1) Desde el punto de vista del programador, indica al menos tres características de tu
producto de programación que consideres se podrían mejorar.
Ejemplo de Resultados.
-Utilizar estructuras de datos dinámicas para la implementación de los archivos indizados.
E2) Desde el punto de vista del usuario, indica al menos tres características de tu producto
de programación que consideres se podrían mejorar.
Ejemplo de Resultados.
-Mejorar la interfaz del usuario.
-Dar más opciones para generar otro tipo de reportes.
Recursos.
R1) Referencias [6] y [7].
R2) Un producto de programación desarrollado previamente, de preferencia en un lenguaje
de programación de alto nivel.
R3) Conexión a Internet.
Actividad 3
Objetivo.
Que el alumno conozca que existen herramientas para evaluar factores de calidad de
software y que pueden ser de diferentes tipos. (En un siguiente capítulo, “Métricas”, se
espera que sea capaz de experimentar con al menos una de ellas).
Especificaciones.
E1) Realiza una búsqueda por Internet y desarrolla una breve documentación sobre tres
herramientas para evaluar factores de calidad de un producto de software. Incluye al menos
los siguientes aspectos:
Nombre.
28
Empresa.
Propósito.
Puedes organizar tus resultados en una tabla.
Ejemplo de Tipo de Resultados.
Nombre. KEMIS“Kybele Environment Mesaurement Information System”
Empresa.KybeleConsulting.
Propósito. Facilitar la medición automatizada de la calidad de los productos software. Ej.
Factores relacionados con capacidad de un producto para ser probado, de soportar
actualizaciones.
Recursos.
R1) Conexión a internet.
R2) Referencias disponibles en [6].
2.4 Comentarios, Conclusiones y Actividades Complementarias sobre los
Antecedentes y Conceptos Básicos de la Ingeniería de Software.
Se propone realizar una actividad grupal de análisis y reflexión, relacionada con las
siguientes cuestiones.
-¿Cuál es el objetivo fundamental de la Ingeniería de software?
-¿Consideras que el desarrollo de tus productos de software que has desarrollado hasta la
fecha, ha sido metodológico y disciplinado?
-¿Tus productos de programación cumplen con algunos o la mayoría de los factores de
calidad que se han revisado?
2.5 Referencias Capítulo 2
[1] Fairley
Ingenierìa de Software.
Prentice Hall.
IEEE Trans. on Software Engineering.
[2] Capítulo 1
29
Pressman Roger S.
Ingeniería de Software, Un Enfoque Práctico.
Mc Graw Hill.
[3] Capítulo 1
IanSommerville.
Ingeniería de Software
Addison Wesley.
Recursos Electrónicos.
[4] Gabriel Buades Rubio.
“Concepto de Calidad”
Ingeniería de Software III
Depto. De Ciencias Matemáticas e Informática.
Universidad de las Islas Balares
http://dmi.uib.es/~bbuades/calidad/sld016.htm
Consulta: Junio 2011
[5] Xavier Ferré Grau
“Principios Básicos de Usabilidad para Ingenieros Software”
Facultad de Informática
Universidad Politécnica de Madrid
http://is.ls.fi.upm.es/miembros/xavier/papers/usabilidad.pdf
Consulta: Junio 2011
[6] Moisés Rodríguez Monje
“Calidad de Procesos y Productos Software, ISO/IEC 25000”
Alarcos Quality Center
http://alarcos.inf-cr.uclm.es/per/fruiz/cur/santander/mrodriguez-iso25000-update.pdf
Consulta: Junio 2011
[7] http://www.iso.org
30
Capítulo 3
Ciclo de Vida.
Alma Delia Ambrosio Vázquez
Ma. del Consuelo Molina García
Introducción
Un modelo de ciclo de vida define el estado de las fases a través de las cuales se lleva un
proyecto de desarrollo de software, este proceso es parte de la calidad del software que un
ingeniero de software debe aplicar y al cual debe dar seguimiento.
31
Uno de los objetivos de la asignatura de ingeniería de software, es conseguir que el
alumno conozca el concepto de calidad del software, que comprenda, conozca y valore la
importancia del uso de metodologías de la ingeniería de software, así como de que le
confiera un seguimiento durante todo el ciclo de vida del software.
Tomando en cuenta que la Ingeniería de Software es el resultado de llevar la
tradicional disciplina de las ingenierías al mundo de la construcción de sistemas de
software es necesario el estudio de los principios y metodologías para el desarrollo y
mantenimiento de sistemas software así como de las personas que se involucran en ello.
Por las razones expuestas, el objetivo del presente trabajo es realizar una intervención
didáctica, que planifique las tareas de aprendizaje en los temas involucrados.
En el presente capítulo se propone una serie de actividades de aprendizaje para que el
docente pueda desarrollar en su clase los siguientes aspectos:
o Paradigmas de Programación
o Las 4 P`s de la Ingeniería de software (Proceso, Producto, Proyecto y
Personas)
o Metodologías de la Ingeniería de software
o Ciclo de vida del software.
3.1 Propuesta de Actividades de Motivación y Diagnóstico para el Estudio
del Ciclo de vida del software .
Dentro de las actividades diagnósticas en esta materia, es trascendental que el
alumno conozca las conceptos básicos como paradigmas de programación, las 4 P’s de la
Ingeniería de Software, Ciclo de Vida, Modelo, Metodología, Calidad del Software,
Planeación y Administración de Proyectos, Factibilidad, Viabilidad, Prototipos, y la
Certificación de Procesos.
Actividades Propuestas.
Actividad 1
Objetivo.
Que el alumno identifique las ventajas de aplicar las metodologías de la ingeniería de
software.
32
Especificaciones.
E1) Que el alumno realice una investigación sobre el conjunto de métodos, técnicas y
herramientas relacionadas con las metodologías de desarrollo de software.
E2) Que el alumno realice una investigación sobre las diferencias en los paradigmas de
programación.
E3) Con base en un análisis crítico-objetivo el alumno basado en un andamiaje, resuma
las condiciones apropiadas para la aplicación de metodologías de la Ingeniería de
Software estructurada u orientada hacia objetos.
E4) Resuelva el siguiente cuestionario:
1. ¿Cuáles son las cuatro componentes P de la ingeniería de software?
2. ¿Qué es el proceso en cascada?
3. ¿Qué estándares existen para documentación?
4.-Establezca las diferencias entre aplicar, o no, una metodología de la Ingeniería de
Software en el desarrollo de software. Justifica tu respuesta.
Recursos.
R1) Consultar bibliografía.
3.2 Planeación Didáctica de Ciclo de vida en la Ingeniería de Software.
Tiempo.
Se propone cubrir el tema en un intervalo de 4 hrs.
Contenido.
•
•
•
Paradigmas de Programación
Las 4 P`s de la Ingeniería de software
Metodologías de la ingeniería de software
33
•
Ciclo de vida del software.
Materiales.
Referencias Bibliográficas.
[1] Capítulo 1
Braude
Ingeniería de Software Una perspectiva orientada a objetos
Alfaomega 2003
IEEE Trans. on Software Engineering.
[2] Capítulo 1
Pressman Roger S.
Ingeniería del Software, Un Enfoque Práctico.
Mc Graw Hill.
[3] Capítulo 1
Ian Sommerville.
Ingeniería de Software
Addison Wesley.
Recursos Electrónicos.
[4] Gabriel Buades Rubio.
“Concepto de Calidad”
Ingeniería de Software III
Depto. De Ciencias Matemáticas e Informática.
Universidad de las Islas Balares
http://dmi.uib.es/~bbuades/calidad/sld016.htm
Consulta: Junio 2011
[5] Xavier Ferré Grau
“Principios Básicos de Usabilidad para Ingenieros Software”
Facultad de Informática
Universidad Politécnica de Madrid
http://is.ls.fi.upm.es/miembros/xavier/papers/usabilidad.pdf
Consulta: Junio 2011
[6] Moisés Rodríguez Monje
“Calidad de Procesos y Productos Software, ISO/IEC 25000”
Alarcos Quality Center
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 Términos de ciclo de vida, las P`s de la Ingeniería de
Software.
Material de Referencia.
De Braude [1] se incluye el siguiente material:
Ciclo de Vida
•
El ciclo de vida de desarrollo de sistemas informáticos puede dividirse en actividades
o fases que, en general, se ajustan al esquema mostrado en el gráfico. Este esquema
gráfico es el ciclo de vida típico, dado que existen gran cantidad de variantes que
dependen de la organización, del tipo de sistema que se realizará, de los gustos de los
administradores, de los tiempos, etc.
Las actividades típicas del ciclo de vida son:
1- Estudio de factibilidad.
2- Análisis (de requerimientos).
3- Diseño
4.1- Creación de prototipos
4.2- Implementación
5 - Validación y prueba
6 - Operación y mantenimiento
35
La Ingeniería de Software es el resultado de llevar la tradicional disciplina de las
ingenierías al mundo de la construcción de sistemas de software.
Es el estudio de los principios y metodologías para el desarrollo y mantenimiento de
sistemas software.
Los desafios de la Ingenieria de Software son:
La Ing. Sw es una tecnología estratificada
•
Enfoque de calidad
– La IS debe estar sustentada en un compromiso con la calidad (Gestión de
Calidad Total, Sigma Seis, etc.) que fomente una cultura de mejora continua
del proceso.
36
•
•
•
•
•
•
Procesos
– Define un marco de trabajo que debe establecerse para la entrega efectiva, la
gestión de proyectos, el contexto en el cual se aplican los métodos técnicos,
se generan los productos del trabajo, se establecen los fundamentos, se
asegura la calidad y el manejo adecuado de cambios
Métodos:
– Definen los “cómo” para construir el software desde el punto de vista
técnico.
Herramientas:
– Proporcionan un soporte automático o semi-automático para los métodos.
Herramientas CASE
Métodos:
– Planificación y estimación de proyectos.
– Análisis de requisitos.
– Diseño.
– Codificación.
– Pruebas.
– Mantenimiento.
Herramientas:
– CASE.
– CAD, ...
Procesos.
– PSP
– TSP
– CMMi…..
¿Qué es un proceso?
Define un marco de trabajo que forma la base del control de gestión de proyectos de
SW y establecen el contexto en que se aplican los métodos técnicos, se producen los
resultados del trabajo, se asegura la calidad, etc
•
•
Los métodos: Indican cómo construir técnicamente el SW. Las tareas que incluye
son:
– Análisis de requisitos.
– Diseño (estructuras de datos, arquitectura de programación y procedimientos
algorítmicos).
– Pruebas.
– Mantenimiento.
Procedimientos: Relacionan métodos y herramientas desde un punto de vista
formal. Entre otras cosas, se define la secuencia en que se aplican los métodos
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 diseñador sin saber de tecnologías
– No se puede diseñar el proceso sin tener en cuenta la Arquitectura
– El proceso tiene que ir apoyado por metodologías
– No se puede ser un buen director de proyecto sin saber del resto
– No se puede ser un buen arquitecto sin saber de tecnología
– No basta con saber de tecnología para ser un buen arquitecto
– ….
Trabajo en equipo de desarrollo de software de paradigma estructurado y orientado
a objetos.
Actividades Propuestas.
Actividad 1
Objetivo.
Que el alumno conozca los conceptos básicos relacionados con el ciclo de vida de la
Ingeniería de software.
Especificación.
E1) Revisar las referencias [1], [2] y [3] para realizar una investigación sobre los conceptos
y términos de ciclo de vida.
-Elaborar un mapa conceptual que represente las metodologías de la ingeniería de software.
38
Ejemplo tipo de Resultados.
(Ver mapa conceptual en Programa de curso de la asignatura de Ingeniería de Software).
Recursos.
R1) Referencias [1] y [2]
R2) Conexión a Internet.
Actividad 2
Objetivo.
Comprender los conceptos básicos de la Ingeniería de software
Especificación.
E1) Revisar las referencias [1], [2] y [3]
1. Se expone por parte del profesor los conceptos básicos de Ingeniería de Software
Proceso, Producto, Personas, Proyecto, Modelo y Metodología.
2. Se reproducirá el video de Apolo 13 a partir de la escena 8 donde inicia el problema
de bióxido de carbono y en tierra se dan instrucciones a un equipo que trabaje con el
material a disposición de la tripulación a fin de hacer algo para solucionar el
problema.
3. Los estudiantes se reúnen en equipos comentan el video examinado y cada equipo
se le entregan unas preguntas tales como:
¿Es importante el proceso para la solución de un problema?
¿La organización del equipo de trabajo ayuda a la solución?
¿Es importante trabajar con roles?
¿Qué estrategia siguieron en el video para solucionar el problema?
4. Un alumno de cada equipo, podrá ser elegido al azar para presentar y justificar ante
el grupo las respuestas
5. Por último, se entregará a cada alumno una prueba de verificación del aprendizaje
de los conceptos vistos y comentados en clase.
Ejemplo tipo de Resultados.
(Ver mapa conceptual en Programa de curso de la asignatura de Ingeniería de Software).
Recursos.
R1) Referencias [1] y [2]
39
R2)Video, Laptop, cañón, plumones, pizarrón, resumen de la clase y prueba de
verificación del aprendizaje
Distribución de tiempo
25 min. Inicio de la clase (Introducción al conocimiento)
Exposición por el profesor
35 min. Ver las escenas del video
10 min. Actividad de cada uno de los equipos genera respuestas.
20 min. Presentación de resultados por un alumno de cada equipo
10 min. Realizar la prueba de verificación de conceptos aprendidos
10 min. Conclusiones
Total 1 hr. 50 min.
3.4 Comentarios, Conclusiones y Actividades Complementarias del Ciclo
de Vida del Software.
En esta etapa el alumno tendrá claro el concepto y la importancia de generar
software de Calidad.El alumno conocerá la existencia de varios modelos de ciclo de vida a
aplicar de acuerdo a sus características durante el desarrollo de software. Asimismo hará
conciencia de la importancia de las P´s de la ingeniería de software.
Se propone realizar una actividad grupal de análisis y reflexión, relacionada con las
siguientes cuestiones.
- ¿Cuál es la diferencia entre aplicar o no una metodología de la Ingeniería de software?
- ¿Para un caso dado, es posible aplicar indistintamente paradigma estructurado u orientado
a objetos?
- ¿Cómo garantizarías la calidad de tu producto de software?
40
3.5 Referencias Capítulo 3
Referencias Bibliográficas.
[1] Fairley
Ingenierìa de Software.
Prentice Hall.
IEEE Trans. on Software Engineering.
[2] Capítulo 1
Pressman Roger S.
Ingeniería de Software, Un Enfoque Práctico.
Mc Graw Hill.
[3] Capítulo 1
IanSommerville.
Ingeniería de Software
Addison Wesley.
41
Capítulo 4
Los Modelos DRA y de Métodos Formales
Mario Anzures García
Maya Carrillo Ruiz
Introducción
Para resolver problemas reales de una empresa, un ingeniero del software o un equipo de
ingenieros deben de incorporar una estrategia que a menudo se llama modelo de proceso o
paradigma de ingeniería de software. Se selecciona un modelo de proceso para la ingeniería
del software de acuerdo a la naturaleza del proyecto y de la aplicación, los métodos y las
herramientas que se utilizan, así como los controles y entregas que se requieren. En este
capítulo se abordan el modelo de Desarrollo Rápido de Aplicaciones (DRA/RAD) y el
Modelo de Métodos Formales.
42
4.1 Planeación Didáctica del Modelo de Desarrollo Rápido de
Aplicaciones.
Tiempo.
Se propone cubrir el tema en un intervalo de 2 hrs.
Contenido.
•
•
Introducción a RAD.
Definiciones y elementos fundamentales de RAD.
Materiales.
R1) Consultar bibliografía.
[1] James Martin
Rapid application development
Macmillan Publishing Co., Inc. Indianapolis, IN, USA
1991
[2] Beynon-Davies P.1; Carne C.1; Mackay H.2; Tudhope D.
Rapid application development (RAD): an empirical review
European Journal of Information Systems, Volume 8, Number 3, 1 Palgrave
MacmillanSeptember 1999 , pp. 211-223(13)
[3] Carlo Ghezzi, Mehdi Jazayeri y Dino Mandrioli.
Fundamentals of Software Engineering. Prentice Hall
International, 1991.
[4] Pressman Roger S.
Ingeniería del Software, Un Enfoque Práctico.
Mc Graw Hill.
[5] Ian Sommerville.
Ingeniería de Software
Addison Wesley.
Recursos Electrónicos.
[5] Vídeo tutorial RDA en http://www.youtube.com/watch?v=gPgsKLtwJ68
43
Fig. 4.1 Tutorial RAD
4.2 Propuesta de Actividades del Modelo de Desarrollo Rápido de
Aplicaciones.
Actividades Propuestas.
Las acciones que se llevarán a cabo tienen como fin incentivar la utilización del modelo
DRA.
Actividad 1.
Objetivo.
Estudiar el enfoque DRA.
Especificaciones.
E1) Que el alumno entienda el modelo DRA
Ejemplo de Resultados.
En la formación del alumno es significativo, que éste estudie, comprenda y utilice
diversos modelos o metodologías relacionadas con el desarrollo de los diferentes
modelos de procesos existentes en la actualidad. Uno de estos es el Modelo de
Desarrollo Rápido de Aplicaciones (DRA) o RAD (Rapid Application Development),
que es un proceso de desarrollo de software, creado inicialmente por James Martin en
44
1980. El método comprende el desarrollo iterativo, la construcción de prototipos y el
uso de utilidades CASE, enfatizando un ciclo de desarrollo extremadamente corto
utilizando un enfoque
de construcción basado en componentes. Si se comprenden bien los requisitos y se
limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear
un "sistema completamente funcional" dentro de periodos cortos de tiempo.
E2) Que el alumno realice una investigación y redacción de las etapas que comprende el
modelo DRA.
Ejemplo de Resultados.
Modelado de gestión: el flujo de información entre las funciones de gestión se
modela de forma que responda a las siguientes preguntas: ¿Qué información
conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera?
¿A dónde va la información? ¿Quién la procesa?
Modelado de datos: el flujo de información definido como parte de la fase de
modelado de gestión se refina como un conjunto de objetos de datos necesarios
para apoyar la empresa. Se definen las características (llamadas atributos) de
cada uno de los objetos y las relaciones entre estos objetos.
Modelado de proceso: los objetos de datos definidos en la fase de modelado de
datos quedan transformados para lograr el flujo de información necesario que
implemente una función de gestión. Las descripciones del proceso se crean para
añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación
entre los objetos.
Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta
generación. En lugar de crear software con lenguajes de programación de tercera
generación, el proceso DRA trabaja para volver a utilizar componentes de
programas ya existentes (cuando es posible) a crear componentes reutilizables
(cuando sea necesario). En todos los casos se utilizan herramientas automáticas
para facilitar la construcción del software.
Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han
comprobado muchos de los componentes de los programas. Esto reduce tiempo
de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se
deben ejercitar todas las interfaces a fondo.
45
Fig. 4.2 Modelo DRA
E3) Que el alumno realice una investigación sobre las ventajas y desventajas del
modelo DRA.
Ejemplo de Resultados.
Ventajas de RAD
Comprar puede ahorrar dinero en comparación con construir.
Los entregables pueden ser fácilmente trasladados a otra plataforma.
El desarrollo se realiza a un nivel de abstracción mayor.
Visibilidad temprana.
Mayor flexibilidad.
Menor codificación manual.
Mayor involucramiento de los usuarios.
Posiblemente menos fallas.
Posiblemente menor costo.
Ciclos de desarrollo más pequeños.
Interfaz gráfica estándar.
Desventajas de RAD
Comprar puede ser más caro que construir.
46
Costo de herramientas integradas y equipo necesario.
Progreso más difícil de medir.
Menos eficiente.
Menor precisión científica.
Riesgo de revertirse a las prácticas sin control de antaño.
Más fallas.
Prototipos pueden no escalar.
Funciones reducidas (por "timeboxing").
Dependencia en componentes de terceros.
E3) Con base en un análisis crítico-objetivo el alumno debe resumir las condiciones
apropiadas para la aplicación de modelos DRA.
RAD se aplica cuando:
La aplicación funcionará de manera independiente.
Se pueden usar principalmente bibliotecas existentes.
Desempeño no crítico.
Distribución limitada, interna o vertical.
Alcance del proyecto limitado.
Confiabilidad no crítica.
El sistema puede dividirse en muchos módulos independientes.
El producto está dirigido a un mercado altamente especializado.
El proyecto cuenta con fuertes limitantes de tiempos parciales
La tecnología requerida tiene más de un año en el mercado.
E4) Resuelva el siguiente cuestionario:
1. ¿Qué es el Modelo de Desarrollo Rápido de Aplicaciones?
2. ¿Cuáles son las Fases del Modelo del Desarrollo Rápido de Aplicaciones?
3. ¿Mencione algunas de las características del Modelo de Desarrollo rápido de
Aplicaciones?
4. ¿Cuáles son las ventajas del modelo de Desarrollo Rápido de Aplicaciones?
5. ¿Cuáles son las desventajas del modelo de Desarrollo Rápido de Aplicaciones?
4.3 Planeación Didáctica del Modelo de Métodos Formales.
Tiempo.
Se propone cubrir el tema en un intervalo de 4 hrs.
47
Contenido.
•
•
•
Introducción
Modelo de Métodos Formales
Formalismos matemáticos usados en el Modelo de Métodos Formales
Materiales.
Referencias Bibliográficas.
[1] Zohar Manna y Richard Waldinger.
The Logical Basis for Computer Programming.
Vol 1: Deductive Reasoning.
[2] Helmut Ehrig y Bernd Mahr.
Fundamental of Algebraic Specification.
Equations and Initial Semantics.
Springer-Verlag
1985.
[3] Z. Manna y A. Pnueli.
The Temporal Logic of Reactiveand Concurrent Systems.
[4] L. Lamport y N. Lynch.
Distributed Computing: Models and Methods.
Handbook of Theoretical Computer Science.
Elsevier Publishers B.V. 1990.
Recursos Electrónicos.
[5] Formal Methods
http://www.afm.sbu.ac.uk/
4.4 Propuesta de Actividades del Modelo de Métodos Formales.
Actividades Propuestas.
Las acciones que se llevarán a cabo tienen como fin incentivar la utilización del modelo
de Métodos Formales.
48
Actividad 1.
Objetivo.
Estudiar el modelo de Métodos Formales.
Especificaciones.
E1) Que el alumno realice una investigación y redacción sobre el modelo de Métodos
Formales.
Ejemplo de Resultados.
Los métodos formales son un conjunto de tendencias de desarrollo de software en
donde la especificación, verificación y diseño de componentes se realiza mediante
notaciones, lenguajes, herramientas y técnicas basadas en teorías con sólido
fundamento matemático completamente funcional" dentro de periodos cortos de
tiempo.
El uso de notaciones y lenguajes formales permite plantear de manera clara los
requerimientos de un sistema, a través de generar especificaciones que definen el
comportamiento en términos del “qué debe hacer” y no del “cómo lo hace”. Gracias al
proceso correcto de especificación, propiedades derivadas de cada módulo, se pueden
verificar mediante técnicas de razonamiento asociadas a los modelos formales, tales
como, probadores de teoremas y verificadores de modelos. A partir de las
especificaciones, la implementación de un sistema puede ser generada de manera casi
automática. En este proceso, denominado diseño formal, es necesario garantizar que
cada nivel de abstracción generado, cumpla con las propiedades verificadas en las
abstracciones de más alto nivel.
En los procesos de especificación, los lenguajes de especificación formal más
conocidos y utilizados son Z y VDM, los cuales han sido recomendados como un
estándar oficial para la especificación en la construcción de sistemas de software.
E2) Que el alumno realice una investigación sobre en qué tipos de formalismo
matemáticos se basan los Modelos de Métodos Formales.
Ejemplo de Resultados.
Los métodos formales son un conjunto de tendencias de desarrollo de software en
donde la especificación, verificación y diseño de componentes se realiza mediante
notaciones, lenguajes, herramientas y técnicas basadas en teorías con sólido
fundamento matemático completamente funcional" dentro de periodos cortos de
tiempo.
49
El término formal queda caracterizado por la categoría de modelos matemáticos
utilizados. Ejemplos de formalismos son: lógica de primer orden, álgebras, redes de
Petri y lógica temporal.
Los formalismos basados en lógica de primer orden y teoría de conjuntos permiten
especificar el sistema mediante un concepto formal de estado y operaciones sobre
estados. Con este propósito, datos y relaciones/funciones se describen en detalle y sus
propiedades se expresan en lógica de primer orden. La semántica de los lenguajes está
basada en la teoría de conjuntos. Durante el diseño e implementación del sistema, los
elementos descritos matemáticamente pueden modificarse preservando las
características esenciales de la especificación inicial.
Los formalismos algebraicos proponen la descripción de estructuras de datos
estableciendo el nombre de los diferentes conjuntos de datos, funciones básicas y
propiedades. No hay concepto de estado modificable en el tiempo. Las propiedades se
escriben mediante fórmulas, generalmente, ecuaciones. Diferentes modelos semánticos
se han propuesto para caracterizarlas especificaciones algebraicas: modelos iniciales,
finales y laxos. Los modelos iniciales identifican términos cuya igualdad puede ser
probada desde los axiomas. Los modelos finales identifican términos diferentes cuya
desigualdad puede ser probada desde sus axiomas y los modelos laxos identifican todas
las álgebras cuyos elementos pueden denotarse con términos sin variables. Para
describir sistemas (de estructuras de datos) se propone una amplia gama de operadores
de composición y parametrización.
Los formalismos basados en redes de Petri establecen la noción de estado de un
sistema mediante lugares que pueden contener marcas. Un conjunto de transiciones
(con pre y post-condiciones) describe la evolución del sistema entendida como
consumo y producción de marcas en varios puntos de la red. Existe una extensa
literatura sobre las redes de Petri y sus caracterizaciones semánticas: semántica de
entrelazado y semántica basada en concurrencia real.
Los formalismos basados en lógica temporal se usan para describir sistemas
concurrentes y reactivos. Un aspecto común asociado a las diferentes lógicas
temporales es la noción de tiempo y estado. Una especificación escrita en lógica
temporal describe las secuencias admisibles de estados (incluyendo estados
concurrentes) para el sistema especificado.
E3) Con base en un análisis crítico-objetivo el alumno debe resumir las condiciones
apropiadas para utilizar cada formalismo matemático.
E4) Resuelva el siguiente cuestionario:
1. ¿Qué es el Modelo de Métodos Formales?
2. ¿Cuál es la diferencia del Método Formal basado en lógica de primer orden y aquel
basado en lógica temporal?
50
3. ¿Cuál es la diferencia del Método Formal basado en lógica de primer orden y aquel
basado en redes de Petri?
4. ¿Cuál es la diferencia del Método Formal basado en álgebras y aquel basado en
redes de Petri?
5. ¿Cuál es la diferencia del Método Formal basado en redes de Petri y aquel basado
en lógica temporal?.
Recursos.
R1) Consultar bibliografía.
4.5 Referencias Capítulo 4
[1] James Martin
Rapid application development
Macmillan Publishing Co., Inc. Indianapolis, IN, USA
1991
[2] Beynon-Davies P.1; Carne C.1; Mackay H.2; Tudhope D.
Rapid application development (RAD): an empirical review
European Journal of Information Systems, Volume 8, Number 3, 1 Palgrave
MacmillanSeptember 1999 , pp. 211-223(13)
[3] Carlo Ghezzi, Mehdi Jazayeri y Dino Mandrioli.
Fundamentals of Software Engineering. Prentice Hall
International, 1991.
[4] Pressman Roger S.
Ingeniería del Software, Un Enfoque Práctico.
Mc Graw Hill.
[5] Ian Sommerville.
Ingeniería de Software
Addison Wesley.
51
Capítulo 5
Herramientas de Ingeniería de Software
Asistida por Computadora
María Josefa Somodevilla García
María de la Concepción Pérez de Celis Herrero
María del Rocío Boone Rojas
Introducción
En términos generales, la Ingeniería de Software Asistida por Computadora (CASE)
identifica al software que se utiliza para asistir a las actividades del proceso del software,
tales como la Ingeniería de Requerimientos, el diseño, el desarrollo de programas y las
pruebas. De tal forma que las herramientas CASE incluyen, herramientas de diseño,
compiladores, herramientas para construcción de sistemas, etc.
52
La tecnología CASE proporciona ayuda al proceso del software al automatizar
algunas de sus actividades y al proporcionar información acerca del proceso desarrollado.
Esto permite algunas mejoras en la calidad y productividad del software.
En el presente capítulo se revisa el objetivo y el concepto de Herramientas de
Ingeniería de Software Asistida por Computadora. Para los componentes de CASE, se
incluye una taxonomía de herramientas CASE y ejemplos específicos. Como caso de
estudio se considera, el entorno de herramientas integradas para el diseño, administración y
desarrollo de bases de datos SQL, MySqlWorkbench.
5.1 Propuesta de Actividades de Motivación y Diagnóstica para el Estudio
de las Herramientas de Ingeniería de Software Asistida por
Computadora.
Actividades Propuestas.
Actividad 1
Objetivo.
Que el alumno identifique a priori algunas de las ventajas inherentes de utilizar
Herramientas de la Ingeniería de Software Asistida por Computadora.
Especificaciones.
E1) Desarrolla el diseño de una base de datos elemental, mediante el modelo ER y por
medio de las facilidades de diseño o de dibujo de una herramienta de edición básica.
Ejemplo. Considera la siguiente porción de una Base de Datos para la Administración
de una cadena de Talleres-Mecánicos. Los talleres se identifican mediante un Número
de Taller (NTall), tienen un “Supervisor” y se ubican en una “Ciudad”. Cada taller
puede tener varios Mecánicos, los cuales se identifican por una clave “NMec”, y se
registra su nombre y edad. Los mecánicos tienen varias “Especialidades”, tales como
(Afinación, Ajuste de Motor, Sistema Hidráulico, …) pero con diferentes “años” de
experiencia.
53
Ejemplo de Resultados.
Fig. 5.1 Diseño ER, Base de Datos Mecánicos
Mecánicos-Talleres.
E2) Resuelve el siguiente cuestionario:
1. ¿Consideras que la herramienta que utilizaste fue la más adecuada para apoyar el
proceso de diseño de tu base de datos?
2. ¿Por medio de esta herramienta y con respecto al diseño de tu base de datos, se
distinguen claramente las entidades, llaves, atributos y las relaciones de tu base de
datos?
3. ¿A partir del diseño ER de tu base de datos, podrías fácilmente traducirlo a un nivel
lógico, posiblemente a tablas relacionales?
Recursos.
R1) Base de Datos Experimental posiblemente desarrollada en un curso paralelo o
previo.
R2) Procesador de Texto o herramienta equivalente con facilidades de diseño.
54
Actividad 2
Objetivo.
Que el alumno identifique, a priori, algunas de las ventajas inherentes de utilizar
Herramientas de la Ingeniería de Software Asistida por Computadora. Así como en este
caso, el apoyo que pueden ofrecer en la formalización y documentación del proceso de
desarrollo de un proyecto.
Considera la siguiente porción del documento en [5], relacionado con la especificación
de Requisitos funcionales mediante la técnica de “casos de uso” y para un sistema de
gestión de un video club.
Requisitos relacionados con el Almacenamiento de Información.
RI–03
Objetivos asociados
Requisitos
asociados
Descripción
Datos específicos
Intervalo temporal
Estabilidad
Comentarios
Información sobre cuentas de socios
OBJ–02 Gestionar los socios
•
•
•
•
•
•
•
RF–01 Alta de socio
RF–02 Baja de socio
RF–05 Alquiler de cinta de vídeo
RF–08 Devolución de cintas de vídeo
RF–09 Ingreso a cuenta
RF–11 Consulta de un socio
RF–12 Consulta de socios con pagos pendientes
El sistema deberá almacenar la información correspondiente a las
cuentas de los socios del vídeo–club. 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 también la película alquilada y la fecha del alquiler
sólo presente
Alta
Un socio puede hacer ingresos a cuenta, por ejemplo para enviar a
sus hijos por películas sin que éstos tengan que llevar dinero
55
Fig. 5.2 Diagrama de casos de uso del subsistema Gestión de socios
Especificaciones.
E1. Realiza la especificación anterior mediante las facilidades que te proporciona la
herramienta que utilizaste para la actividad anterior.
E2. Resuelve el siguiente cuestionario.
1. ¿Consideras que la herramienta que utilizaste fue la más adecuada para apoyar la
especificación de requisitos desarrollada mediante esta técnica?
2. ¿Por medio de tu herramienta, y con respecto a la especificación realizada, se podría
fácilmente dar seguimiento y durante el proceso de desarrollo del proyecto a los
requisitos establecidos?
3. ¿Por medio de esta especificación, podrías fácilmente, continuar con el proceso de
desarrollo del proyecto?
56
5.2 Planeación Didáctica de los Antecedentes y Conceptos Básicos de
Ingeniería de Software Asistida por Computadora.
Tiempo.
Se propone cubrir el tema en un intervalo de 4 hrs.
Contenido.
5.
6.
7.
8.
El Concepto CASE.
Componentes básicos de CASE.
Taxonomía de Herramientas CASE.
Caso de Estudio. Introducción a una Herramienta de Ingeniería de Software Asistida
por Computadora.
Materiales.
Referencias Bibliográficas.
[1] Capítulo 29
Pressman Roger S.
Ingeniería de Software, Un Enfoque Práctico.
McGraw Hill.
[2] Pags. 11,79-82, 225,280.
Ian Sommerville.
Ingeniería de Software
Addison Wesley.
Recursos Electrónicos.
[3]López Quesada Juan Antonio.
Herramientas CASE
http://dis.um.es/~lopezquesada/documentos/tema%2013.ppt
Alguna herramienta CASE.
Ejemplo.MySQLWorkbench
www.mysql.com/products/workbench/
57
5.3 Desarrollo de las Actividades de Antecedentes y Conceptos Básicos de
Ingeniería de Software Asistida por Computadora.
5.3.1 El Concepto CASE.
Material de Referencia.
De Pressman [2]:
El mejor taller de un artesano -sea mecánico, carpintero o ingeniero del software- tiene
tres características fundamentales: (1) una colección de herramientas útiles que le
ayudarán en todos los pasos de la construcción de un producto; (2) una disposición
organizada que permitirá hallar rápidamente las herramientas y utilizarlas con eficacia; y
(3) un artesano calificado que entienda la forma de utilizar las herramientas de manera
eficaz. Ahora es cuando los ingenieros del software reconocen que necesitan más
herramientas y más variadas, junto con un taller eficiente y organizado en el que puedan
ubicarlas. El taller de ingeniería del software se denomina un entorno de apoyo integrado
a proyectos y el conjunto de herramientas que llena ese taller se denomina ingeniería del
software asistida por computadora (CASE). CASE proporciona al ingeniero la posibilidad
de automatizar actividades manuales y de mejorar su visión general de la ingeniería. Al
igual que las herramientas de ingeniería y de diseño asistidos por computadora que
utilizan los ingenieros de otras disciplinas, las herramientas CASE ayudan a garantizar
que la calidad se diseñe antes de llegar a construir el producto.
En [3] se establece:
Objetivos de la tecnología CASE.
INCREMENTAR
Productividad del equipo.
Calidad del Software.
Reusabilidad del software.
REDUCIR
Costes de desarrollo y mantenimiento.
AUTOMATIZAR
Gestión del proyecto.
Desarrollo del software.
mantenimiento del software (Incluyendo la automatización y
estandarización de la documentación y de su mantenimiento)
AUTOMATIZACIÓN DEL DESARROLLO DE SW.:
Productividad del equipo ↑↑
Calidad del Software ↑↑
58
INCREMENTAR
Reusabilidad del software.
REDUCIR
Costos de desarrollo y mantenimiento.
AUTOMATIZAR/SIMPLIFICAR
Gestión del proyecto.
Desarrollo del sw. (permitir aplicación met. estructuradas;
prototipos; desarrollo “visual”)
Mantenimiento del software (Incluyendo la automatización y
estandarización de la documentación y de su mantenimiento)
Concepto CASE (Computed Aided Software Engineering)
Conjunto de herramientas y métodos asociados que proporcionan asistencia
automatizada en el proceso de desarrollo del software a lo largo de su ciclo de vida.
Gestión del proyecto. (planificación, estimación y control)
Desarrollo del software. (análisis, diseño, implementación, validación)
Mantenimiento del software.
Actividades Propuestas.
Actividad 1
Objetivo.
Que el alumno identifique el concepto de Ingeniería de Software Asistida por
Computadora.
Especificación.
E1) Revisa las referencias [1], [2] y realiza tu propia investigación sobre el concepto de
ingeniería de software asistida por computadora.
-Elabora un mapa conceptual que involucre los principales elementos que involucra el
concepto de ingeniería de software asistida por computadora.
Ejemplo tipo de Resultados.
(Ver mapa conceptual en Programa de curso de la asignatura de Ingeniería de Software,
Modelo MUM).
Recursos.
R1) Referencias [1] y [2]
59
R2) Conexión a Internet.
5.3.2Componentes básicos de CASE.
Material de Referencia.
Revisar Referencias [1] y [2].
De acuerdo a López-Quesada [3]:
Fig. 5.3 Componentes CASE
Interfaz gráfica.
Editor de textos y gráficos.
BD de soporte
(BD del proyecto, depósito o ‘repositorio’ CASE)
Mecanismos de control para:
acceso a componentes.
(datos, código, documentos, dispositivos)
Compatibilidad de las herramientas.
Consistencia de los productos.
Detección de olvidos.
Trazado de modificaciones.
Donde la BD de soporte:
60
Reúne las funciones de:
Catálogo central de archivos y BD’s.
Diccionario de datos y procesos.
Biblioteca de programas y documentación.
y es la base para:
La integración de herramientas.
El mantenimiento de la integridad del sistema.
La coordinación y compartición de información entre usuarios, con controles
de seguridad y privilegios de acceso.
El control de cambios y versiones.
La estandarización de la documentación.
La reutilización del software.
La gestión del proyecto (incluyendo auditorías).
La incorporación a otro sistema informático.
De una forma más específica en [1] se indica:
Aunque se pueden obtener beneficios individualmente de las herramientas CASE que
abarcan actividades de ingeniería del software por separado, la verdadera potencia de
CASE solamente se puede lograr mediante la integración. Entre los beneficios del CASE
integrado (I-CASE) se incluyen: (1) una transferencia regular de información (modelos,
programas, documentos, datos) entre una herramienta y otra, y entre un paso de ingeniería
y el siguiente; (2) una reducción del esfuerzo necesario para efectuar actividades globales
tales como la gestión de configuración de software, el control de calidad y la producción
de documentos; ( 3 ) un aumento del control del proyecto que se logra mediante una mejor
planificación, monitorización y comunicación; (4) una mejor coordinación entre los
miembros del personal que estén trabajando en grandes proyectos de software.
5.3.3Taxonomía de Herramientas CASE.
Material de Referencia.
De acuerdo a [1]
Existe un cierto número de riesgos que son inherentes siempre que se intenta efectuar una
categorización de las herramientas CASE. Existe una sutil implicación que consiste en que
para crear un entorno CASE efectivo se deberán implementar todas las categorías de
herramientas esto no es ni sencillo, ni cierto-. Cuando hay personas que creen que una
herramienta pertenece a una categoría, se puede crear cierta confusión (o contradicción)
al ubicar una herramienta específica dentro de otra categoría. Es posible que algunos
lectores piensen que se ha omitido una categoría completa -e1iminando por tanto un
conjunto de herramientas completo e incluirlo así en el entorno CASE global-. Además,
61
una categorización sencilla tiende a ser plana - esto es, no se muestra la interacción
jerárquica de las herramientas o las relaciones que existen entre ellas-. A pesar de estos
riesgos, es necesario crear una taxonomía de herramientas CASE, para comprender mejor
la amplitud de CASE y para apreciar mejor en donde se pueden aplicar estas herramientas
dentro del proceso del software. Las herramientas CASE se pueden clasificar por su
función, por su papel como instrumentos para administradores o personal técnico, por su
utilización en los distintos pasos del proceso de ingeniería del software, por la arquitectura
del entorno (hardware y software) que les presta su apoyo, o incluso por su origen o costo.
La clasificación de la taxonomía que se presenta a continuación utiliza como criterio
principal la función.
Herramientas de ingeniería de procesos de negocio.
Modelado de procesos y herramientas de gestión.
Modelado de procesos y herramientas de gestión.
Herramientas de análisis de riesgos.
Herramientas de gestión de proyectos.
Herramientas de seguimiento de requisitos.
Herramientas de métricas y de gestión.
Herramientas de documentación.
Herramientas de software de sistema.
Herramientas de control de calidad.
Herramientas de gestión de bases de datos del proyecto.
Herramientas de gestión de configuración de software.
Herramientas de análisis y diseño.
Herramientas PRO/SIM. (De construcción de prototipos y simulación).
Herramientas de desarrollo y diseño de interfaz.
Herramientas de construcción de prototipos.
Herramientas de programación.
Herramientas de desarrollo de Webs.
Herramientas de integración y pruebas.
Herramientas de análisis estático.
Herramientas de análisis dinámico.
Herramientas de gestión de pruebas.
Herramientas de pruebas cliente/servidor.
Herramientas de reingeniería.
En la taxonomía de [3] se incluyen ejemplos específicos dentro de algunas de sus
categorías:
Herramientas de análisis y diseño.
62
Permiten crear y verificar DFD’s, diagramas E/R, de clase, de estructura...
Herramientas de prototipado:
Diseñadores de pantallas
Generadores de menús
Generadores de informes
Lenguajes de especificación ejecutables
Ejemplos:
DESIGNER/2000 de ORACLE
EASY CASE de Evergreen
Rational ROSE
EXCELERATOR de Intersolv
OBJECT MAKER de Mark IV.
OMTool de GTE.
PARADIGM Plus de Platinum
SILVERRUN de CSA Research
SYSTEM Architect de PopkinSofware& Systems
Herramientas de acuerdo a su funcionalidad.
Herramientas de gestión de proyectos ayudan a la planificación y seguimiento del
proyecto
Planificación: agenda de desarrollo.
Estimación: costes, duración, esfuerzo.
Control: productividad, calidad.
Herramientas de análisis y diseño.
Herramientas de prototipado y simulación.
Herramientas de programación.
Editores dirigidos por la sintaxis (cabeceras de subrutinas, palabras clave,
indentación, nomenclatura de variables, ...)
Generadores de estructuras de programas.
Entornos integrados de desarrollo para soporte de un lenguaje (editor,
compilador, depurador).
Herramientas de integración y pruebas.
Analizadores estáticos.
Depuradores.
Generadores de datos.
Comparadores (e.g. de archivos).
Herramientas de soporte.
Herramientas de mantenimiento.
Ingeniería inversa.
63
Reingeniería.
En [2] se presenta un ejemplo ilustrativo de una posible clasificación de la tecnología
CASE como ayuda para el proceso del software.
Se puntualiza que la tecnología CASE proporciona ayuda automatizada a los
procesos del software. Las herramientas CASE ayudan a las actividades individuales del
proceso; los bancos de trabajo ayudan a un conjunto de actividades relacionadas; los
entornos ayudan a todas o a la mayoría de las actividades del proceso del software.
Fig. 5.4 Herramientas, Bancos de Trabajo y Entornos.
Actividad 1
Objetivo.
Que el alumno organice una versión propia de una taxonomía de herramientas CASE, como
resultado de la consulta de al menos tres referencias.
Especificaciones.
E1. Revisa la taxonomía de herramientas CASE en las referencias [1] [2] [3].
64
E2. Organiza en una tabla una taxonomía que resulte de la unión de los diferentes tipos de
herramientas CASE que se consideran en las taxonomías de las referencias [1] [2] y [3].
Ejemplo de resultados.
Tomar como referencia alguna de las taxonomías incluidas en [1] [2] y [3].
Actividad 2
Objetivo.
Que el alumno conozca que existen muy diversos tipos de herramientas CASE y que
pueden ser de diferentes tipos, propósitos y alcances.
Especificaciones.
E1) Realiza una búsqueda por Internet y toma como referencia la taxonomía de
herramientas CASE que se ha revisado en este capítulo. Desarrolla una breve
documentación sobre cinco herramientas de diferentes tipos. Incluye al menos la siguiente
información:
Nombre.
Empresa.
Propósito.
Puedes organizar tus resultados en una tabla.
Ejemplo de Tipo de Resultados.
Nombre
Herramienta
MySQLWorkbench.
Empresa
Oracle.
Propósito
Entorno integrado de herramientas para el
administración y desarrollo de bases de datos SQL.
diseño,
Recursos.
R1) Conexión a internet.
65
Actividad 3
Objetivo.
Que el alumno esté informado sobre las facilidades básicas de un entorno integrado / banco
de Trabajo CASE.
Especificaciones.
E1) Toma como referencia la investigación realizada en la actividad anterior, selecciona un
entorno integrado de herramientas CASE que sea de tu interés, realiza un breve reporte (3-5
cuartillas) sobre sus características generales y facilidades básicas.
Ejemplo de Tipo de Resultados.
(Complementar información de Caso de Estudio de la Sig. sección)
5.3.4Caso de Estudio. Introducción a una Herramienta de Ingeniería de
Software Asistida por Computadora.
Se propone revisar las facilidades básicas y a nivel de introducción de alguna herramienta
de Ingeniería de Software Asistida por Computadora. Ej. Para el diseño de Bases de Datos,
Para Especificación de Requisitos/ Casos de Uso, Generador de Reportes, entre otros.
Ejemplo. Introducción al entorno de herramientas MySQLWorkbench para el caso de
diseño de bases de Datos. Se propone revisar las características generales del producto,
Fig. 5.5. y a continuación ofrecer un panorama general de las facilidades básicas para el
diseño de base de datos de la herramienta, Fig. 5.6.
66
Fig. 5.5Workbench Central.
Fig. 5.6 Herramientas para diseño visual de bases de datos en MysqlWorkbench.
67
Actividad 1.
Objetivo. Que el alumno realice una experimentación básica con alguna herramienta
CASE, en este caso para el diseño de bases de datos mediante las herramientas de
Mysql Workbench.
Especificaciones.
E1. Considera la base de datos experimental cuyo diseño desarrollaste en la actividad 1
de la Sección 5.1.
E2. Desarrolla el diseño de tu base de datos experimental mediante las facilidades para
el diseño de bases de datos de Mysql Workbench.
5.4 Comentarios, Conclusiones y Actividades Complementarias sobre los
Antecedentes y Conceptos Básicos de Ingeniería de SoftwareAsistida por
Computadora.
-Se propone dar continuidad a las actividades de investigación y experimentación
realizadas previamente.
-Se propone continuar experimentando con la herramienta CASE que se ha abordado como
caso de estudio.
-Se propone realizar investigación y experimentación complementaria sobre otro tipo de
herramientas CASE más especializadas, tales como para la Admon. De Proyectos o
Ingeniería Web.
-Realizar una discusión grupal sobre las posibles ventajas del desarrollo de proyectos
individuales y/o grupales mediante el apoyo de la tecnología CASE.
5.5 Referencias, Capítulo 5
Referencias Bibliográficas.
[1] Capítulo 29 / 31
Pressman Roger S.
Ingeniería de Software, Un Enfoque Práctico.
McGraw Hill.
68
[2] Pags. 11,79-82, 225,280.
Ian Sommerville.
Ingeniería de Software
Addison Wesley.
Recursos Electrónicos.
[3]López-Quesada, Juan Antonio.
Herramientas CASE
http://dis.um.es/~lopezquesada/documentos/tema%2013.ppt
[4] MySQL Workbench
www.mysql.com/products/workbench/
[5] Domínguez D., R. García.
“Ejemplo de Casos de Uso, Gestión de un Video Club”.
http://www.dsic.upv.es/asignaturas/facultad/si/trabajos/032000.doc
69
Capítulo 6
Modelos Ágiles de Procesos.
Josefina Guerrero García
Juan Manuel González Calleros
Introducción
La ingeniería de software ha evolucionado en los últimos años y se ha adaptado al entorno
dinámico donde es usada y como tal sus métodos han evolucionado. Es ahí donde nacen los
métodos ágiles que promueven, entre otras cosas, la adaptación constante y efectiva a los
cambios que ocurren con las necesidades del cliente. Este capítulo introduce brevemente
los conceptos de los métodos ágiles como una invitación al alumno a descubrirlos a lo largo
del curso.
El docente tiene como objetivo motivar la importancia actual que tienen los
métodos ágiles y que favorecen la retención de los conceptos relevantes al tema. La
asignación de actividades dinámicas que ayuden a retener los conceptos aquí presentados es
el objetivo de esta unidad.
El alumno se tendrá que involucrar en las actividades grupales e individuales de tal
forma que vaya adquiriendo el conocimiento asociado a los métodos ágiles.
En el presente capítulo se propone una serie de actividades de aprendizaje para que
el docente pueda desarrollar en su clase los siguientes aspectos:
70
o
o
o
o
Modelos Ágiles de Proceso
Programación Extrema
Metodologías Cristal
Scrum
6.1 Propuesta de actividades de motivación y diagnóstica para el estudio
de modelos ágiles de proceso.
Actividades Propuestas.
Actividad 1. Identificación de limitantes de métodos actuales de ingeniería de
software
Objetivo. El alumno será capaz de identificar las limitantes de los métodos de desarrollo
de software tradicionales y proponer mejoras.
Especificaciones.
Plantear un caso de estudio simple, donde sean muy notorias las limitantes del uso de
un método tradicional. Dar oportunidad al alumno a la reflexión considerando el
conocimiento ya adquirido sobre procesos de desarrollo de software usando una lista de
fallas en el software para que puedan identificar las causas de las fallas.
Ver video de Ariane 5. Disponible en http://www.youtube.com/watch?v=gp_D8r-2hwk
El 4 de junio de 1996, el primer vuelo de la nueva Agencia Aeroespacial Europea lanzó
el cohete Ariane 5, mismo que falló poco después del lanzamiento, lo que resultó en una
pérdida estimada de mil quinientos millones de dólares.
El problema:
71
La altitud y trayectoria del cohete es medía por un equipo de referencia
inercial computarizado. Este transmitía los comandos a los motores para mantener la
altitud y la dirección.
a. El software falló y este sistema y el sistema de soporte se apagaron
b. Los comandos de diagnóstico fueron transmitidos a los motores lo cuales
fueron interpretados como datos reales e hicieron girar el cohete a una posición
extrema
Falla de software:
Un Fallo de software se produjo cuando se intentó hacer una conversión de un número de
64 bits de punto flotante, a un entero con signo de 16 bits, lo que hizo que se desbordara la
memoria.
a. No había manejador de excepciones asociado con la conversión de números. Por
seguridad, ésto apagó la computadora.
b. La aplicación de respaldo tenía el mismo error así que, también falló.
Se pudo evitar la catástrofe
El software que falló fue rehusado del sistema del Ariane 4. El cálculo computacional que
falló no fue usado en el Ariane 5. Se tomaron decisiones en su momento:
a. No quitar esta facilidad ya que podría producir errores no controlados
b. No poner a prueba las excepciones de desbordamiento de memoria ya que el
procesador estaba muy cargado. Por razones de fiabilidad, se pensaba
que era deseable tener un poco de capacidad del procesador de repuesto
c. En el Ariane 4 nunca se hubiera generado este error pues la velocidad nunca
sería tan rápida como la del Ariane 5.
La cadena de omisiones
Esta funcionalidad del Ariane 4 no era necesaria en el Ariane 5 por lo tanto nunca fue un
requerimiento.
Dado que no era requerimiento nunca se probó su funcionalidad ni correcta operación
durante las pruebas.
La simulación nunca llego a este escenario ya que no estaba en la lista de pruebas.
Lección aprendida
Todo software debe ser revisado y probar que funcione
No ejecutar software en sistemas críticos a menos que sea realmente necesario (por eso los
aviones no llevan computadoras para controlar el avión, sino puros controles y sensores)
Así como se prueba lo que el sistema debe hacer se debe probar lo escenarios donde el
sistema hace lo que no debe hacer
Tomar en cuenta todas las variantes de excepciones que pueden ocurrir y no recaer
en el uso del gestor por default de excepciones
En cálculos computacionales críticos, siempre tener clara la alternativa numérica a
asignar en caso de error al sistema
En la medida de la posibilidad hacer pruebas reales y no solo simulaciones
72
Mejorar el proceso de revisión incluyendo participantes externos y revisando todas
las suposiciones que se hacen en el código
El diseñador del Ariane 5 cometió un error elemental pero critico. Diseño un
sistema complejo donde la falla de un componente simple lo hizo fallar. Errores muy
graves pese a que el software estaba dirigido por método formal, rígido.
Ahora el alumno debe identificar en los siguientes casos las causas posibles del error de
software.
Ejemplo de Resultados.
1. En febrero de 2008, problemas de software en el sistema automático de
clasificación de equipajes en un aeropuerto importante, impidieron la partida de
miles de pasajeros al no poder documentar su equipaje para sus respectivos
vuelos Se informó que la falla se produjo durante una actualización de software,
a pesar de la pre-prueba del mismo. El sistema continuó teniendo problemas en
los meses siguientes. Pruebas no exhaustivas.
2. Informes de prensa en diciembre de 2007 indicaban que seguían ocurriendo
problemas importantes de software en un nuevo sistema de nóminas ERP para
un sistema escolar urbano. Se pensaba que en varias ocasiones, más de un tercio
de los empleados, había recibido cheques de pago incorrectos, desde que el
nuevo sistema se puso en marcha en enero, lo que dio lugar a pagos en exceso
por 53 millones de dólares, además de otros pagos erróneos. El sindicato de
trabajadores presentó una demanda contra el sistema escolar, se espera que el
costo del sistema ERP aumente en un 40%, y la parte que no pertenece a la
nómina del sistema de ERP se retrasó. Según los informes, pruebas
inadecuadas han contribuido a los problemas.
3. En noviembre de 2007 un gobierno regional interpuso una demanda
multimillonaria en contra de un proveedor de servicios de software, afirmando
que èste "minimizó la calidad del software " de un gran sistema de información
sobre justicia penal y que por lo tanto, el sistema no cumplía los requisitos. El
vendedor también demandó a su subcontratista en el proyecto. Fallo de
comunicación, ausencia de interacción con el cliente ya que seguramente al
ser subcontratado no trabajaba directamente con los actores involucrados.
4. Según informes periodísticos, en abril de 2007, un problema de software
contribuyó a un incendio de vagones de ferrocarril, en un importante sistema de
metro. Se comunicó que el software no funcionó como era de esperarse para
detectar y prevenir el exceso de consumo de energía en los equipos de un vagón
de pasajeros nuevo, ocasionando un sobrecalentamiento y fuego en dicho vagón,
73
la consecuente evacuación y el cierre de parte del sistema. Falta de pruebas,
liberación temprana del sistema.
E1) Identificar problemas a partir de la lista arriba descrita
Recursos.
R1) Caso de estudio de experiencia de desarrollo de software fallida. Material
descriptivo de métodos tradicionales de ingeniería de software. Lista de errores de
software.
6.2 Planeación Didáctica de modelos agiles de proceso.
Tiempo.
Se propone cubrir el tema en un intervalo de 5 hrs.
• 2 h. para la introducción a los métodos ágiles (sección x.2.3)
• 2 h. para la descripción de los diferentes procesos (sección x.2.4)
• 1h. para consolidar el conocimiento adquirido (sección x.2.5)
Contenido.
9. Modelo Ágiles de proceso
10. Programación Extrema
11. Cristal
12. Scrum
13. Melé
Materiales.
Texto en este capítulo.
Metodos-Agiles.PDF
nerur.pdf
carlos-reynoso-metodos-agiles-academia.ppt
Referencias Bibliográficas.
[1] SridharNerur, RadhaKantaMahapatra, George Mangalaraj
Challenges of migrating to agile methodologies
Communications of the ACM - Adaptive complex enterprises
Volume 48 Issue 5, May 2005
74
[2] Desarrollo de Software mediante Metodologías Ágiles.
http://www.snip.gob.ni/Xdc/Agile/Agile.htm
[3] Capitulo1
Ken Schwaber, Mike Beedle
Agile Software Development with Scrum
Prentice Hall
[4] Carlos Reynoso
Métodos Ágiles en desarrollo de software
UNIVERSIDAD DE BUENOS AIRES
http://carlosreynoso.com.ar/archivos/arquitectura/Metodos-Agiles.PDF
[7] GrigoriMelnik
Microsoft p&p summit, 2007
Empirical Evidence Of Agile Methods
http://www.slideshare.net/melnik/empirical-evidence-of-agile-methods-190997
6.3 Desarrollo de las Actividades de Introducción a los métodos ágiles de
la Ingeniería de Software.
6.3.1 Introducción a los modelos ágiles.
Material de Referencia.
Síntesis y extracción de [4]:
“Los modelos de los métodos clásicos difieren bastante en su conformación y en su
naturaleza, pero exaltan casi siempre las virtudes del planeamiento y poseen un espíritu
normativo. Comienzan con la licitación y el análisis completo de los requerimientos del
usuario. Después de un largo período de intensa interacción con usuarios y clientes, los
ingenieros establecen un conjunto definitivo y exhaustivo de rasgos, requerimientos
funcionales y no funcionales. Esta información se documenta en forma de especificaciones
para la segunda etapa, el diseño, en el que los arquitectos, trabajando junto a otros expertos
en temas puntuales (como ser estructuras y bases de datos), generan la arquitectura del
sistema. Luego los programadores implementan ese diseño bien documentado y finalmente,
el sistema completo se prueba y se despacha. ”
75
Castigando sobre todo al modelo en cascada se ha publicado:
“Gran parte de los procedimientos actuales de adquisición de software reposan en el
supuesto de que se puede especificar de antemano un sistema satisfactorio, obtener
requisitos para su construcción, construirlo e instalarlo. Pienso que este supuesto es
fundamentalmente equivocado y que muchos de los problemas de adquisición se
originan en esta falacia.”
Descrédito de los procesos en cascada
(1988) Department of Defense Standard 2167A), titled "Defense Systems
Software Development → MIL STD 498 "establish uniform requirements
for software development and documentation." (1994)
Crisis de confianza en los procesos regidos por metodologías prescriptivas con
análisis completo de requerimientos y planificación detallada
CMM, CMMI, Spice, Bootstrap, TickIt, ISO 9000
CMM no es una metodología ni un modelo en cascada, pero “coincide con su
espíritu”
Legislación negativa sobre conformidad con estándares de calidad
Ante esa evidencia los expertos, en masa, aconsejaron el abandono de los métodos
en cascada y las normativas fuertes. Trabajaron en sus propias alternativas dinámicas,
iterativas, evolutivas y en suma, ágiles. Reforzado por el entorno donde se trabaja Nerur [1]
expone:
“Software development methodologies are constantly evolving due to changing
technologies and new demands from users. Today’s dynamic business
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
requirements—but the traditional, plan-driven software development methodologies
lack the flexibility to dynamically adjust the development process.”
A comienzos del siglo XXI ante el descrédito de los métodos tradicionales se daban
las condiciones para los 17 proponentes de métodos ágiles se juntaran en marzo de 2001 en
Salt Lake City para discutir los nuevos métodos. Lo que surgió de su reunión fue el
Manifiesto Ágil de Desarrollo de Software. De donde surgen ideas como:
De hecho, muchos de nosotros deseamos restaurar credibilidad a la palabra
metodología. Queremos recuperar un equilibrio. Promovemos el modelado, pero
no con el fin de archivar algún diagrama en un polvoriento repositorio corporativo.
Promovemos la documentación, pero no cientos de páginas en tomos nunca
mantenidos y rara vez usados. Planificamos, pero reconocemos los límites de la
planificación en un entorno turbulento.
•
•
•
•
1
Los individuos y la interacción por encima de los procesos y
herramientas.La gente es el principal factor de éxito de un proyecto
software. No se necesitan desarrolladores brillantes, sino
desarrolladores que se adapten bien al trabajo en equipo. Así mismo,
las herramientas (compiladores, depuradores, control de versiones,
etc.) son importantes para mejorar el rendimiento del equipo, pero el
disponer de más recursos que los estrictamente necesarios también
puede afectar negativamente.
El software que funciona por encima de la documentación
abarcadora. Aunque se parte de la base de que el software sin
documentación es un desastre, la regla a seguir es “no producir
documentos a menos que sean necesarios de forma inmediata para
tomar un decisión importante”. Estos documentos deben ser cortos y
centrarse en lo fundamental.
La colaboración con el cliente por encima de la negociación
contractual. Se propone que exista una interacción constante entre el
cliente y el equipo de desarrollo. Esta colaboración entre ambos será
la que marque la marcha del proyecto y asegure su éxito.
La respuesta al cambio por encima del seguimiento de un plan. La
habilidad de responder a los cambios que puedan surgir a los largo
del proyecto (cambios en los requisitos, en la tecnología, en el
equipo, etc.) determina también el éxito o fracaso del mismo. Por lo
tanto, la planificación no debe ser estricta puesto que hay muchas
variables en juego, debe ser flexible para poder adaptarse a los
cambios que puedan surgir.
Truex, D.P., Baskerville, R. and Klein, H. Growing systems in emergent organizations. Commun. ACM 42, 8 (Aug. 1999), 117–123.
77
Aunque hay valor en los elementos a la derecha, valorizamos más los de la
izquierda.
Los principios que rigen a la comunidad de métodos ágiles:
1. Nuestra prioridad más alta es satisfacer al cliente a través de la entrega
temprana y continua de software valioso.
2. Los requerimientos cambiantes son bienvenidos, incluso cuando llegan
tarde en el desarrollo. Los procesos ágiles se pliegan al cambio en procura
de una ventaja competitiva para el cliente.
3. Entregar con frecuencia software que funcione, desde un par de semanas
hasta un par de meses, con preferencia por las escalas de tiempo más breves.
4. La gente de negocios y los desarrolladores deben trabajar juntos
cotidianamente a través de todo el proyecto.
5. Construir proyectos en torno de individuos motivados. Darles la
oportunidad y el respaldo que necesitan y procurarles confianza para que
realicen la tarea.
6. La forma más eficiente y efectiva de comunicar información de ida y vuelta
dentro de un equipo de desarrollo es mediante la conversación cara a cara.
7. El software que funciona es la medida primaria de progreso.
8. Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores,
desarrolladores y usuarios deben mantener un ritmo constante
indefinidamente.
9. La atención continua a la excelencia técnica enaltece la agilidad.
10. La simplicidad (el arte de maximizar la cantidad de trabajo que no se hace)
es esencial.
11. Las mejores arquitecturas, requerimientos y diseños emergen de equipos
que se auto organizan.
12. A intervalos regulares, el equipo reflexiona sobre la forma de ser más
efectivo, y ajusta su conducta en consecuencia.
Nerur [1] realza las diferencias entre métodos ágiles y tradicionales en el siguiente gráfico.
78
Los modelos ágiles se pueden describir como aquellos modelos que son lo
suficientemente buenos, donde cumplen con las siguientes características: satisfacen un
propósito, son inteligentes, son lo suficientemente precisos, son lo suficientemente
detallados, aportan valor positivo y son lo más simple posible. Para poder tener más clara
las ideas un modelo ágil es más eficiente que los modelos tradicionales, un prototipo de
papel podría ser un modelo ágil, un dibujo de pizarra podría ser un modelo ágil, un
diagrama de Visio puede ser un modelo ágil o un modelo de datos físicos podría ser un
modelo ágil. El tipo de modelo, o herramienta con la que se creó en realidad no importa, lo
importante es que el modelo sólo sea sólo lo suficientemente bueno para obtener su
máximo provecho.
El desarrollo ágil de software es un marco de trabajo conceptual de la ingeniería de
software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del
proyecto. Existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos
desarrollando software en lapsos cortos de tiempo. El software desarrollado en una unidad
de tiempo es llamado una iteración, la cual debe durar de una a cuatro semanas. Cada
iteración del ciclo de vida incluye: planificación, análisis de requerimientos, diseño,
codificación, revisión y documentación. Una iteración no debe agregar demasiada
funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener
un demo (sin errores) al final de cada iteración. Al final de cada iteración el equipo vuelve a
evaluar las prioridades del proyecto. La mayoría de los equipos ágiles están localizados en
una simple oficina abierta, a veces llamadas "plataformas de lanzamiento". La oficina debe
incluir revisores, escritores de documentación y ayuda, diseñadores de iteración y
directores de proyecto. Los métodos ágiles también enfatizan que el software funcional es
la primera medida del progreso.
79
Actividades Propuestas.
Actividad 1. Requerimientos para cambiar de un paradigma clásico a uno ágil
Objetivo.
Que el alumno proponga los cambios organizacionales necesarios para adoptar un proceso
de desarrollo ágil.
Especificación.
E1) Llena la siguiente tabla en equipos de 4 indicando los cambios necesarios para adoptar
un proceso iterativo.
Cambio organizacional y en la administración
Cambio en la gente
Cambio en los procesos
Cambio en la tecnología (técnicas y herramientas)
Ejemplo tipo de Resultados.
Cambio organizacional y en la administración
•
•
•
•
•
Cultura organizacional
Estilo de administración
Forma organizacional
Manejo del conocimiento de desarrollo de software
Sistemas de recompensas
Cambio en la gente
• Trabajo efectivo en equipo
• Alto nivel de competencias
• Relaciones con clientes – compromiso, conocimiento, proximidad, confianza, respeto
Cambio en los procesos
• Cambio de un proceso centralizado a uno guiado por características, centrado en la persona
80
• Guiado por elementos como ser: corto, iterativo, evaluativo con énfasis en la adaptabilidad
• Manejo de proyectos grandes y escalables
• Selección del proceso ágil adecuado a la empresa
Cambio en la tecnología (técnicas y herramientas)
Revisar que herramientas y tecnología sean apropiadas
Desarrollo de nuevas habilidades -
Recursos.
R1) Referencia [1]
R2) Material de esta sección
6.4 Desarrollo de las actividades de métodos ágiles de la ingeniería de
software.
6.4.1 PROGRAMACIÓN EXTREMA [extreme programming( XP)]
Kent Beck [5] sentó las bases de los patrones de diseño y XP en 1999. XP es la primera
metodología ágil y la que le dio conciencia al movimiento actual de metodologías ágiles, se
centra en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de
software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los
desarrolladores, y propiciando un buen clima de trabajo. XP se basa en retroalimentación
continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los
participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los
cambios [6]. XP se define como especialmente adecuada para proyectos con requisitos
imprecisos y muy cambiantes, y donde existe un alto riesgo técnico.
Los principios y prácticas son de sentido común pero llevadas al extremo, de ahí
proviene su nombre.
Las características esenciales de XP se pueden organizar en: historias de usuario, roles,
proceso y prácticas.
A. Las Historias de Usuario [Tarjetas de historia (StoryCards)]
Son la técnica utilizada para especificar los requisitos del software. Se trata de tarjetas de
papel en las cuales el cliente describe brevemente las características que el sistema debe
poseer, sean requisitos funcionales o no funcionales. Las tarjetas se usan para estimar
prioridades, alcance y tiempo de realización; en caso de discrepancia, gana la estimación
más optimista. El tratamiento de las historias de usuario es muy dinámico y flexible. Cada
historia de usuario es lo suficientemente comprensible y delimitada para que los
programadores puedan implementarla en unas semanas. Un ejemplo de ficha presenta los
siguientes contenidos: fecha, tipo de actividad (nueva, corrección, mejora), prueba
funcional, número de historia, prioridad técnica y del cliente, referencia a otra historia
previa, riesgo, estimación técnica, descripción, notas y una lista de seguimiento con la
81
fecha, estado, cosas por terminar y comentarios. A efectos de planificación, las historias
pueden ser de una a tres semanas de tiempo de programación (para no superar el tamaño de
una iteración). Las historias de usuario son descompuestas en tareas de programación
(taskcard) y asignadas a los programadores para ser implementadas durante una iteración.
B. Roles XP
Los roles de acuerdo con la propuesta original de Beck son:
- Programador. El programador escribe las pruebas unitarias y produce el código del
sistema.
- Cliente. Escribe las historias de usuario y las pruebas funcionales para validar su
implementación. Además, asigna la prioridad a las historias de usuario y decide cuáles se
implementan en cada iteración centrándose en aportar mayor valor al negocio.
- Encargado de pruebas (Tester). Ayuda al cliente a escribir las pruebas funcionales.
Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de
las herramientas de soporte para pruebas.
- Encargado de seguimiento (Tracker). Proporciona realimentación al equipo. Verifica el
grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, para mejorar
futuras estimaciones. Realiza el seguimiento del progreso de cada iteración.
- Entrenador (Coach). Es responsable del proceso global. Debe proveer guías al equipo de
forma que se apliquen las prácticas XP y se siga el proceso correctamente.
- Consultor. Es un miembro externo del equipo con un conocimiento específico en algún
tema necesario para el proyecto, en el que puedan surgir problemas.
- Gestor (Big boss). Es el vínculo entre clientes y programadores, ayuda a que el equipo
trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de
coordinación.
C. Proceso XP
Un proyecto XP tiene éxito cuando el cliente selecciona el valor de negocio a implementar
basado en la habilidad del equipo para medir la funcionalidad que puede entregar a través
del tiempo. El ciclo de desarrollo consiste en los siguientes pasos:
1. El cliente define el valor de negocio a implementar.
2. El programador estima el esfuerzo necesario para su implementación.
3. El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones
de tiempo.
4. El programador construye ese valor de negocio.
5. Vuelve al paso 1.
En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No
se debe presionar al programador a realizar más trabajo que el estimado, ya que se perderá
calidad en el software o no se cumplirán los plazos. De la misma forma el cliente tiene la
obligación de manejar el ámbito de entrega del producto, para asegurarse que el sistema
tenga el mayor valor de negocio posible con cada iteración.
82
El ciclo de vida ideal de XP consiste de seis fases: Exploración, Planificación de la Entrega
(Release), Iteraciones, Producción, Mantenimiento y Muerte del Proyecto.
Figura 1 Ciclo de vida de XP, fuente [8]
D. Prácticas XP
La principal suposición que se realiza en XP es la posibilidad de disminuir la mítica curva
exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el diseño
evolutivo funcione. Esto se consigue gracias a las tecnologías disponibles para ayudar en el
desarrollo de software y a la aplicación disciplinada de las siguientes prácticas.
• Juego de Planeamiento. Busca determinar rápidamente el alcance de la versión
siguiente, combinando prioridades de negocio definidas por el cliente con las
estimaciones técnicas de los programadores. Éstos estiman el esfuerzo necesario para
implementar las historias del cliente y éste decide sobre el alcance y la agenda de las
entregas. Las historias se escriben en pequeñas fichas, que algunas veces se tiran.
Cuando esto sucede, lo único restante que se parece a un requerimiento es una multitud
de pruebas automatizadas, las pruebas de aceptación.
• Entregas pequeñas y frecuentes. Se “produccioniza” un pequeño sistema
rápidamente, al menos uno cada dos o tres meses. Pueden liberarse nuevas versiones
diariamente (como es práctica en Microsoft); se agregan pocos rasgos cada vez.
• Metáforas del sistema. El sistema de define a través de una metáfora o un conjunto de
metáforas, una “historia compartida” por clientes, managers y programadores que
orienta todo el sistema describiendo como funciona. Una metáfora puede interpretarse
como una arquitectura simplificada.
• Diseño simple. El énfasis se deposita en diseñar la solución más simple susceptible de
implementarse en el momento. Se eliminan complejidades innecesarias y código extra,
y se define la menor cantidad de clases posible. No debe duplicarse el código.
• Prueba continua. El desarrollo está orientado por las pruebas. Los clientes ayudan a
escribir las pruebas funcionales antes de que se escriba el código. El propósito del
código real no es cumplir un requerimiento, sino pasar las pruebas. Las pruebas y el
código son escritas por el mismo programador, pero la prueba debería realizarse sin
intervención humana, y es a todo o nada. Hay dos clases de prueba: 1) la prueba
unitaria, que verifica una sola clase, o un pequeño conjunto de clases y2) la prueba de
aceptación que verifica todo el sistema, o una gran parte.
83
•
•
•
•
•
•
•
•
•
Refactorízación continua. Se refactoriza el sistema eliminando duplicación,
mejorando la comunicación y agregando flexibilidad sin cambiar la funcionalidad La
práctica también se conoce como Mejora Continua de Código o Refactorízación
implacable.
Programación en pares. Todo el código está escrito por pares de programadores. Dos
personas escriben código en una computadora, turnándose en el uso del ratón y el
teclado. El que no está escribiendo, piensa desde un punto de vista más estratégico y
realiza lo que podría llamarse revisión de código en tiempo real. Los roles pueden
cambiarse varias veces al día.
Propiedad colectiva del código. Cualquiera puede cambiar cualquier parte del código
en cualquier momento, siempre que escriba antes la prueba correspondiente.
Integración continua. Cada pieza se integra a la base de código apenas está lista,
varias veces al día. Debe correrse la prueba antes y después de la integración. Hay una
máquina (solamente) dedicada a este propósito.
Ritmo sostenible, trabajando un máximo de 8 horas por día. Antes se llamaba a esta
práctica Semana de 40 horas. Dado que el desarrollo de software se considera un
ejercicio creativo, se estima que hay que estar fresco y descansado para hacerlo
eficientemente; con ello se motiva a los participantes, se evita la rotación del personal y
se mejora la calidad del producto.
Todo el equipo en el mismo lugar. El cliente debe estar presente y disponible a tiempo
completo para el equipo. También se llama El Cliente en el Sitio. Como esto parecía no
cumplirse, se especificó que el representante del cliente debe ser preferentemente un
analista.
Estándares de codificación. Se deben seguir reglas de codificación y comunicarse a
través del código. Algunos practicantes se ponen de acuerdo en estilos de notación,
indentación y nomenclatura, así como en un valor apreciado en la práctica, el llamado
“código revelador de intenciones”.
Espacio abierto. Es preferible una sala grande con pequeños cubículos o, mejor
todavía, sin divisiones. Los pares de programadores deben estar en el centro. En la
periferia se ubican las máquinas privadas.
Reglas justas. El equipo tiene sus propias reglas a seguir, pero se pueden cambiar en
cualquier momento. En XP se piensa que no existe un proceso que sirva para todos los
proyectos; lo que se hace habitualmente es adaptar un conjunto de prácticas simples a
las características de cada proyecto.
El mayor beneficio de las prácticas se consigue con su aplicación conjunta y equilibrada
puesto que se apoyan unas en otras. Esto se ilustra en la Figura 2, donde una línea entre dos
prácticas significa que las dos prácticas se refuerzan entre sí. La mayoría de las prácticas
propuestas por XP no son novedosas sino que en alguna forma ya habían sido propuestas en
ingeniería del software e incluso demostrado su valor en la práctica. El mérito de XP es
integrarlas de una forma efectiva y complementarlas con otras ideas desde la perspectiva
del negocio, los valores humanos y el trabajo en equipo.
84
Figura 2 Las prácticas se refuerzan entre sí.
6.4.2 Metodologías Crystal [Crystal Methodologies (CM)]
Las metodologías Crystal fueron creadas por el “antropólogo de proyectos” Alistair
Cockburn en 1998.Se trata de un conjunto de metodologías para el desarrollo de software
caracterizadas por estar centradas en las personas que componen el equipo (de ellas
depende el éxito del proyecto) y la reducción al máximo del número de artefactos
producidos. La familia Crystal dispone un código de color para marcar la complejidad de
una metodología: cuanto más oscuro un color, más “pesado” es el método. Cuanto más
crítico es un sistema, más rigor se requiere. El código cromático se aplica a una forma
tabular elaborada por Cockburn que se usa en muchos MAs para situar el rango de
complejidad al cual se aplica una metodología. En la figura se muestra una evaluación de
las pérdidas que puede ocasionar la falla de un sistema y el método requerido según este
criterio. Los parámetros son Comodidad (C), Dinero Discrecional (D), Dinero Esencial (E)
y Vidas (L). En otras palabras, la caída de un sistema que ocasione incomodidades indica
que su nivel de criticalidad es C, mientras que si causa pérdidas de vidas su nivel es L. Los
números del cuadro indican el número de personas afectadas a un proyecto, ±20%.
Los métodos se llaman Crystal evocando las facetas de una gema: cada faceta es
otra versión del proceso, y todas se sitúan en torno a un núcleo idéntico. Hay cuatro
variantes de metodologías: Crystal Clear (“Claro como el cristal”) para equipos de 8 o
menos integrantes; Amarillo, para 8 a 20; Naranja, para 20 a 50; Rojo, para 50 a 100. Se
promete seguir con Marrón, Azul y Violeta.
85
Figura 3 Familia de CrystalMethods [Crystalmethodologies.org]
La más exhaustivamente documentada es Crystal Clear (CC), puede ser usado en
proyectos pequeños de categoría D6, aunque con alguna extensión se aplica también
aniveles E8 a D10. El otro método elaborado en profundidad es el Naranja, apto para
proyectos de duración estimada en 2 años, los otros dos aún se están desarrollando. Como
casi todos los otros métodos, CC consiste en valores, técnicas y procesos.
A. Valores de cristal clear
Los siete valores o propiedades de CC [9] son:
1. Entrega frecuente. Consiste en entregar, con frecuencia, software a los clientes con
frecuencia, no solamente en compilar el código. La frecuencia dependerá del proyecto, pero
puede ser diaria, semanal, mensual o lo que fuere. La entrega puede hacerse sin despliegue,
si es que se consigue algún usuario cortés o curioso que suministre realimentación.
2. Comunicación osmótica. Todos juntos en el mismo cuarto. Una variante especial es
disponer en la sala de un diseñador senior; eso se llama Experto al Alcance de la Oreja.
Una reunión separada para que los concurrentes se concentren mejor es descrita como El
Cono del Silencio.
3. Mejora reflexiva. Tomarse un pequeño tiempo (unas pocas horas cada algunas semanas
o una vez al mes) para pensar bien qué se está haciendo, cotejar notas, reflexionar, discutir.
4. Seguridad personal. Hablar cuando algo molesta: decirle amigablemente al manager
que la agenda no es realista, o a un colega que su código necesita mejorarse, o que sería
conveniente que se bañase con mayor frecuencia. Esto es importante porque el equipo
puede descubrir y reparar sus debilidades. No es provechoso encubrir los desacuerdos con
gentileza y conciliación. Técnicamente, estas cuestiones se han caracterizado como una
importante variable de confianza y han sido estudiadas con seriedad en la literatura.
5. Foco. Saber lo que se está haciendo y tener la tranquilidad y el tiempo para hacerlo. Lo
primero debe venir de la comunicación sobre dirección y prioridades, típicamente con el
Patrocinador Ejecutivo. Lo segundo, de un ambiente en que la gente no se vea compelida a
hacer otras cosas incompatibles.
86
6. Fácil acceso a usuarios expertos. No hay un dogma de vida o muerte sobre esto, como
sí lo hay en XP. Un encuentro semanal o semi-semanal con llamadas telefónicas
adicionales parece ser una buena pauta. Otra variante es que los programadores se entrenen
para ser usuarios durante un tiempo. El equipo de desarrollo, de todas maneras, incluye un
Experto en Negocios.
7. Ambiente técnico con prueba automatizada, management de configuración e
integración frecuente. Microsoft estableció la idea de los builds(se refiere tanto al proceso de
conversión de archivos de código fuente en los artefactos de software independiente(s)que se pueden
ejecutar en una computadora, o el resultado de hacerlo)
cotidianamente, y no es una mala
práctica. Muchos equipos ágiles compilan e integran varias veces al día.
B. Técnicas
En cuanto a las técnicas, se favorecen:
1. Entrevistas de proyectos. Se suele entrevistar a más de un responsable para tener
visiones más ricas. La idea es averiguar cuáles son las prioridades, obtener una lista de
rasgos deseados, saber cuáles son los requerimientos más críticos y cuáles los más
negociables. Si se trata de una actualización o corrección, saber cuáles son las cosas que se
hicieron bien y merecen preservarse y los errores que no se quieren repetir.
2. Talleres de reflexión. El equipo debe detenerse treinta minutos o una hora para
reflexionar sobre sus convenciones de trabajo, discutir inconvenientes y mejoras y planear
para el período siguiente.
3. Planeamiento Blitz. Una técnica puede ser el Juego de Planeamiento de XP. En este
juego, se ponen tarjetas indexadas en una mesa, con una historia de usuario o función
visible en cada una. El grupo finge que no hay dependencias entre tarjetas, y las alinea en
secuencias de desarrollo preferidas. Los programadores escriben en cada tarjeta el tiempo
estimado para desarrollar cada función. El patrocinador o embajador del usuario escribe la
secuencia de prioridades, teniendo en cuenta los tiempos referidos y el valor de negocio de
cada función. Las tarjetas se agrupan en períodos de tres semanas llamados iteraciones que
se agrupan en entregas (releases), usualmente no más largas de tres meses. Pueden usarse
tarjetas CRC. Cockburn propone otras variantes del juego, las diferencias entre la versión
de Cockburn y el juego de XP son varias: en XP las tarjetas tienen historias, en CC listas de
tareas; el juego de XP asume que no hay dependencias, el de CC que sí las hay; en XP hay
iteraciones de duración fija, en CC no se presupone nada sobre la longitud de la iteración.
4. Estimación Delphi con estimaciones de pericia. La técnica se llama así por analogía
con el oráculo de Delfos. En el proceso Delphi se reúnen los expertos responsables y
proceden como en un remate para proponer el tamaño del sistema, su tiempo de ejecución,
la fecha de las entregas según dependencias técnicas y de negocios y para equilibrar las
entregas en paquetes de igual tamaño.
5. Encuentros diarios de pie. La palabra clave es “brevedad”, cinco a diez minutos como
máximo. No se trata de discutir problemas, sino de identificarlos. Los problemas sólo se
discuten en otros encuentros posteriores, con la gente que tiene que ver en ellos.
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 canónicos que pueden usarse para articular esta práctica. Una
forma de presentar Crystal Clear puede consumir entre 90 minutos y un día. La idea es que
la gente pueda “degustar” la nueva metodología.
7. Gráficos de quemado. Su nombre viene de los gráficos de quemado de calorías de los
regímenes dietéticos; se usan también en Scrum. Se trata de una técnica de graficación para
descubrir demoras y problemas tempranamente en el proceso, evitando que se descubra
demasiado tarde aún que todavía no se sabe cuánto falta. Para ello se hace una estimación
del tiempo faltante para programar lo que resta al ritmo actual, lo cual sirve para tener
dominio de proyectos en los que las prioridades cambian bruscamente y con frecuencia.
8. Programación lado a lado. Mucha gente siente que la programación en pares de XP
involucra una presión excesiva; la versión de Crystal Clear establece proximidad, pero cada
quien se aboca a su trabajo asignado, prestando un ojo a lo que hace su compañero, quien
tiene su propia máquina.
C. Procesos
El proceso de Crystal Clear se basa en una exploración refinada de los inconvenientes de
los modelos clásicos. Dice Cockburn que la mayoría de los modelos de proceso propuestos
entre 1970 y 2000 se describían como secuencias de pasos. Aún cuando se recomendaran
iteraciones e incrementos (que no hacían más que agregar confusión a la interpretación) los
modelos parecían dictar un proceso en cascada, por más que los autores aseguraran que no
era así. El problema con estos procesos es que realmente están describiendo un workflow
requerido, un grafo de dependencia: el equipo no puede entregar un sistema hasta que está
integrado y corre. No puede integrar y verificar hasta que el código no está escrito y
corriendo. Y no puede diseñar y escribir el código hasta que se le dice cuáles son los
requerimientos. Un grafo de dependencia se interpreta necesariamente en ese sentido,
aunque no haya sido la intención original. En lugar de esta interpretación lineal, Crystal
Clear enfatiza el proceso como un conjunto de ciclos anidados. En la mayoría de los
proyectos se perciben siete ciclos: (1) el proyecto, (2) el ciclo de entrega de una unidad, (3)
la iteración (nótese que CCrequiere múltiples entregas por proyecto pero no muchas
iteraciones por entrega), (4)la semana laboral, (5) el período de integración, de 30 minutos
a tres días, (6) el día de trabajo, (7) el episodio de desarrollo de una sección de código, de
pocos minutos apocas horas.
Los métodos Crystal no prescriben las prácticas de desarrollo, las herramientas o los
productos que pueden usarse, pudiendo combinarse con otros métodos como Scrum, XP y
Microsoft Solutions Framework.
88
Figura 4 Ciclos anidados de Crystal Clear
D. Roles
Hay ocho roles nominados en cristal clear:
1. Patrocinador. Produce la Declaración de Misión con Prioridades de
Compromiso(Tradeoff). Consigue los recursos y define la totalidad del proyecto.
2. Usuario Experto. Junto con el Experto en Negocios produce la Lista de ActoresObjetivos y el Archivo de Casos de Uso y Requerimientos. Debe familiarizarse con el uso
del sistema, sugerir atajos de teclado, modos de operación, información a visualizar
simultáneamente, navegación, etcétera.
3. Diseñador Principal. Produce la Descripción Arquitectónica. Se supone que debe ser al
menos un profesional de Nivel 3. (En métodos ágiles se definen tres niveles de experiencia:
Nivel 1 es capaz de “seguir los procedimientos”; Nivel 2 es capaz de “apartarse de los
procedimientos específicos” y encontrar otros distintos; Nivel 3 es capaz de manejar con
fluidez, mezclar e inventar procedimientos). El Diseñador Principal tiene roles de
coordinador, arquitecto, mentor y programador más experto.
4. Diseñador-Programador. Produce, junto con el Diseñador Principal, los Borradores de
Pantallas, el Modelo Común de Dominio, las Notas y Diagramas de Diseño, el Código
Fuente, el Código de Migración, las Pruebas y el Sistema Empaquetado. Cockburn no
distingue entre diseñadores y programadores. Un programa en CC es “diseño y programa”;
sus programadores son diseñadores-programadores. En CC un diseñador que no programe
no tiene cabida.
5. Experto en Negocios. Junto con el Usuario Experto produce la Lista de ActoresObjetivos y el Archivo de Casos de Uso y Requerimientos. Debe conocer las reglas y
políticas del negocio.
6. Coordinador. Con la ayuda del equipo, produce el Mapa de Proyecto, el Plan de
Entrega, el Estado del Proyecto, la Lista de Riesgos, el Plan y Estado de Iteración y la
Agenda de Visualización.
7. Verificador. Produce el Reporte de Bugs. Puede ser un programador en tiempo parcial, o
un equipo de varias personas.
8. Escritor. Produce el Manual de Usuario.
6.4.3 SCRUM
Scrum define un proceso empírico, iterativo e incremental de desarrollo que intenta obtener
ventajas respecto a los procesos definidos (cascada, espiral, prototipos, etc.) mediante la
aceptación de la naturaleza caótica del desarrollo de software, y la utilización de prácticas
tendientes a manejar lo impredecible y el riesgo a niveles aceptables. El mismo surge en
1986, de un artículo de la Harvard Business Review titulado “The New New Product
89
Development Game” de Hirotaka Takeuchi e Ikujiro Nonaka, que introducía las mejores
prácticas más utilizadas en 10 compañías japonesas altamente innovadoras. A partir de ahí
y tomando referencias al juego de rugby, Ken Scwaber y Jeff Sutherland formalizan el
proceso conocido como Scrum en el año 1995.
La intención de Scrum es la de maximizar la realimentación sobre el desarrollo pudiendo
corregir problemas y mitigar riesgos de forma temprana. Su uso se está extendiendo cada
vez más dentro de la comunidad de Metodologías Ágiles, siendo combinado con otras –
como XP – para completar sus carencias. Cabe mencionar que Scrum no propone el uso de
ninguna práctica de desarrollo en particular; sin embargo, es habitual emplearlo como un
framework ágil de administración de proyectos que puede ser combinado con cualquiera de
las metodologías mencionadas.
A. Roles
Scrum define seis roles:
1. El Scrum Master. Interactúa con el cliente y el equipo. Es responsable de asegurarse
que el proyecto se lleve a cabo de acuerdo con las prácticas, valores y reglas de Scrum y
que progrese según lo previsto. Coordina los encuentros diarios, formula lastres preguntas
canónicas y se encarga de eliminar eventuales obstáculos. Debe ser miembro del equipo y
trabajar a la par de sus integrantes.
2. Propietario del Proyecto. Es el responsable oficial del proyecto, gestión, control y
visibilidad de la lista de acumulación o lista de retraso del producto (productbacklog). Es
elegido por el Scrum Master, el cliente y los ejecutivos a cargo. Toma las decisiones finales
de las tareas asignadas al registro y convierte sus elementos en rasgos a desarrollar.
3. Equipo de Scrum. Tiene autoridad para reorganizarse y definir las acciones necesarias o
sugerir la remoción de impedimentos.
4. Cliente. Participa en las tareas relacionadas con los ítems del registro.
5. Management. Está a cargo de las decisiones fundamentales y participa en la definición
de los objetivos y requerimientos. Por ejemplo, selecciona al Dueño del Producto, evalúa el
progreso y reduce el registro de acumulación junto con el Scrum Master.
6. Usuario.
La dimensión del equipo total de Scrum no debería ser superior a diez ingenieros. El
número ideal es siete, más o menos dos, una cifra canónica en ciencia cognitiva. Si hay
más, lo más recomendable es formar varios equipos.
B. Ciclo de Vida
El ciclo de vida de Scrum es el siguiente:
1. Pre-Juego: Planeamiento. El propósito es establecer la visión, definir expectativas y
asegurarse el financiamiento. Las actividades son la escritura de la visión, el presupuesto, el
registro de acumulación o retraso (backlog) del producto inicial y los ítems estimados, así
como la arquitectura de alto nivel, el diseño exploratorio y los prototipos. El registro de
acumulación es de alto nivel de abstracción.
2. Pre-Juego: Montaje (Staging). El propósito es identificar más requerimientos y
priorizar las tareas para la primera iteración. Las actividades son planificación, diseño
exploratorio y prototipos.
90
3. Juego o Desarrollo. El propósito es implementar un sistema listo para entrega en una
serie de iteraciones de treinta días llamadas “corridas” (sprints). Las actividades son un
encuentro de planeamiento de corridas en cada iteración, la definición del registro de
acumulación de corridas y los estimados, y encuentros diarios de Scrum.
4. Pos-Juego: Liberación. El propósito es el despliegue operacional. Las actividades,
documentación, entrenamiento, mercadeo y venta.
Figura 5 Ciclo de Scrum, basado en [10]
Usualmente los registros de acumulación se llevan en planillas de cálculo comunes, antes
que en una herramienta sofisticada de gestión de proyectos. Los elementos del registro
pueden ser prestaciones del software, funciones, corrección de bugs, mejoras requeridas y
actualizaciones de tecnología. Hay un registro total del producto y otro específico para cada
corrida de 30 días. En la jerga de Scrum se llaman “paquetes” a los objetos o componentes
que necesitan cambiarse en la siguiente iteración.
Figura 6 Ciclo de Carrera (Sprint) de Scrum, basado en [http://www.Controlchaos.com]
91
La lista de Acumulación del Producto contiene todos los rasgos, tecnología, mejoras y lista
de bugs que, a medida que se desenvuelven, constituyen las futuras entregas del producto.
Los rasgos más urgentes merecerán mayor detalle, los que pueden esperar se tratarán de
manera más sumaria. La lista se origina a partir de una variedad de fuentes. El grupo de
mercadeo genera los rasgos y la función; la gente de ventas genera elementos que harán que
el producto sea más competitivo; los de ingeniería aportarán paquetes que lo harán más
robusto; el cliente ingresará debilidades o problemas que deberán resolverse. El propietario
de la administración y el control del backlog en productos comerciales bien puede ser el
product manager; para desarrollos in-house podría ser el project manager, o alguien
designado por él. Se recomienda que una sola persona defina la prioridad de una tarea; si
alguien tiene otra opinión, deberá convencer al responsable. Se estima que priorizar
adecuadamente una lista de producto puede resultar difícil al principio del desarrollo, pero
deviene más fácil con el correr del tiempo.
Al fin de cada iteración de treinta días hay una demostración a cargo del Scrum Master. Las
presentaciones en PowerPoint están prohibidas. Todos tienen que ser puntuales; si alguien
llega tarde, se le cobra una multa que se destinará a obras de caridad. Es permitido usar
artefactos de los métodos a los que Scrum acompañe, por ejemplo Listas de Riesgos si se
utiliza UP o los Planes de Proyecto sugeridos en la disciplina de Gestión de Proyectos de
Microsoft Solutions Framework. No es legal, en cambio, el uso de instrumentos tales como
diagramas PERT, porque éstos parten del supuesto de que las tareas de un proyecto se
pueden identificar y ordenar; en Scrum el supuesto dominante es que el desarrollo es semicaótico, cambiante y tiene demasiado ruido como para que se le aplique un proceso
definido. Algunos textos sobre Scrum establecen una arquitectura global en la fase de prejuego; otros dicen que no hay una arquitectura global en Scrum, sino que la arquitectura y
el diseño emanan de múltiples corridas [SB02]. No hay una ingeniería del software
prescrita para Scrum; cada quien puede escoger entonces las prácticas de automatización,
inspección de código, prueba unitaria, análisis o programación en pares que le resulten
adecuadas. Es habitual que Scrum se complemente con XP; en estos casos, Scrum
suministra un marco de management basado en patrones organizacionales, mientras XP
constituye la práctica de programación, usualmente orientada a objetos y con fuerte uso de
patrones de diseño. Uno de los nombres que se utiliza para esta alianza es XP@Scrum.
Actividades para el Estudio de Modelos Ágiles de Procesos.
Actividad 1
Objetivo. Que el alumno aprecie las convergencias y divergencias en la definición de
los modelos ágiles resumiendo sus características claves, los nombres de los promotores
iniciales y sus fechas de aparición.
Especificación.
-Revisar el capitulo.
92
-Hacer una tabla mencionando los acrónimos, el tipo de modelo, las características
claves, los nombres de los promotores iniciales y sus fechas de aparición de los
modelos vistos.
Ejemplo de Resultados.
Metodología
Acrónimo
Creación
Programación
extrema
XP
Beck, 1999
Crystal Methods
CM
Cockburn, 1998
Scrum
Scrum
Sutherland Schwaber, 1995
Tipo de modelo
“Disciplina en
prácticas de
ingeniería”
“Familia de
metodologías”
“Proceso”
(framework de
management)
Característica
Método ágil radical
Método ágil con
énfasis en modelo
de ciclos
Complemento de
otros métodos,
ágiles o no
Actividad 2
Objetivo. Que el alumno comprenda las cualidades y características de los modelos
ágiles.
Especificación.
-Revisar y analizar el capitulo.
-Hacer un resumen de los valores, prácticas y principios de los modelos ágiles.
Ejemplo de Resultados.
Los Valores de AM
•
•
•
•
•
Comunicación.
Valentía.
Retroalimentación.
Humildad.
Simplicidad.
Principios centrales de AM
•
•
•
•
•
•
•
•
•
•
Asumir simplicidad.
Bienvenido el cambio.
Permitir el siguiente esfuerzo es el objetivo secundario.
Cambio incremental.
Maximizar la inversión de las partes interesadas en el proyecto.
Modelar con un propósito.
Múltiples modelos.
Trabajo de calidad.
Rápida retroalimentación.
El software es el objetivo primario.
Prácticas centrales de AM
•
•
•
•
Participación activa de todos aquellos que soportan el proyecto.
Aplicar los artefactos correctos.
Propiedad colectiva.
Considerar la puesta a prueba del sistema.
93
•
•
•
•
•
•
•
•
•
Crear varios modelos en paralelo.
Crear contenidos simples.
Representar los modelos de manera simple.
Presentar los modelos públicamente.
Iterar a otros artefactos.
Modelar en pequeños incrementos.
Modelar con otros.
Demuéstrelo con código.
Use las herramientas más simples.
Referencias Bibliográficas.
[1] Sridhar Nerur, Radha Kanta Mahapatra, George Mangalaraj,
Challenges of migrating
to agile methodologies. Communications of the ACM - Adaptive complex enterprises
Volume 48 Issue 5, May 2005
[5] Kent Beck. Extreme Programming Explained: Embrace Change. Reading, Addison
Wesley, 1999.
[6] Letelier P., Penadés C., Metodologías ágiles para el desarrollo de
Software:eXtremeProgramming (XP), Universidad Politécnica de Valencia
Disponible en: http://www.willydev.net/descargas/masyxp.pdf
[8] Carlos Reynoso – Método heterodoxos en Desarrollo de Software (Survey de Métodos
Ágiles)
[9] Alistair Cockburn. “Crystal Clear. A human-powered methodology for small teams,
including The Seven Properties of Effective Software Projects”.Borrador. Humans and
Technology, versión del 27 de febrero de 2002.
[10]Pekka Abrahamsson. “Agile Software development methods: A minitutorial”. VTT
Technical
Research
Centre
of
Finland,http://www.vtt.fi/virtual/agile/seminar2002/Abrahamsson_agile_methods_minituto
rial.pdf, 2002.
6.5 Comentarios, conclusiones y actividades complementarias sobre los
antecedentes y conceptos básicos de la ingeniería de software.
Se propone realizar una actividad grupal de análisis y reflexión para cerrar el estudio de
métodos ágiles.
Debido a la novedad de las metodologías ágiles, muy pocos datos empíricos están
disponibles en relación con cada método. El desafío más grande para el líder del proyecto,
por lo tanto, es la selección de un método apropiado dentro de la cantidad de métodos
ágiles disponibles en la actualidad. Esto es muy parecido a la situación que enfrentaron los
primeros desarrolladores al adoptar la tecnología de objetos. Aunque todos los métodos
ágiles, en cierta medida, se ajustan a los principios descritos en el manifiesto ágil, no todos
se gobiernen en el mismo sentido. Existen diferencias significativas en términos de tamaño
94
del equipo, la propiedad del código, la duración de cada ciclo iterativo, el énfasis
de actividades de flujo al frente y de flujo inverso, y los mecanismos
para una rápida retroalimentación y adaptación al cambio.
Melnik [7] hace un estudio empírico para identificar el uso de métodos ágiles en la práctica.
Algunos de sus resultados son los siguientes:
1. Estado de uso en la práctica
a. Zona amplia libre de mediciones
• Pocos experimentos
• Incluso menos resultados publicados
• Foco mínimo en recolección de datos
• Datos existentes generalmente incompletos
• Consultores de muy alto nivel solo transmiten anécdotas
b. Experimentos existentes
• Muy triviales o
• Defectos experimentales
i) Gran cantidad de variables que no pueden ser controladas
ii) Pequeñas muestras
iii) Sujetos ajenos a la profesión
iv) Conducido en un lapso breve de tiempo
2. La adopción de esta metodología ha sido lenta en la industria (41%)
3. Poco conocida (54 % no sabe de ella) y de los que la conocen y aún no la adoptan
(29%) muy pocos se encuentran en la posibilidad (7%) de adoptarla.
95
4. El tamaño es importante. Cuando nos referimos al volumen de personas que
trabajan en una compañía. Mientras mayor sea el número mayor el nivel de
conocimiento de los métodos ágiles.
5. Los proyecto que usan métodos ágiles han logrado un nivel de madurez mayor que
solo proyectos piloto
96
6. Los beneficios tangibles que se reportan, 90% incremento de productividad, 85%
reducción de defectos de software, 83% aceleración de tiempo para poner en el
mercado el producto, 66% reducción de costo.
7. Un caso de estudio que muestra el éxito en el área aeroespacial con la empresa
Boeing. El
97
8. Técnicas que son más usadas, planeación iterativa (65%), pruebas de unidades de
desarrollo (60%), discusión diaria (55%), planeación de entregables (54%),
integración continua (50%).
9. Las metodologías más usadas
10. Han logrado pasar el abismo los métodos ágiles y no quedar en ser algo para
visionarios, al parecer ha pasado esa barrera.
98
11. Veamos ahora que industrias han adoptado los métodos ágiles
12. La satisfacción en el trabajo es mayor en un esquema ágil
99
Actividad 1. Reflexión sobre uso de métodos ágiles
Objetivo. El alumno reflexionará sobre la eficacia de los métodos ágiles.
Especificaciones.
Responder al cuestionario y hacer un debate en clase.
Ejemplo de Resultados.
1. ¿Los métodos ágiles son buenos por las prácticas que promueven o por qué sus
promotores simplemente son muy buenos desarrolladores?
Para lograr resultados se requiere disciplina, y mucha practica, es por eso que un
método ágil sólo será exitoso si se adopta de forma correcta.
Un proceso ágil va a funcionar con personas competentes y por encima del
promedio [1].
2. ¿Qué consecuencias negativas puede haber en la empresa respecto al nivel de
los profesionales que se requieren para el uso de métodos ágiles?
Dificultad para conseguir personal, ya que será muy complicado encontrar
equipos de desarrolladores que funcionen en el médelo ágil. Afectar autoestima
de tu personal al ser un esquema de selección de personal muy elitista lo cual
afectará la moral de los desarrolladores no-áiles.
3. ¿Cómo se va afectada la toma de decisiones?
Los desarrolladores de software y el cliente toman la mayoría de las decisiones.
Esto crea un ambiente plural de toma de decisiones con diferente historial,
actitud, metas, y disposición cognitiva. La toma de decisiones es más
100
4.
5.
6.
7.
complicada comparada con un enfoque tradicional donde el administrador del
proyecto toma la mayoría de las decisiones.
¿Cuál es el nivel de dificultad al adoptar esta cultura de toma de decisiones?
Una organización que adopta un modelo ágil debe considerar que se requiere de
un esfuerzo enorme en tiempo y paciencia para lograr instaurar la cultura de
confianza y respeto necesarios para que un esquema de toma de decisiones ágil
funcione.
¿Cómo debe ser el cliente de un desarrollo ágil?
El éxito de un desarrollo ágil depende de encontrar clientes que van a participar,
de manera activa, en el proceso de desarrollo. Más aún, los clientes deben ser:
colaboradores, representativos, poseer autoridad en la toma de decisiones,
comprometidos, y poseer conocimiento. Un perfil complicado para encontrar,
sobre todo en sistemas complejos.
¿Enumerar algunas ventajas del uso de métodos ágiles?
Algunas fortalezas de este modelo son:
• Los modelos ágiles enfatizan las comunicaciones cara a cara en vez de la
documentación.
• Los modelos ágiles son una manera efectiva de trabajar en conjunto para
alcanzarlas necesidades de las partes interesadas en el proyecto.
• Se puede decir que el modelo ágil, es una metodología muy práctica a la
hora de tener que diseñar modelados y documentación, ya que proporciona
documentación, e información sobre cómo poder realizarlos de una manera
ágil, logrando entregar modelos y documentos que realmente sean de
importancia para el usuario y eliminando los datos que sean innecesarios.
• El resultado final es un software de alta calidad en el menor tiempo posible y
un cliente satisfecho.
¿Enumerar algunas limitantes de los métodos ágiles?
Algunas debilidades de este modelo son:
• Combinado con la preferencia por las comunicaciones frente a frente,
generalmente los métodos ágiles son criticados y tratados como
"indisciplinados" por la falta de documentación técnica.
• Es un complemento a los métodos existentes, no es una metodología
completa.
• Los modelos ágiles no son un proceso de desarrollo de software completo,
donde no incluye las actividades de programación, las actividades de prueba,
no cubre la gestión de proyectos, la implementación del sistema, las
operaciones del sistema, el soporte del sistema u otros elementos
relacionados con la realización de proyectos que no sean la documentación y
el modelado.
• Hay una falta de énfasis en el diseño y en la documentación necesarios.
101
• Sólo los programadores experimentados pueden tomar las decisiones
necesarias durante el proceso de desarrollo.
• El problema con los modelos ágiles adaptables es que requieren un equipo
eficaz de desarrollo tanto a nivel individual como de equipo.
8. ¿Qué problemas se puede enfrentar una organización para adoptar un enfoque
ágil desde el punto de vista tecnológico?
Las herramientas de soporte juegan un papel crítico en el éxito de la
implementación de un software basado en la metodología ágil. Las
organizaciones que busquen adoptar metodologías ágiles deben invertir
en herramientas que apoyen y faciliten el rápido desarrollo iterativo, gestión de
versiones / configuración, refactorización, y otras técnicas ágiles. Por supuesto,
las herramientas por sí solas no pueden hacer que el desarrollo de software con
éxito. En una organización la tecnología existente puede afectar los esfuerzos
para emigrar hacia las metodologías ágiles. Para las empresas que confían
únicamente en tecnologías de mainframe puede resultar difícil la emigración
hacia los métodos ágiles en comparación con los que utilizan en el
desarrollo Orientado a Objetos.
9. ¿Cuál de las siguientes aseveraciones es verdadera?
a) equipos contentos equipos productivos –Mito
b) equipos contentos baja rotación de personal – Hecho que impacta la
economía de la empresa ya que la rotación de personal tiene un costo de
70% a200% en el salario anual de los empleados.
10. ¿Cuál de las siguientes aseveraciones es verdadera?
Es posible diagramar a priori y en detalle la totalidad del ciclo de vida y sus
artefactos- Falso
El seguimiento de un plan garantiza la excelencia de un proceso de desarrolloFalso
El diseño previo implica corrección arquitectónica y/o mejora las cualidades nofuncionales- Falso
El diseño previo incide sobre la calidad del código- Falso
La semántica de los lenguajes de diseño mapea punto a punto sobre la semántica
de los frameworks de programación- Falso
El diseño y el plan documentan el desarrollo real y/o facilitan su mantenimiento
o transferencia - Falso
Recursos.
R1) Quiz. Material descriptivo de métodos ágiles de ingeniería de software.
R2) Referencia [7]
R3) Internet
102
6.6 Referencias Capítulo 6.
Referencias Bibliográficas.
[1] SridharNerur, RadhaKantaMahapatra, George Mangalaraj
Challenges of migrating to agile methodologies
Communications of the ACM - Adaptive complex enterprises
Volume 48 Issue 5, May 2005
[2] Desarrollo de Software mediante Metodologías Ágiles.
http://www.snip.gob.ni/Xdc/Agile/Agile.htm
[3] Capitulo1
Ken Schwaber, Mike Beedle
Agile Software Development with Scrum
Prentice Hall
[4] Carlos Reynoso
Métodos Ágiles en desarrollo de software
UNIVERSIDAD DE BUENOS AIRES
http://carlosreynoso.com.ar/archivos/arquitectura/Metodos-Agiles.PDF
[5] Kent Beck.
Extreme Programming Explained: Embrace Change. Reading,
Addison Wesley, 1999.
[6] Letelier P., Penadés C.,
Metodologías ágiles para el desarrollo de Software: eXtremeProgramming (XP),
Universidad Politécnica de Valencia
Disponible en: http://www.willydev.net/descargas/masyxp.pdf
[7] GrigoriMelnik
Microsoft p&p summit, 2007
Empirical Evidence Of Agile Methods
http://www.slideshare.net/melnik/empirical-evidence-of-agile-methods-190997
[8] Carlos Reynoso
Método heterodoxos en Desarrollo de Software (Survey de Métodos Ágiles)
[9] Alistair Cockburn.
“Crystal Clear. A human-powered methodology for small teams, including The Seven
Properties of Effective Software Projects”.Borrador.
Humans and Technology, versión del 27 de febrero de 2002.
[10] PekkaAbrahamsson.
“Agile Software development methods: A minitutorial”.
VTT Technical Research Centre of Finland,
http://www.vtt.fi/virtual/agile/seminar2002/Abrahamsson_agile_methods_minitutorial.pdf
2002.
103
Autores de la presente Publicación:
M.C. Alma Delia Ambrosio Vázquez.
[email protected]
C.Dr. Mario Anzures García.
[email protected]
Dra. Etelvina Archundia Sierra.
[email protected]
M.C. María del Rocío Boone Rojas
[email protected]
Dra. Maya Carrillo Ruiz.
[email protected]
Dr. Juan Manuel González Calleros
[email protected]
Dra. Josefina Guerrero García
[email protected]
M.C. María del Consuelo Molina García.
[email protected]
Dra. María de la Concepción Pérez de Celis Herrero.
[email protected]
Dra. María Josefa Somodevilla García.
[email protected]
Con la colaboración como autor de:
M.E. María del Carmen Cerón Garnica.
[email protected]
Otoño 2011
104
Colofón
Tópicos Selectos para la Enseñanza de la Ingeniería de Software:
Introducción a la Ingeniería de Software.
Libro publicado electrónicamente, 3.03 MB, almacenado en un CD en formato PDF.
Se terminó de reproducir el 19 de Agosto de 2011,
en el laboratorio de Bases de Datos de la Facultad de Ciencias de la Computación,
ubicado en la 14 Sur y la Avenida San Claudio, Ciudad Universitaria, Puebla, Pue. Mex.
Teléfono 01-222-229 55 00 Ext. 7208.
Responsable de la publicación, M.C. María del Rocío Boone Rojas.
Tiraje 50 ejemplares.
No. De Páginas 105
105