|
Keynotes |
||
|
Antonia Bertolino |
||
|
Software Testing Forever: Old and New Processes and Techniques for Validating Today's Applications |
 |
|
|
Short bio.
Antonia Bertolino is a Research Director of the Italian National Research Council (CNR),
in Pisa, where she leads the Software Engineering Research Laboratory. Within European
and national projects, she investigates approaches for rigorous and automated model-based
integration and system testing, for architecture-based and component-based test methodologies,
as well as methods for evaluation of extra-functional properties of compound systems.
She is the Area Editor for Software Testing for the Elsevier Journal of Systems and Software;
she is also an Associate Editor of Springer Empirical Software Engineering Journal, and of the
IEEE Transactions on Software Engineering.
She has been the Program Chair for the joint European Software Engineering Conference and
the ACM SIGSOFT Symposium on the Foundations of Software Engineering Conference ESEC/FSE 2007.
She serves regularly in the Program Committees of the main events in software engineering and testing,
including ISSTA, ESEC/FSE, ICSE, TESTCOM/FATES, CBSE.
She has (co)authored over 90 papers in international journals and conferences. ABSTRACT. Software testing is a very complex activity deserving a first-class role in software development. Testing related activities encompass the entire development process and may consume a large part of the effort required for producing software. In this talk, I will first organize into a coherent framework the many topics and tasks forming the software testing discipline, pointing at relevant open issues. Then, among the outlined challenges, I will focus on some hottest ones posed by the testing of modern complex and highly dynamic systems. What is assured is that software testers do not risk to remain without their job, and testing researchers are not at short of puzzles. Software testing is and will *forever* be a fundamental activity of software engineering: notwithstanding the revolutionary advances in the way it is built and employed (or perhaps exactly because of), the software will always need to be eventually tried and monitored. In the years, software testing has evolved from an 'art' to a discipline, but test practice largely remains a trial-and-error methodology. We will never find a test approach that is guaranteed to deliver a 'perfect' product, whichever is the effort we employ. However, what we can and must pursue is to transform testing from 'trial-and-error' to a systematic, cost-effective and predictable engineering practice. |
||
|
Kurt Schneider |
||
|
Supporting Experience and Information Flow in Software Projects |
 |
|
|
Short bio.
Kurt Schneider studied Computer Science in Erlangen, Germany. He received a doctoral degree in
Software Engineering from the University of Stuttgart in 1994. He had a grant from the
NATO Science Committee for a Postdoctoral position at the University of Colorado at Boulder
from 1994-1996. Kurt Schneider was a visiting member of the interdisciplinary Center for
LifeLong Learning and Design in Boulder. From 1996-2003, he was a researcher and a project leader
at the DaimlerChrysler Research Centre in Ulm, Germany. In particular, Kurt Schneider was
leader of the Software Experience Centre (SEC) project for DaimlerChrysler. Since 2003, he is
a full professor of Software Engineering at Leibniz Universität Hannover. His main research
interests are requirements engineering, software quality, and service-oriented architectures.
Life-long learning and cognitive optimization of techniques and tools are investigated in all
those areas. ABSTRACT. Several large companies have conducted initiatives for systematic learning from experience in software engineering. In the international Software Experience Center (SEC), for example, five companies exchanged experiences and collaborated in building experience exchange mechanisms to be used within each company. Many insights were gained and lessons were learned over the years, among them: (1) Written and documented experiences are the exception rather than the rule. (2) Although not documented in detail or controlled by a process, experience needs guidance and support in order to reach the designated person or group. The “flow” of experience must be kept in mind. (3) Experience is a delicate material, and any avoidable effort or threshold to participate in systematic experience exploitation may endanger stakeholder participation and success. (4) Tools can effectively be built to support orderly flow of experience, but they must be optimized for cognitive support of their users. These lessons learned from supporting experience exploitation can be applied to software projects more generally: Requirements, rationale, and other information flowing through a software project resemble experience with respect to the above-mentioned characteristics: They are often communicated orally rather than in a document. There are diverse processes and practices designed to channel information flow. Early and vague requirements must be handled with care, and tools need to be optimized to reduce cognitive barriers and thresholds, or they will not be accepted. A focus on information and experience flow takes the above-mentioned lessons into account. Information flows within one project, while experience often cuts across several projects. Requirements of one project are useful only in that same project. Experience in designing a product, however, may be reused in subsequent projects. Information and experience flows need to be modelled explicitly. A simple notation is proposed to capture just the essence of flowing information. What may seem like a subtle shift from processes to flows offers a new perspective: Based on those models, dedicated techniques and tools can be developed for analysing and for improving the flows. A wide range of current trends in software engineering can benefit from a better understanding of – and support for – appropriate information flow: Interfaces to the subcontractors, distributed and collaborative teams, Wiki webs, and a variety of new communication channels in global software engineering call for a focus on information flow. |
||
|
|
||
|
Culture of Error Management |
 |
|
|
Short bio of
Horst Degen-Hientz. "In my roles as consultant and business development manager
I have today the responsibility to support our customers’ process performance
improvement and change programs towards targeted business success.
In my various roles as programmer, consultant, and CEO I have gathered since 1986
in-depth insight in companies and practices in this field. My experiences are
based on intensive work with culturally diverse small, medium, and large
embedded systems software development organizations within the value creation
network especially in Automotive and Telecom industries. Selected experiences
were packaged as tutorials and papers and published at various conferences,
e.g. NASA/SEL96 - USA, ESCOM97 - Germany, ACOSM97 - Australia,
DASIA97 - Spain, SPI98 - Monte-Carlo, E-SEPG98 – UK, SEPG08 - USA."
KUGLER MAAG CIE is a professional consulting services company, member of Lero, the
Irish Software Engineering Research Institute, co-founder of iNTACS (TM),
partner of the SEI-USA, and sponsor of the SEI-Europe. www.kuglermaag.com. ABSTRACT. What has a Stradivari and Linux in common? It is the error culture-driven process that created it. A culture of restless strives for innovation and quality enabling continuous learning. We systematically get trained by being punished as child when doing mistakes and often need a life long cumbersome process to undo this conditioning. In western world many organization behave just like as that: errors are socially not acceptable. This seems to be universal applicable as Kaizen and the “zero-defect-culture” can teach us. It is not a society intrinsic attitude - as one can observe from the Toyota way - which took years to establish an organizational error management culture. Studies in Europe show too that organizational error management are a means to boost companies’ performance and goals achievement. Hence, what can we learn from Stradivari and Linux? It is the way to organize error management and innovation. This is key to open source projects and the raising inner source projects as observable in companies like Google. |
||