The field of software development has changed over the last few years. The modern society has
become more and more dependent on software and on products containing software. This
means that on one hand the dependability of software has tremendously increased but on the
other hand there are still quite a number of software engineering projects which overrun the
budget, are late in delivery or are a total failure. A lot of effort is spent on improving the software
development process and this has indeed let to an increase in the overall quality of the software
and projects. However, there is still a long way to go. The next step in increasing the quality of
software and projects is to focus on the software artifacts. This means a thorough analysis of the
software products. For instance, the analysis of a user requirement document may reveal inconsistencies
or ambiguities in the formulated requirements. The mining and analysis of source code
gives insight in structure and maintainability of the code. The mining analysis of logs of a software
system may reveal inconsistencies or inefficiencies with respect to the original (workflow)
process description. Analysis of the underlying process models of a software system may reveal
unexpected deadlocks. These mining and analysis results can be used to improve the software
system and eventually to give a verdict on the quality of the software system. LaQuSo has
worked over the last few years on the development of a certification methodology. This certification
methodology uses the mining and analysis results when establishing the quality of a software
artifact. So, strong analysis techniques are a requirement to be able to certify software
products.
On the feasibility and benefits of model-based software testing
Model-based testing involves, in its most common form, testing software
systems using various models of its behavior to generate test cases and
verdicts (oracles). The fundamental ideas of model-based testing have
been floating around for at least two decades. Several successful
experiences have been reported by companies in various application
domains such as Motorola, Nokia, or BMW. However, model-based testing is
far to be a common practice. Evidence of its cost-effectiveness or even
simple practice is still scant. And far more research is needed. This
talk will introduce the basic principles of model-based testing and
develop an argument demonstrating why there is no other option for
effective test automation. It will also show why new modeling
technologies are making it it easier to develop specifically tailored
model-based testing tools within software development organizations.
Actual examples, from both research and practice, will highlight the
technologies involved, the challenges to be expected, and the potential
benefits.
Measuring Software Quality: between hope and fears
Measuring Software Quality gains more and more interest, from a lot
of different parties. However, until today little consensus seems to
exist about the answers on fundamental questions such as why measuring
quality, what to measure, how to measure, and how to present the
results. In this presentation Jacob Brunekreef will explore the field
and present some answers, focused on measuring code quality. These
answers will be illustrated with the results of ongoing measurement
activities at the Hogeschool van Amsterdam (where the quality of the
code produced by all student projects in the first two years is
measured), and some results from industrial experiences.
Analyzing Certification
Certification is used for various kinds of analysis in various parts of the software development
process. This includes certifying people, organizations and software artifacts, such as software
requirements, system designs or software source code. Staying close to its scientific research
results and scientific capabilities LaQuSo focuses on the certification of software artifacts. Several
certification projects have been performed. Certificates are handed out by independent experts.
The certification requirements and the certification report must be publicly available. Certifying
software products can be important for software risk reduction since not only in the certification
process errors are found and corrected but also results of the (formal) analysis guarantee the
absence of complete classes of flaws. Reduction of risks in software development is becoming
more and more important with increasing societal and commercial dependency of the reliability
of software components. Certification can play a central role in increasing trust in core components.
Also, an upcoming demand for software liability raises more and more interest in certification.
Finally, with the increasing use of outsourcing, certification of both the requirements specification
and of the produced code can help in guaranteeing an effective production of reliable
software upon which the society and ‘the business’ can depend.
Product Quality Analysis of OpenOffice.org with SourceInventory and Columbus
The Department of Software Engineering at the University of Szeged, MultiRacio Ltd.
and FrontEndART Ltd. recently accomplished a large project called OpenOffice++ for
analyzing, improving and monitoring the quality of OpenOffice.org source code by using
the SourceInventory tool which is based on the Columbus framework. The project was 26
months long and had a volume of 0.5 million Euros. This project is now being continued
for three years in a larger scale (2,5 million Euros) involving new partners (Sun Microsystems,
Polygon - IBM, Budapest University of Technology and Economics, and Eötvös Loránd University).
We develop technologies, tools and a methodology for assessing the quality of the source code.
The applied methods include the automatic analysis of source code and the extraction of
information from which we calculate various quality indicators with which we rank and
certify the product. Our tools continuously scan the source code of OpenOffice.org
releases (8 million lines of C++ code) and store the measured values in an SQL database.
The results can be accessed and queried through a web-based interface. Using the extracted
information our tools also audit the code to detect bugs and identify design problems.
The problematic code fragments are being refactored to obtain better quality code and
more than 180 resulting patches were already contributed back to the OpenOffice.org
community. It is also possible to apply this quality assessment and monitoring system
to software systems developed in other languages (C/C++/C#/Java/SQL).
Introducing Requirements Management for Existing Systems -
Lessons Learned
When testing existing systems, we often discover that we miss some
important input to base the test cases on: the specification of the
system. That is when we start to reverse engineer and complete the
documentation on the system. This activity yields us a big number of
requirements, that need to be managed accordingly. The introduction of
requirements management in a later system release has a number of
specificities compared to requirements management started from the very
first release of a system. This presentation highlights some of these
differences and describes the difficulties encountered in a recent
project that aimed to introduce requirements management for an existing
system.
Evolving Critical Systems: A Research Agenda for Software
Engineering
Increasingly software can be considered to be critical, due to the
business or other functionality which it supports. Upgrades or changes
to such software are expensive and risky, primarily because the software
has not been designed and built for ease of change. Expertise, tools and
methodologies which support the design and implementation of software
systems that evolve without risk (of failure or loss of quality) are
essential. We address a research agenda for building software that (a)
is highly reliable and (b) retains this reliability as it evolves,
either over time or at run-time.
Realities of API asbestos
There are different incarnations of software asbestos: spaghetti code,
code cloning, code tangling, code with hidden assumptions, code with
vendor-specific language extensions, code that is locked into
proprietary and outdated component/SOA technology, and so on. This
presentation is concerned with API asbestos: software that is locked
into specific APIs up to a point that it is difficult or infeasible to
replace one (say aged) API by another (say modern) API, or to replace
API-based, low-level code by modules that are based on generative or
model-driven techniques instead. Hence, API asbestos hampers software
evolution and modernization in particular. There is no best practice yet
for removal of software asbestos but the presentation discusses some
first ideas and open research questions towards such a best practice.
The presentation is based on research on API-usage analysis and
automated API migration specifically in the context of the Java
platform.
RFID protocols and privacy
Radio Frequency Identification (RFID) is a technology based on
short-range wireless communication between a transponder and a reader
to remotely identify an object to which the transponder is attached.
This technology is replacing not only the widespread bar code, which
is currently used to identify objects, but also smart cards for
payment and ticketing applications such as mass transit.
It is well known that the deployment of RFID tags leads to security
risks such as loss of privacy (through object tracking), insecure
authentication (with biometric passports), and theft of service (in
public transportation). The protocols proposed for applications
employing RFID technology must therefore be carefully verified to
prevent such vulnerabilities.
Because RFID chips have limited resources, it is in general not
possible to use the standard "off-the-shelve" cryptographic protocols.
New protocols are being designed every day and many of them are shown
to contain weaknesses after a careful scrutiny.
The lecture starts by giving an overview of the privacy issues related
to RFID systems. After discussing attacks on the privacy of some
existing RFID protocols, I will discuss a formal definition of privacy
(or untraceability) and show its implications.
Minimum effort, Maximum results
A part the development process, from analysis to certification, is the testing process. Test-M is the answer to the ever growing costs of this expensive process. Testing has become a goal on his own, rather than being just one of the quality measures to be taken. Testing could become more efficient and cheaper without losing quality by making testing specific, taking quality measures were needed without the unnecessary generic waste: “Minimum effort, Maximum results”.
In many organizations structured testing seems to be the approach to determine the quality of IT-solutions. However many of the defects found by testers are introduced earlier in the development process and you would like to prevent these defects or at least discover them earlier. With just testing,
focusing on the quality of the end products, you don't get a grip on your project. To control your projects you also need to pay attention to the quality of the intermediate deliverables and the development process itself. A result-driven approach, based upon experiences in the areas of structured testing and quality assurance, will support all stakeholders of a project to control both product quality and process quality. Getting grip on these quality aspects will assure project success: on time, within budget and the expected product quality.
Testing is necessary and will also be necessary in the future. Testing or Product quality will however focus more and more on preventing errors rather than only recording these errors.
Dn-based Architecture Assessment of Java Open Source Software Systems
Since their introduction in 1994 the Martin’s metrics became popular
in assessing object-oriented software architectures. While one of the Martin
metrics, normalized distance from the main sequence Dn, has been originally
designed with assessing individual packages, it has also been applied to
assess quality of entire software architectures. The approach itself, however,
has never been studied. In this paper we take the first step to formalizing
the Dn-based architecture assessment of Java Open Source software.
We present two aggregate measures: average normalized distance from the
main sequence Dąn, and parameter of the fitted statistical model lambda.
Applying these measures to a carefully selected collection of benchmarks
we obtain a set of reference values that can be used to assess quality of
a system architecture. Furthermore, we show that applying the same
measures to different versions of the same system provides valuable insights
in system architecture evolution.
A Common Language: Creating Requirement Statement Templates
The formal documentation of natural language requirements in a requirements specification
is an important piece of a software engineering project. This document lays the groundwork
for the development of a software system. It represents an agreement between the customer
and the development team as to what is going to be built.
The requirements written in this document become the common language between all stakeholders.
By creating requirement statement templates projects and companies can gain:
a decrease in amount of time required to reach shared understanding with stakeholders;
the ability to identify comprehension risks in requirements statements;
a decrease in amount of rework needed to initial draft of requirements;
an ability to add additional sentence formatting to help engineers identify high risk terms;
cnsistent use of terminology throughout all requirement documents; and
test cases can be systematically created based on templates
The process discussed in this presentation can be used to develop natural language
requirement templates so that key stakeholders understand the basic intent of each
statement, regardless of the domain information contained within that statement.
Requirements Engineering and Certification
Quality makes products which do not return and customers who do. Requirements are essential for making quality. From the testing community (among others) we hear more and more complaints about the quality (and availability…) of the requirements. But what makes requirements ‘good’ requirements? The answer from the test community is often that ‘good’ requirements need to be SMART. But is this sufficient? In this presentation ‘golden’ rules for gathering and specifying ‘good’ requirements will be presented.
Do we answer the question “do we know enough to start gathering requirements”? We need to have a clear picture about scope, context and all the stakeholders. How do we deal with changing scope and context, and how to deal with changing requirements? A well defined process for both requirements engineering and requirements management is essential for project success.
By thoroughly defining requirements in an early stage, functional as well as non-functional requirements, a clear and distinct frame of reference will be originated. By verifying and validating the product in a later stage, we can determine whether the product will meet the requirements which can be a fundament for further product certification. Not only checking whether the product will meet the requirements can contribute to product certification but also meeting the requirements for the process and the requirements for the people involved.
In the testing community this is already common practice by having recognized certification for the testers according to ISTQB or TMap. In this presentation certification for the requirement engineer will be introduced according to the Certified Professional for Requirements Engineering (CPRE) certification model originated by the International Requirements Engineering Board IREB.
Learn more about requirement engineering and certification!
Measuring and Rating Technical Quality of Software: An instrument for software cost reduction
The success of many organizations depends on the ability of their
software systems to evolve as fast as their business processes. A system
that meets its functional requirements today may not do so tomorrow if,
due to low technical quality, it can only be changed with high cost and
risk. The Software Improvement Group has developed a practical model for
measuring technical quality of software products. In this presentation,
Joost Visser will explain how this quality model can be employed to find
opportunities for cost reduction in software portfolios.
