Christof Ebert

Optimizing Supplier Management in Global Software Engineering

Global software engineering is the consequence of the rather friction-free economic principles of the entire software industry. Many companies start global software engineering (GSE) due to perceived cost differences. Most of these companies engage globally active outsourcing companies to achieve fastest ramp-up of their globalization targets. After a while into that business they realize that savings are much smaller and problems are more difficult to cure than before. Disillusioned many abandon their GSE activities. What has gotten wrong? GSE bears many challenges, specifically if done with an external supplier. We will look in this article to lessons learned from GSE to effectively and successfully manage supplier relationships. Specifically we use process maturity and CMMI as a guidance how to improve supplier relationships. Both experiences and practical guidance result from our work with clients in automotive and telecommunication industries. They can be readily implemented, specifically our checklists for effective supplier management.

Messung und Bewertung von Software

ZusammenfassungSoftware bestimmt unser Leben. Sowohl ihr Nutzen als auch die damit verbundenen Risiken wachsen ständig. Das Wissen um Software, ihre Entwicklung und die vielfältigen Anwendungsmöglichkeiten ist Voraussetzung für die Beherrschung ihrer ständig wachsenden Komplexität. Softwaremessung und -bewertung ist die Disziplin in der Softwaretechnik und Informatik, die sich mit der quantitativen Behandlung von Eigenschaften von Softwareprodukten, -prozessen und -projekten befasst. Dabei geht es um die Nutzung von Softwaremessungen, also das Einführen von Messsystemen, das Extrahieren von Messdaten, das Evaluieren der Softwarequalität und das Entscheiden über Verbesserungsmaßnahmen, um bestimmte Ziele, wie beispielsweise Projektkontrolle, Fehlerreduktion oder Effizienzsteigerung, zu erreichen. In diesem Beitrag werden der Stand der Softwaremessung dargestellt, einige aktuelle Probleme identifiziert und zukünftige Arbeiten motiviert.

Improving Processes and Products

Today, software is a major asset of many companies. Engineering investments are primarily spent for software development for the majority of applications and products. In our fast changing world, a company will only succeed if it continually challenges and optimizes its own performance. Engineering of technical products is currently undergoing a dramatic change. Ever more complex systems with high quality must be developed at decreasing cost and shortened time to market. At the same time, competition is growing and the entry barriers to established markets are diminishing. The result is more competitors claiming that they can achieve better performance than established companies. An increasing number of companies are aware of these challenges and are pro-actively looking at ways to improve their development processes.

Quality Control and Assurance

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.

Making Measurement a Success — A Primer

“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.

Performing the Measurement Process

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.

Planning the Measurement Process

Usually the software measurement process is embedded in software engineering processes and depends on the environmental characteristics such as the estimation of the next or future product components, process aspects and resource levels for keeping a successful continuous project in the software development ([Chri06, Dumk02b, NASA95]); the analysis of artifacts, technologies and methods in order to understand the appropriate resources for the software process ([Dumk99b, Dumk02a, Wang00]); the structuring of the software process for planning the next steps including the resource characteristics ([Dumk97, Dumk03b, Kene99]); the improvement of techniques and methodologies for software development as software process improvement ([Chri06, Dumk01, Eber03b, Emam98, Garm95, Muta03a, Warb94]); the control of the software process, including the analysis of the product quality aspects and their relationships ([Dumk01, Eber03b, Eber97b], and [Kitc96]).

Empirical Laws and Rules of Thumb

This chapter will summarize the quantifiable experiences and wisdom that the two authors collected in their (combined) over fifty years of practical software engineering. Believe it or not: We have measured all the way over these fifty years!. Knowing that it is often difficult to just use plain numbers to characterize a situation, we are also aware that beginners and practitioners need some numbers to build upon — even if their applicability is somewhat limited. We will therefore provide in this chapter concrete and fact-based guidance with numbers from our own experiences so you can use it as a baselines in your projects.

Measuring Software Systems

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.

Getting yet more Information

Software measurement is not easy. Many measurement programs fail to deliver actual performance improvements — for numerous reasons, as we showed in this book. You might have further questions on software measurement that go beyond the book or request specific insight.