Catálogo de publicaciones - libros

Human performance improvement is essentially unlimited. We continuously try to go beyond what is thought to be the limits. The fastest time for the mile was 4.5 minutes in 1865, 4.0 minutes in 1954, and is around 3.6 minutes today (depending on when you read this introduction). One might expect a three-minute mile during this century. Can you imagine how little runners might have improved if there were no stopwatch or measured track? Unmeasured and unchallenged performance does not improve! Moreover, it will not improve if not fostered by best practices in the discipline.

“The answer is 42” is the popular statement around which Douglas Adams wrote a series of thought-provoking and insightful science fiction books [Adam79, Adam95]. “42” was supposedly “the answer to life, the universe, and everything” in the world, the end to all questions and the final answer that would explain all the rules and logic that make our world move. A huge computer specifically constructed to this endeavor was working for centuries to derive that answer. There was only one difficulty with that answer 42, namely that the question was unknown. The computer seemingly was only asked to provide the answer but not to explain the logic behind and what question it did really address. Therefore, another even bigger computer was built and some books later, it would come back with the question behind that answer. Well, the question was surprising and confused rather than explained anything. Yet it helped to reveal that “there is something fundamentally wrong with the universe”. But that is another story.

Software measurement as an essential part of the software engineering discipline does not consider the only. In order to support the decision findings in any aspect of software systems or products, software processes and software resources would involve plenty of approaches and methodologies for analysis, understanding and evaluation of software in general. This point of view motivates the consideration of measurement as “software measurement evaluation” and involves the statistical methods supporting the tasks of the measurement processes themselves.

Usually the software measurement process is embedded in software engineering processes and depends on the environmental characteristics such as

We will look into the “performing” of the measurement process from a systematic tools-oriented perspective here. The remaining part of the book will detail the practical process-oriented aspects of the measurement process.

Better, faster, cheaper! Practically all enterprises work towards one or more of those slogans. They have often dedicated programs in place to reduce cost, improve productivity or simply adjust towards the ever-changing business in which they operate. While such objectives and the related bold management statements are on each company website, the same companies do not know where they are and how to measure progress towards these objectives. Measurements not only must be technically defined, repeatable or reliable.

Estimating size and cost is one of the most important topics in the area of project management. You cannot plan if you don’t know these basic parameters. The dynamics of the software market with increasing usage of external components and adapting code instead of writing it from scratch has lead to extended or new kinds of methods for the estimation of product size or development effort in the background of . Gradually estimation moves away from mere volume-or size-based estimation towards functional and component estimation.

Project management is the major application of software measurement. And still, measurement is not sufficiently used to keep projects on track. Whether it’s software engineering for a new embedded automation product, or the development of a software application or the introduction of a managed IT-service, demand outstrips the capacity of an organization. As a result we see two things. First the acceptance of impossible constraints in time, content and cost. Second and a direct consequence of the first is an increase in churn and turmoil, as well as budget overruns, canceled projects and delays.

Customer-perceived quality is among the three factors with the strongest influence on long-term profitability of a company [Buzz87]. Customers view achieving the right balance of reliability, market window of a product and cost as having the greatest effect on their long-term link to a company. This has been long articulated, and applies in different economies and circumstances. Even in restricted competitive situations, such as a market with few dominant players (e.g., the operating system market of today or the database market of few years ago), the principle applies and has given rise to open source development. With the competitor being often only a mouse-click away, today quality has even higher relevance. This applies to Web sites as well as to commodity goods with either embedded or dedicated software deliveries. And the principle certainly applies to investment goods, where suppliers are evaluated by a long list of different quality attributes.

Software measurement of different systems are related to the different kinds of systems (information-based, embedded, Web-based, decision support, knowledge-based etc) and to the different kinds of software development paradigms such as object-oriented software engineering (OOSE), aspect-oriented programming (AOP), component-based software engineering (CBSE), feature-oriented development (FOD), service-oriented software engineering (SOSE), event-based design (EBD) and agent-oriented software engineering (AOSE). On the other hand, general characteristics of software systems are meaningful in different IT environments such as performance, security and usability or context-dependent as outsourcing and offshoring. Finally, measurement artifacts can depend from the different kinds of systems such as embedded systems, information systems, and so on.