Assessment is an inherently human activity. When assessing large data sets or complex software systems, tools are indeed a prerequisite because we need to deal with the sheer size of details, but eventually it is the human that has to understand and make decisions.
Traditionally, the process of assessment is dominated by the use of standard reporting tools. However, these tools are often not useful out-of-the-box, because problems tend to not be standard. I argue for an assessment process that is centered on humans rather than on tools, and I propose a new, humane, approach trough which custom tools are crafted to meet custom needs.
As part of the humane assessment (http://humane-assessment.com) philosophy, I introduce the daily assessment, a simple technique based on the following daily routine:
Moose is an extensive platform that was conceived exactly to ease the building of customized analysis tools.
An agile process replaces upfront design with the focus on the ability to react and to adapt to the current situation. To take the right decision, we need to be able to assess the situation accurately, and given the short iteration cycle, we need to do it in a timely fashion, too.
This talk proposes a fresh perspective on software assessment. First, we assert that software assessment is critical for taking accurate decisions that involve technical aspects. Second, we provide an overview of some software assessment tools and techniques that can scale to large amounts of information. And third, we discuss the implications of integrating these tools and techniques in an agile development process.
We need a radical change in the way we approach software assessment both in practice and in research. Assessment is a critical software engineering activity, often accounting to as much as 50% of the overall development effort. However, in practice this activity is regarded as secondary and it is dealt with in an ad-hoc way. This does not service. We should recognize it explicitly and approach it holistically as a discipline.
Assessing large software systems is traditionally tackled using off-the-shelf tools that offer static reports. However, complex software systems exhibit specific problems that require specific strategies to understand and solve. This talk argues that software assessment should embrace these peculiarities and instead of generic hardcoded tools, it should rely on dedicated exploratory tools to answer specific problems. The message is exemplified through demos of the Glamour and Mondrian scripting engines contained in the Moose analysis platform.
To control the development of software systems effectively, we need to be able to assess their status. As modern systems are large and complex, we must go beyond reading raw data and rely on a combination of tools and techniques. Furthermore, as systems have particularities we need to customize the analysis to match the situation.
Browsers are crucial to make software models accessible. Problem domains often require multiple views to access, interpret and edit the underlying elements. However, browsers are expensive to create and burdensome to maintain.
Glamour is a platform dedicated to building such browsers. Glamour is built in Smalltalk (both in VW and in Pharo), and comes with actual renderers for Widgetry, Morphic and Seaside. It uses a components and connectors architecture, and it comes with an embedded domain specific language that allows the user to build dedicated browsers quickly. It accommodates any kind of domain models via on-the-fly transformations and it enforces a strict and explicit separation between the presentation of the data and the navigation flow between different entities.
To manage software systems, we need to be able to assess their quality. However, software systems are large and complex, and documentation is often not reliable. To handle this situation we need assessment techniques and tools that provide an accurate overview.
Metrics are such tools, and in this talk we provide an overview of their role in the assessment process: we talk about the goal-question-metrics paradigm, we list examples of various ways in which we can measure external and internal quality aspects, and we describe the use of metrics in quality models.
At the end, we step back, we talk about the pitfalls that accompany metrics and argue about how the process of assessment can and must go beyond metrics.
Research is less about discovering the fantastic, as it is about revealing the obvious. The obvious is always there. It needs no discovery. It only needs us to take a look from a different perspective to see it. Thus, the most important challenge is not the fight against nature, but against our own assumptions. One way of fighting against our own assumptions is to expose them to other people. That is why, I advocate and practice what I call demo-driven research, a way of doing research that puts emphasis on presenting the state of research with any given chance and to any audience willing to listen.
To analyze complex data we need to visualize it and to interact with it. Mondrian is a novel information visualization engine that lets the visualization and the interaction be specified via a script. Rather than featuring a dedicated scripting language, we designed Mondrian to use the hosting language for scripting. Our original implementation is in Smalltalk, and makes use of the dynamic nature of the language to provide an expressive scripting language. Several other implementations of the concept have been built in other languages as well. Mondrian is based on a graph model and works directly with the objects to be represented.
Modern software systems are large and complex, and to effectively understand them we need to employ a combination of analysis techniques. Moose is a reengineering environment that allows for tools integration by making a clear distinction between the meta-model and the analysis techniques. In this presentation we describe the philosophy of Moose and demonstrate how it enables an integrated, yet agile approach to reverse engineering. Furthermore, as Moose is the result of 10 years of research we also encompass the symbiotic relationship between the implementation effort and the basic research.
Over the past three decades, more and more research has been spent on understanding software evolution. However, the approaches developed so far rely on ad-hoc models, or on too specific meta-models, and thus, it is difficult to reuse or compare their results. We argue for the need of an explicit and generic meta-model that recognizes evolution as an explicit phenomenon and models it as a first class entity. Our solution is to encapsulate the evolution in the explicit notion of history as a sequence of versions, and to build a meta-model around these notions called Hismo. To show the usefulness of our meta-model we exercise its different characteristics by building several reverse engineering applications.
Understanding software systems is hampered by their sheer size and complexity. Software visualization encodes the data found in these systems into pictures and enables the human eye to interpret it. In this presentation we place software visualization in the context of reverse engineering and we present several examples of how it can help in understanding software systems. We also go behind the scene and discuss the principles that make for a good visualization.
These days preparing a presentation is synonym with writing bullets on slides, presenting is synonym with delivering the pack of slides. While this approach might seem straightforward, it is ineffective as it fails to animate and transmit the message. In this presentation we strive to give another perspective on how presenting can be.
The last snapshot from the versioning system can tell us how the software system looks like, but it does not tell us how and why it got in this state. This talk argues that software history needs to be taken into account during the software assessment process, and it provides several examples of how history can be measured, predicted, visualized or how it can reveal behavior patterns of developers.
Research is the game of finding new points of view. Only through play do we relax enough for finding new points of view. But how should this game look like? What are the rules? What are the good practices? In this talk I present the game I play.
This lecture introduces the problem of maintaining and evolving software systems, presents various approaches to understand them and offers an outlook of possible reengineering techniques.
While the status quo can be comfortable, it is certainly not perfect. There always is something to improve. However, when entrenched in a routine we typically have no clue of what that something is and how to improve it. How can we find that something and how can we improve it?