VVSS Symposium : Verification and Validation of Software Systems

March 23 I went to the VVSS symposium. VVSS stands for Verification and Validation of Software Systems.

The symposium was held for the third time at the Technical University of Eindhoven (the Netherlands) and was organised by LaQuSo, the Laboratory for Quality Software, which is a cooperation between the universities of Eindhoven and Twente.

The symposium had 2 keynotes and 30 presentations in 5 parallel tracks during one day. I was present at 8 presentations in total. There were about 300 people present.

Before I go into the details, I would like to say that I was surprised by the different quality of the presentations. In my article about presentation techniques, I introduced some tips on presentations, and the most common pitfalls. Most presenters could learn from it.

Professor Dr. Wil van der Aalst presented an very interesting keynote about the use of logfiles for automatically creating process diagrams.

When systems are designed, usually process diagrams are produced. Several notations are common, like Petrinets or BPEL. After the system is designed, it can be useful to check if the process is built as designed.

Almost all modern systems produce large amounts of logging data. Not only IT systems, but also for instance medical systems like X-ray machines.

The TU/e developed software to automatically create process diagrams based on these logs. The software has no prior knowledge about the process. After the diagrams are created, the software can pinpoint where in the process most delays are experienced. this technique is called Process-mining.

Compuware presented a product (Vantage) that produces performance information about .Net or Java based systems during the development phase.

Another tool, called Dev Partner can be used to find performance problems before a system is put in production.

Hans Baaten of Atos Origin presented the ATOS method Requirements Definitions Center. This method is based on the Rational Unified Process (RUP) and is therefore iterative by nature. An important property of the method is to have a software-architect, a system analyst and a requirements engineer working together during the requirements gathering.

An example of a very good presenter was  Erik Poll of the Radboud University Nijmegen.  His presentation was about the formal verification of SSH implementations on mobile phones (sounds boring, but it wasn't). The study showed that although the SSH protocol is very strong on itself, the implementations of the protocol in software is very hard. Several security vulnerabilities were found in existing (Java) software implementations.

The last keynote speaker was Professor Dr. David Parnas from the University of Limerick in Ireland. He has spent 40 years of his life improving software documentation.

His most important message was that software should be described the same way as technical diagrams in Engineering (construction and electronics). Those diagrams are all based on mathematical models.

In the last decades, professor Parnas created a method for describing software using (complicated) mathematical terms. The terms are then converted to easily readable matrices, that are scientifically correct. His method is used in the construction of software for nuclear plants and in aerospace.

Architects and Engineers

Yesterday, I had a discussion with a few colleagues about the difference between engineers (or developers) and architects.

There seems to be a thin line between these disciplines. My opinion about this subject is as follows:

Engineers and architects both have different roles and skills. Engineers can create designs and can oversee much of the details that go with it. They are the specialists on a field that can make designs that can be built easily.

Architects are in a different playingfield than engineers. Usually architects are positioned at the beginning of projects, where engineers usually do their job when the project is running for a while. Furthermore, architects should have the following skills, that are not necessarily needed for engineers:

• Good architects have much (at least 10 years) experience in many companies, and in different roles. This way they have a good understanding of different business- and technical issues.
• Architects have a wide technical knowledge, across many different areas. They should not be specialists, but generalists.
• Architects need good communication- and social skills. It's the architects who are supposed to convince the managers and project leaders of their architectures. Furthermore, they need leadership skills to have projects follow the architecture.
• Architects need a helicopter view. They are the ones that need to oversee the consequences of architectures and the changes to it, including the business effects.

This means that there is no such thing as a Java Architect or a Network Architect. These people are engineers. They excel in their specific knowledge area and they use the more general guidelines from the architects.