I.C.S.E.

International Conferences on Software Engineering

Portland, OR, EEUU - 3-10 Mayo 200325 Aniversario

ACM IEEE

ICSE 2003

• Qué significa ICSE?• Historia de ICSE. 25 años• Qué representa ICSE 2003?• Stakeholders de ICSE

• Industria (NASA, L.M.S.) Investigadores, Estudiantes

• Nuestra participación

ICSE 2003

• ICSE 2003• Tutorials• Workshops• Presentations• Demos and Posters• Industrial presentations• Co-located

ASISTENTES

• Argentina 4• Brasil 19

• Canadá 78• EEUU 486• Australia 13• India 1• Israel 2• Japon 18• S. Korea 13• New Zealand 2

• Singapore 3• Thailand 2

• Austria 10• Belgica 3• Finland 20• Francia 11• Alemania 50• España 5• UK 42• Otros…

Total: 794

TRACKS

• Technical Tracks 42/324• Experience Tracks 16/61• Education Tracks 11/52• Awards• Panels and MiniTutorials• Demostrations and Posters• Co-located

WORKSHOPS 14/32

• W1: SELMAS’03 - 2nd International Workshop on Software Engineering for Large-Scale Multi-Agent Systems

• W2: EDSER-5 - 5th International Workshop on Economics-Driven Software Engineering Research: The Search for Value in Engineering Decisions

• W4: Bridging the Gaps Between Software Engineering and Human-Computer Interaction

• W7: WADS - Workshop on Software Architectures for Dependable Systems

• W8: SCESM - 2nd International Workshop on Scenarios and State Machines: Models, Algorithms, and Tools

• W9: 3rd Workshop on Open Source Software Engineering• W10: SEHAS’03 - Software Engineering for High

Assurance Systems: Synergies between Process, Product, and Profiling

• W15: STRAW ‘03 - 2nd International Workshop on SofTware Requirements to Architectures

WORKSHOP

• Workshop STRAW 03• 2nd International Workshop on Software

Requeriments to Architectures and Architectures to Requeriments.

• STRAW 03 Chairs:• Daniel M. Berry (Univ. Waterloo, CA)• Rick Kazman (CMU, SEI, US)

• Quien lo conduce?• Como se lleva a cabo un Workshop?• De la Arquitectura a los

Requerimientos?

TUTORIALS 17/80

• Tutorials (Full Day)• F3: Documenting Software

Architectures: Views and Beyond• F6: Mastering Design Patterns• F8: Usage-Centered Software

Engineering• F11: Industrial-Strength Software

Product-Line Engineering• F10: Pattern-Oriented Distributed

System Architectures

TUTORIALS

• Tutorials (Half day)• H1: Feature-Oriented Programming for

Product Lines• H2: An Overview of UML 2.0

• H3: Best Practices for Implementing CMM-Based Software Process Improvement

• H4: Designing Software Architectures for Usability

• H6: Agile Unified Process

DEMOSTRATION AND POSTERS

• Embedded Architect: A Tool for Early Performance Evaluation of Embedded Software

• JIVE: Visualizing Java in Action• FEAT: A Tool for Locating, Describing, and

Analyzing Concerns in Source Code• A Software Process Scheduling Simulator• Source Viewer 3D (sv3D) - A Framework for

Software Visualization• xChek: A Model Checker for Multi-Valued

Reasoning• The Role of Trust in Software Outsourcing

ICSE 2003

Otros:• Premio 10 años después. Paper de mayor

influencia en esta década.• Pioners Symposium

• Guía de lideres a graduados.David Parnas:

“Research that will still be relevant 25 years from now". E.g., What distinguishes such work? What does a researcher need to know and do to produce such work?”

FULL DAY TUTORIAL

Documenting Software Architecture: Views And Beyond

• Paul Clements, CMU Software Engineering Institute, USA

• David Garlan, Carnegie Mellon University, USA• Reed Little, CMU Software Engineering Institute, USA• Robert Nord, Siemens Corporate Research, USA• Judith Stafford, Tufts University, USA

FULL DAY TUTORIAL

• Como documentar una arquitectura? • Respuesta: No de esa manera. (Pobre)

• Que significan las líneas y los rectángulos?• Porque es tan importante documentar?

La documentación muestra la arquitectura hoy y en 20 años (Que sabemos de los sistemas hechos en 1980, 1990 hoy día? Quien los mantiene?)

FULL DAY TUTORIAL

• Que documentos han leído que se destaquen?• MAN, sus tp’s Ing. Soft I, API, …

• Que los hace tan buenos?• Cuales han leído que no han

servido?• Que los hace tan malos?

FULL DAY TUTORIAL

LOS SAGRADOS SIETE PRINCIPIOS:1. Escribir desde el punto de vista del lector

Secuencia lógica, secuencia de ejecución.2. Evitar las repeticiones

Fácil de modificar, fácil de usar.3. Evitar ambigüedades

Si el documento usa un lenguaje gráfico, explicarlo.4. Utilizar estándares

Un documento se lee una sola vez…con suerte…5. Plasmar el razonamiento

Evita perder el tiempo…6. Mantener la documentación al día, pero no

tanto…7. Ver la documentación con los stakeholders…

es lo que quieren? Se presenta en forma practica?

PRESENTACIONES

• Mujeres en C.S.? Porque tan pocas? Que nos perdemos?

• Componentes confiables.• Seguridad hoy en día!. Caos.• Predecir… confiar en un software…

PRESENTACIONES

• Mujeres en CS? Porque tan pocas? Que nos perdemos?

• Meyer: Componentes.

• Seguridad hoy en día!. Caos.

• Predecir… confiar en un software…

OBJETIVO

• Lograr seguridad, poder predecir.• Aplicaciones embebidas, tiempo real.• Métodos formales? Cuando?• Mejorar lo existente.• Muchas áreas…

Opening Keynote: B. MEYER

• Industria del Software vs. Componentes Electrónicos• Estándares y verificación. (No es el caso de I.S.)

• No hay tiempo!!• “Good Enought” vs. “Good Software” (Muy caro!)• CMM, ISO. pero se concentran solo en el proceso!.

• 6 Millones de desarrolladores VB.• Componentes en los que uno puede

confiar…

WOW

Window on the World

• Qué es WOW?• Noticias• Tips• Destacados• Criticas• Humor• Fotos

MATERIAL

• Entonces… donde obtengo este conocimiento?• Material:

• Ing. Soft I :)• Apuntes• Proceedings• S.E.I. (web)• Writing good Software Engineering Papers

(Tutorial)• Mary Shaw http://spoke.compose.cs.cmu.edu/write/

EL FUTURO…

ICSE 2004: Edimburgo, Escocia.

¿ICSE 200X: Buenos Aires, Argentina.?

MUCHAS GRACIAS

MUCHAS GRACIAS…

ESTUDIANTES VOLUNTARIOS