Agenda Day 2

9.30 Strengthening CMMI Maturity Levels with a Quantitative Approach to Root-Cause Analysis
Luigi Buglione (Engineering.it, Italia)

• To profitably use 'old' but common-sense TQM techniques with a new flavour, for its quantitative usage in projects, as done yet in Defect Management with ODC (Orthogonal Defect Classification), but enlarged
• To stress the relevance and value of gathering data from multiple sources, using RCA as a further opportunity to take more precise corrective/improvement actions based on your own historical data
• To introduce a different manner to express Ishikawa diagrams with Mind Maps, increasing the communication value to more stakeholders as possibile

This paper discusses and analyzes the opportunity to approach to typical TQM qualitative tools such as Root-Cause Analysis (RCA), expressed with the well-known Ishikawa (or Fishbone) diagrams, in a quantitative manner. The addition of a control measure at the end of each 'cause' leaf can help decision-makers in a better determination of corrective actions in terms of 'how much' resources to introduce into the related action plan. ISO 15939 Measurement Information Model can be the proper tool helping in deriving such measures, overcoming the inner limitations of Orthogonal Defect Classification (ODC), providing a direct process improvement at ML2 on Measurement & Analysis (ME) and at ML3 on Organizational Process Focus (OPF, SP1.4) as well as on the General Practice GP2.8 (Monitor & Control the Process) across all the process areas involved in each single cause-effect analysis.
Furthermore, the communication issue is discussed, proposing an alternative way to express Ishikawa diagrams, through Mind Maps and how they can facilitate the diffusion and usage of RCA into organizations

10.00 Presentation to be defined

10.30 Context-adapted quality analysis 
Jonathan Streit (Itestra GmbH, Germania), Elmar Jürgens(Technische Universität München, Institut für Informatik, Germania)

The authors analyse a problem that is relevant in software engineering practice and present their experiences from industrial software projects. Delegates will learn a method to significantly improve the precision of automated analyses for quality defect location and efficiency of their use. The authors give an overview of existing tools for quality defect analysis, concentrating on the insights they can realistically provide in a software project.
 
Code quality significantly influences software maintenance costs. Since manual inspections are time consuming and thus expensive, numerous automated analyses have been proposed to locate different types of quality defects in source code. Examples are bug pattern finder, guideline checker, metrics or clone detection tools. However, most of these automated methods suffer from a high number of false positives in practice, burying important problems among large amounts of spurious warnings. In practice, this is usually dealt with by either weakening thresholds and rules (thereby reducing the value of the analysis) or by checking violations manually (costly and time-consuming) or worse, by ignorance towards the entire result set.
In this paper, we argue that one reason for the insufficient precision of current methods is the attempt to judge a whole software system with the same set of rules and thresholds. Different parts of a software system are subject to different activities, at different frequency, by different people and have different origin, criticality and usage characteristics. This information is often crucial for making informed quality assessments. Thus, different criteria should be applied for judging their quality.
We therefore propose to categorize code, e.g., according to its origin, role, lifetime and criticality. Different sets of rules and thresholds can be defined for different categories, enriching the quality analysis of a piece of code with context related information. This additional information allows to both increase precision and to use sharper criteria on critical sections. We outline support for context-adapted tailoring of diverse quality analyses implemented in the open source quality assessment toolkit ConQAT and present a case study in validation of our method on industrial software systems.

11.00 Coffee break

11.30 Software Acquisition in Automotive: Is Supplier's Software Process Capability Determination Enough?
Giuseppe Lami

the paper describes today's common approaches for managing software acquisition in the automotive domain, discusses current problems, and presents a novel approach to improve the monitoring and control of software acquisition. The approach presented is practice-oriented and can be of interest for IT professionals.

The success of the acquisition process depends on the capability of effectively managing the relationship between customer and suppliers. The agreement on single requirement baselines can be insufficient if not accompanied by a continuous communication all over the development of the supply.
It is a common practice (principally in the European automotive industry) to ask potential software suppliers a specific capability profile according to the Automotive SPICE model. It is even common that car manufacturers sponsor the initial assessment for determining such a capability profile. The return of such an investment is, for the car manufacturer, the possibility to know the capability of the supplier' software process; such knowledge becomes one of the main criteria for the supplier selection process.
To assess the capability of the software process, assessors use process instances (i.e. projects being representative of the organization's business goals) to collect evidences and consequently rate the Automotive SPICE process attributes.
Nevertheless, car manufacturers do not have the guarantee that the project the supplier undertakes for a specific supply has the same characteristics of the projects used as process instances by the assessors at assessment time.
In other words, a new project might be designed, planned, managed and conducted with a different level of care, effort and resources without following the same good practices as respect the project used as process instances for Automotive SPICE assessments.
That should not be surprising. Performing an assessment means to determine, in a disciplined manner, the capability of a set of selected processes.
Process capability is a characterization of the ability of an organization's process to meet current and predicted business goals, it is not involved with the evaluation of the specific techniques and management choices of a single project.
In other words, determining the capability of a process means rating the ability of an organization of achieving the outcomes associated with a particular process, no matter how and no matter according what technical or managerial solutions.
So, there is no contradiction if an organization, having a process with high capability level, implements that process in a different (and possibly worse)  way as respect as the standard way it performs. Such a situation doesn't depend neither on a defect in the SPICE assessment model, on a bad assessment made by the assessors, nor on the fact that the organization undertaking the assessment (the software supplier, in our case) was cheating during the assessment. It is simple due to management choices of the supplier. It can decide to devote different care in project without make invalid the results of the assessments already performed.
Such a situation requires that customers integrate the software capability determination with other techniques aimed at verifying the correspondence between the evidences collected at assessment time and the characteristics of the specific project the supplier is undertaking.
A way to cope with this demand is to integrate the assessment results and evidences with joint reviews involving both supplier and the customer aimed at evaluating the content of specific work products (e.g. the specifications that are to be reviewed, understood and agreed) or verifying of managerial aspects of the supplier's development project (e.g. respect of planning, compliance with process requirements, control of risks, ...).
In the paper we intend submit the integration between software process assessment and joint reviews is described and discussed in order to identify advantages and possible limitation of its application in the practice.

12.00 Handling Traceability in Evolving Automotive Decision Processes
Thilo Schwinn, Hannes Omasreiter (Software Structures Research, Daimler AG, Germania) Carolin Hürster  (Faculty for Engineering and Computer Science, Germania)

Awareness of challenges and issues concerning traceability in increasing complex system environments. Possible solutions and/or approaches will be discussed.
* .
This paper results from exchanges with different enterprises and environments. Therefore it represents a summary of experiences from different sources and also provides deeper insights of the authors. Research issues and trends of high relevance will be addressed.
In times of increasing complexity in the systems/software and technical world prevalent project management and decision methods do not always seem to be able to keep up with the speed of this development. The causes of this growing complexity are manifold. Examples are longer system runtimes, in automotive or aerospace sectors caused by soaring integration and networking of electronic control units (ECU), cooperating functions, (international) laws, customer requirements and various supplier structures.
Therefore it is difficult to ensure awareness of all aspects influencing such global decisions. In particular, conflicts between local and global optima can arise easily and they are not always obvious or visible. Defining consistent decision processes is no task of triviality. Global and local views differ and the consequences of changes to any piece of the system often are unpredictable. For this reason consistency and comprehensibility of systems as well as of decision processes is necessary to ensure traceability.
Traceability is also needed for another issue discussed in the paper which will be the conflict between the efforts to standardize processes and the dynamics of projects and their environments. On one hand, coordination and leading of projects combined with a larger stability of projects provide a solid basis for project success. On the other hand, the adaptation of standardized processes within complex environments is almost impossible. As the project focus often is locally narrowed gaining an overview of all stakeholders` views demands a great effort. Local aspects from various groups have to be considered.
The paper further points out correlations between the issues of this topic. The complexity and the connections can e.g. be drawn up by the hierarchy layers of systems in the architectural view. From the top (strategy) to the bottom (IT infrastructure) different views or layers set priorities to different aspects. Examples are politics, economics, company, communications, resources, systems, software etc. Traceability between these layers is necessary for preventing conflicts and tensions as well as supporting decision processes.

12.30 Practical experiences of Function Points estimation and measurement in a complex outsourcing context of an Italian Public Administration.
Franco Perna, Roberto Meli (D.P.O. - Data Processing Organization, Italia)

• a real experience of application of FP estimation and measurement in a huge and complex contractual environment
• problems and solutions found in the implementation of a measurement contractual system.

In the management of software procurement in a commercial market environment, customer-supplier relationship is among the most important aspects to be considered. In case of a delivery including software development, executed under broad contractual outsourcing agreements, the economical evaluation process adopted either in the tender process and in the day by day management of the contract can make that relationship very critical to be managed.
In the Italian marketplace a big effort has been made, in the last decade, to apply economical reward processes based on parameters that are objective as much as possible. In the ICT domain, this effort led to the spreading of broad (multi-project) agreements based on an economical appreciation of software development and enhancement activities derived by the amount of delivered functionality, measured by the use of the Function Point method.
Using Function Points is not only a matter of writing appropriate Request for Tenders or Supplier's Offers: it is a matter of designing and operating an estimation and measurement process which is compliant with formal contractual provisions and with customer-supplier informal expectations. The process should be a good compromise among several attributes like precision of estimation and measurement, repeatability of results, easiness of execution, low impact on production processes and the like.
Aspects that should be carefully considered when installing a contractual measurement system are:
• Organization (Roles / responsibilities)
• Processes
• Methods
• Tools
A relevant component of this system is the measurement's dashboard, an information management tool indispensable for contract's governance. We will show how all of these aspects were considered into an actual implementation of the estimation and measurement system of an important Italian Public Administration outsourcing contract.

13.00 Networking Luncheon
   
14.00 Estimation of rework effort based on requirements categorization
Bee Bee Chua, June Verner (University of Technology, Sydney and National ICT Australia)

This work will help delegates understand how different types of requirements changes affect the effort involved in making those changes both during development and maintenance.

Poor estimates of project time are usually responsible for inadequate project management, and resource planning. Therefore, there is a need to investigate and better understand and the impact, in terms of effort, of requirement changes on software development projects.

Requirement changes are unavoidable and unpredictable during the development of most software projects. Regardless of the software development team size or the size of the project, every requirements change must be dealt carefully to ensure that every team member understands what the requirement change is, how the change is to be implemented and the amount of time needed to correct or to modify the software.
To estimate accurately the individual and group effort required during rework for any requirements change is a difficult task for many experienced cost and schedule estimators. This is because firstly there is normally not enough data available on which to base a model, and secondly there is no useful categorization of the various requirements types for estimating the amount of effort for a requirements change.
IT change control forms designed by industrial practitioners are not based on any theoretical framework that categorizes requirements changes in a logical, economical and structured manner. Practitioners often design change control forms based on the types of requirements outlined in project without a real understanding of the requirement's actual characteristics and attributes. Until now, there has been no standard method for categorizing requirements changes able to provide an understanding (both analytical and theoretical) that will enable IT practitioners to categorize requirements changes at both the project level and the requirement level. We provide such a categorization and use this as the basis of a rework effort estimation model.
This paper presents a theoretical model that categorizes requirements changes and uses the categorization as input into a cost estimation model. This theoretical model will benefit IT practitioners in providing them with a method for better effort estimation.  The added contribution is that it can help mitigate project risks early.

14.30 Effort estimation in agile software development projects
Andreas Schmietendorf (FHW Berlin - Berlin School of Economics, Fachbereich II, Otto-von-Guericke-Universität Magdeburg, FIN-IVS, CECMG - Central Europe Computer Measurement Group, Germania)

- Principles of agile software development methods
- Possibilities to carry out an effort estimation for XP-projects
- Applicability of the Function Point method for XP-projects
- Maturity of the XP-approach within the industries
- Empirical analysis about the industrial requirements for agile Projects

Agile Software Development Methods are nowadays wide spread and accepted. From the Software Measurement point-of-view not all metrics and methods from conventional lifecycle models can be used without adoption. Within this paper we want to investigate especially the aspect of effort estimation activities for agile software development projects. For this we want to show the possibilities and borders of effort estimation tasks and the new challenges. The following questions are examined:
1. Which conditions do projects that are executed with help of agile process models assume?
2. Do the classic methods of the effort estimation methods, like Function Points or COCOMO are applicable?
3. Which basic approaches (state of the art) to the effort estimation can be identified for agile executed projects at present?
Beside the clarification of these questions, a short overview is given to the key characteristics of agile software development methods. For this we want to consider especially the industrial accepted XP approach. XP stand for "eXtreme Programming" and provides a set of practices, values and principles. These set provides a "best practices" approach and should help to carry out successful software development projects. XP especially takes into account "feedback" and "change" activities. Feedback and changes are important for effort estimation activities too, as through [Glib 2007] noticed.
"Accurate estimation is impossible for complex technical projects, but keeping to agreed budgets is still possible using feedback and change."
In addition, an empirical analysis executed in the industrial surroundings offers statements about possible problems and borders of the agile procedure.
The following topics were examined within this empirical analysis:
- Compare the productivity between XP - and non XP-projects
- Compare the productivity before and after introduction of the XP-approach
- Compare the productivity in the context of similar development tasks
- Analysis of the productivity of maintenance projects executed with help of XP
- Comparison of the Load-Factors between XP - and non XP-projects.
 

15.00 Function Point: how to transform them in effort? That is the problem!
Gianfranco Lanza (CSI Piemonte, Italia)

* To understand the fact that the transformation from Function Point to effort is not a deterministic process but is correlated with many factors (not so easy to estimate). Presentation of a method that consider all of them..

The need to estimate the effort of a software project is one of the most important issues in ICT world.
The use of  Function Points to determine the functional dimension of a software project is, in CSI Piemonte, the base for deriving the effort and, consequently, the cost.
If the process to determine the functional dimension in Function Points can be considered a deterministic method, based on precise rules defined in IFPUG Counting Practices Manual, the process to determine the effort is less deterministic, depending by many factors (some of them difficult to evaluate).
CSI Piemonte has developed a model to determine the effort by Function Point through a process that, step by step, takes into account some non-functional factors that can influence the productivity.
Initially a "standard productivity" for the project is established trough two parameters: Programming Language (according with Capers Jones Language Programming Table) and dimension in Function Point (the productivity decrease if the dimension of the software project arises).
Then the  technical and non-functional factors (algorithmic complexity, relations with other products, relations with other projects, time binding, etc.) have to take into account to adjust productivity.
This adjustment could be applied selectively, not necessarily on the entire amount of Function Points.
For example, in a same project, productivity for implementing batch processes is often considered lower than that for online functionalities.
At this point a risk analysis  is performed. This can bring to consider a new effort in order to remove (or reduce) some risk, or to consider a contingency: a certain amount of extra time being correlated with a risk management activity.
In effort evaluation there is also to take into account of the activities not correlated with the functional dimension (effort for code data management, for example).
At the end the total effort is divided into RUP Activities for a better scheduling of the project and for deriving costs.
The effort estimate derived by Function Point is compared with the effort estimate derived by experience, thus deriving effort from Function Point is not the only method used to estimate effort and cost

15.30 Using Function Point in the estimation of real-time software: an experience __
Luigi Lavazza (CEFRIEL, Italia), Carla Garavaglia (Intecs - Syrea, Italia

The paper reports a set of experiences in measuring the functional size of real time software and estimating its development effort. Participants will learn from our experience that using function points to size real-time software is possible, and that this measure can be effectively used in estimating development projects. We shall also explain that effective estimation requires a good characterization of the product and development process. The characterization required by the SEER SEM tool and methodology, and how to apply it to real-time avionic software, will be also illustrated. 
The paper reports about the estimation of the development effort of real-time software using Function Points as the means for expressing the size of the software.
The work reported was carried out in a European company that develops various types of avionic and embedded applications. The company started an exploratory activity aiming at improving their estimation process. The immediate goals were the identification of a reliable sizing method for estimation-oriented software sizing, and the adoption of an estimation methodology and tool.
For practical reasons, the estimation tool was chosen among the best commercial proposals. In particular, SEER SEM was considered for adoption. The tool accepts both LOCs and FPs as sizing units.
The usage of LOCs for estimation suffers from well known problems, the most relevant being that the physical size of the software to be developed has to be estimated as well: the error in estimating the size sums up with the approximation in the effort estimation, thus yielding a result that is often too imprecise to be effectively used in contracting and planning.
On the contrary, FPs were considered particularly appealing by the management, since they can be computed on the basis of specifications, and can be counted -with some approximation- even though the specifications are not known in a complete and detailed manner.
Therefore, it was decided to explore the possibility of using FPs, counted according to the IFPUG measurement guidelines whenever possible.  When the real-time nature of the software made IFPUG guidelines inapplicable, we adopted ad-hoc counting criteria, using common sense and striving to preserve the principles of Function Point Analysis.
Actually, FPs are supposed to be not very suitable to represent the size of real-time software, since they are believed to fail in representing the inherent complexity of the software. Both the management and the authors were not convinced of this limitation of FPs, and decided to verify in practice the performance of FP-based estimation of real-time software.
The paper describes the process of estimating the physical size and the development effort for 8 projects, on the basis of their functional size expressed in FPs. The paper also stresses the importance of determining the factors that, together with the functional size, affect the estimates.
The results of the FP-based estimation are given in terms of: estimated size in LOCs, estimated development effort, differences with respect to the actual size and the actual effort spent. These results are discussed, taking into account the characteristics of each project.
The outcomes of our work are that:
- FP-based sizing of real-time software is feasible and gives reasonably good results. In fact, the sizes in LOC estimated by SEER SEM on the basis of the measured FPs are quite close to the actual size of the developed software. In other words, the functional size in FPs seems coherent with the actual size in LOCs, according to both the literature and the employed tool.
- FP-based effort estimation is also feasible: the estimated effort was considered reasonable by the management (also taking into account the actual effort). In practice, the estimation based on FPs and the actual effort are quite close in general; the differences that were observed in a couple of projects could be explained by the particular history of those projects.
- In general, the management considered that the estimations could be useful to decrease the risk of planning according to an unfeasible budget or underestimated development time. Accordingly, they are planning to employ FP-based sizing, in conjunction with the characterization of products and process required by the SEER SEM tool, in the company estimation process.

16.00 Coffee break  
 
16.30 Size Matters - Avoid The Common Pitfalls That Produce Poor Estimates By Using A Structured Approach To Sizing The Scope Of An Application
Andy Robinson (Galorath, Gran Bretagna)

1. Sizing methodology for different project profiles
2. Which sizing measures to use at what stage of a project
3. How to assess and cater for size growth of a project

Examination of currently-accepted software cost, schedule, and defect estimation algorithms reveals a common acknowledgment that assumed software size is the single most influential independent variable. It follows then that assumed software size has a significant impact on a given estimate's quality or usefulness, however all too often not enough attention is paid to this aspect of a project.

Typical failings are:
- No clear methodology for sizing
- Lack of or mixed definitions of size
- Taking the system engineers' estimates as gospel
- Not taking account of size growth inherent in all software projects

 This presentation will describe how to define a sizing methodology that allows companies to improve their estimating process by adopting a more structured approach that takes into account the development lifecycle phase at which an estimate is being produced. For example, at an early stage you are typically faced with a vague statement of requirements which can't be directly related to any notion of physical size. The estimating process is further complicated by the fact that the requirements should be a description of what is wanted not what needs to be built.

The presentation will cover an overview of the sizing measures that are typically used. These include some alternative measures for early stage estimates for new applications as well as more traditional direct sizing methods.

Sizing measures that will be covered include:
• History Based Sizing
- Analogy and Pairwise comparison
• Direct Measure Sizing
• Functions
• Function Points
• Source Lines of Code
• Alternative Sizing Measures
• Business Requirements
• Use Cases
• Structured Text
• Programs
• Features
• Modules

It will also cover Galorath's recommendations for which size metric should be used based upon the development lifecycle phase at which an estimate is being produced. The approach also takes into account the type project being undertaken, i.e. one size doesn't fit all. We will look at range of application types including web based developments, re-engineering projects, package implementations and new developments
Size growth is a given for most software projects and it can be defined as the Variability in the baseline estimated software size that results from a change in the common understanding of the required functionality and/or the context in which the software development project exists.
The presentation will tackle the issue of how to account for size growth associated with early stage software projects. The recommended technique is to use a 3 point range that takes into account uncertainty and risk.

Most organizations are undertaking maintenance of existing applications; however; one of the typical errors we see in determining the size of the project is to focus on overall size rather than effective size. In addition with the move towards SOA most companies are faced with trying to estimate what is required to redevelopment applications for re-use.
I will describe an approach for handling re-use and rework associated with redevelopment of applications. This approach can be used for both application maintenance as well as re-engineering applications for re-use. Galorath has defined a process for categorizing re-work based upon the effort required to perform redesign, reimplementation and retest. The process allows a company to adjust the overall percentage of re-work based upon an assessment of requirements using a weighting system to reflect the actual size of the redesign, reimplementation and retest effort.

17.00 Forum   
 
18.00 Closing