Agile teams measure their velocity for performance, based on Story Points. However, such velocity does not allow predicting when the product will be finished. Story points measure effort only. They do not discriminate between creating functionality and other tasks. Non-functional requirements (NFR), such as enhancing product quality, test coverage, removing technical debt, as well as process-related NFR such as agreeing with stakeholders, getting requirements right, or documenting, consume effort but do not add functionality. Thus, it remains unclear whether the product makes any progress, or the team is just looping around. Euro Project Office has therefore developed a method how to complement a product backlog by functional size, indicating progress and completeness in unambiguous terms. The method is based on the international standard ISO/IEC 14143 and ISO/IEC 19761. NFR are understood as in . Tools are available as open source and can be used by development teams with minimum investment into training.

Agile teams measure their velocity for performance, based on Story Points. However, such velocity does not allow predicting when the product will be finished. Story points measure effort only. They do not discriminate between creating functionality and other tasks. Non-functional requirements, such as agreeing with stakeholders, designing, testing, or documenting, consume effort but do not add functionality. Thus, it remains unclear whether the product makes any progress, or the team is just looping around technical debt and unclear requirements. Euro Project Office has therefore developed a method how to complement a product backlog by functional size, indicating progress and completeness in unambiguous terms. The method is based on the international standard ISO/IEC 14143 [1] and ISO/IEC 19761 [2]. Tools are available as open source and can be used by development teams with minimum investment into training.

For the Internet of Things (IoT), for safety in automotive, or for data protection, to be legally compliant requires testing the impact of any actions before allowing them to occur. However, system boundaries change at runtime. When adding a new, previously unknown device to an IoT orchestra, or when an autonomous car meets another, or with truck platooning, the original base system expands and needs being tested before it can do decisions with the potential of affecting harm to humans. This paper explains the theory and outlines the implementation approach a framework for autonomous real-time testing of a software-based system while in operation, with an example from IoT.

Checking regularly the progress of a running entire software development project or parts of it is a mandatory task of project management. The purpose of progress checks is to monitor whether an actual project will be completed successfully at the project deadline at the latest. It is common practice to track and to communicate project progress by burn charts, especially by burn-up charts in the case when the amount of work varies by, e.g., scope creep during the time line of the project. This paper shows that a burn-up chart continuously adapted by means of a specific rule and combined with a Bayesian Approach to the German tank problem leads to an efficient tool for project progress monitoring.

Defect Density Measurements based on functional size have big advantages over traditional approaches based on counting entries in defect repositories. Using structural information, defects can be located within data movements using the ISO/IEC 19761 COSMIC framework. Consequently, defect counts and defect density indicators become comparable among different projects and products, and can even be used for contracting purposes and in acceptance criteria. This article explores modern defect density measurements in two different areas: first, in mobile apps, where functionality spreads between server and devices and defects might arise at communication interfaces between server and devices, and second, in instruments with embedded software ("Internet of Things"), where defects occur when interfacing between different functional users. This yields new insights into origin of defects, and, consequently, leads to defect avoidance strategies. Also, it is shown how ISO/IEC 20926 IFPUG can be used to identify layered application boundaries within the counting scope, establishing effective test scenarios useful for counting defects with ISO/IEC 19761 COSMIC. A best practice for setting application boundaries is proposed that applies both to IFPUG and COSMIC.

For some years, Statistical Process Controls (SPC) techniques such as traditional Shewhart control charts add value to monitor and to control the Software Development Process (SDP) efficiently. Nonetheless, the application of Shewhart control charts to the SDP involves a considerable problem, since the availability of a sufficiently large set of observations is essential when constructing traditional control charts. Especially at the start-up of each SDP phase such a set cannot be provided. To remedy this problem, Q control charts widely used when monitoring short-run manufacturing processes have been introduced successfully. This paper focuses on the predictive property of Exponentially Weighted Moving Average (EWMA) Q control charts and investigates whether the predictive property is attractive for monitoring and controlling the SDP. Results of initial experiments are also reported.

ICT Projects have a bad reputation: they often exceed budget or change scope. It holds especially when writing new software is involved, however, writing mobile apps, joint & distributed software development across organizations, integration of new services, sizing maintenance or ICT portfolio projects is also affected. Project management is needed but without proper estimation methods and tools it is limited to managing the budget overrun. For the economy, this is a serious blocker, since ICT is the major motor for economic growth. Work breakdown structure fails because it is part of the project to find out what work is needed, expert estimation fails because experts cannot remember previous decisions and their estimates suffer from important variations. Without proper budgeting, ICT projects carry enormous risks for the financial stability for the sponsors of an ICT project.

Software Project Cost Prediction is one of the unresolved problems of mankind. While today's civil engineering work is more or less under control, software projects are not. Cost overruns are so frequent that it is wise never trusting any initial cost estimate but take precaution for higher cost. Nevertheless, finance managers need reliable estimates in order to be able to fund software and ICT projects without running risks. Estimates are usually readily available - for instance based on functional size and benchmarking. However, the question how reliable these estimations are is often left out, or answered in a purely statistical manner that gives no clue to practitioners what these overall statistical variations means for them. This paper explains how to make use of Six Sigma's transfer functions that map cost defined by a committee of GUFPI-ISMA onto project cost. Transfer functions reverse the process of estimation: they show how much a project costs under suitable assumptions for the cost drivers. If cost drivers can be measured, and transfer functions can be determined with known accuracy, not only project cost can be predicted but also the range and probability for such cost to occur.