How to Succeed in Communicating Software Metrics in Organization?

While software metrics are indispensable for quality assurance, using metrics in practice is complicated. Quality, productivity, speed, and efficiency are important factors to be considered in software development (Holmstrom et al. 2006; Svensson 2005). Measuring correct metrics and using them in the right and transparent way contributes to pushing development in a desirable direction, leading to achieving projected goals and outcomes (Staron and Meding 2018). On the other hand, tracking the wrong metrics, and failing to interpret and communicate them properly results in a stressful work environment, conflicts, distrust, lower engagement, and decreased productivity (de Sá Leitão Júnior 2018; Ellis et al. 1991; Staron 2012). To ensure proper and effective use of metrics in organizations, successful communication around metrics is essential (Lindström et al. 2021; Post et al. 2002; Staron and Meding 2015). The purpose of this study is to understand and improve communication about metrics in contexts of contemporary software development practice in organizations. This is achieved by identifying the bottlenecks in the process of communication around metrics and how to overcome them in practice. Drawing on 38 semi-structured interviews and interactive workshops with metrics teams members and stakeholders from three organizations, we identify three interrelated challenges including limited knowledge about metrics and lack of terminology, uncoordinated use of multiple communication channels, and sensitivity of metrics, which influence workplace communication, trust, and performance. Our study shows the importance of developing metrics terminology to ensure the development of a shared understanding of metrics. Further, raising awareness about the affordances such channels as dashboards, email, MS Teams meetings/chat, stand up meetings, reports, etc., commonly used in software organizations, and how they can be combined to successfully transfer information about metrics is essential (Verhulsdonck and Shah 2020). It becomes especially important in remote work practices. Finally, though metrics is a powerful tool for decision making, enhancing transparency, and steering development in the desired direction, they can also turn into finger-pointing, blaming, and a pressing tool, resulting in stress and conflicts (Streit and Pizka 2011). The findings also indicate the importance of creating a culture around metrics, clarifying, and informing about the purpose of metrics in the organization (Umarji and Seaman 2008). We plan to build on the early findings of this study to develop a comprehensive framework for successful software metrics communication within organizations

Measurement of Ada Throughout the Software Development Life Cycle

Quality enhancement has now become a major factor in software production. Software metrics have demonstrated their ability to predict source code complexity at design time and to predict maintainability of a software system from source code. Obviously metrics can assist software developers in the enhancement of quality. Tools which automatically generate metrics for Ada are increasing in popularity. This paper describes an existing tool which produces software metrics for Ada that may be used throughout the software development life cycle. This tool, while calculating established metrics, also calculates a new structure metric that is designed to capture communication interface complexity. Measuring designs written using Ada as a PDL allows designers early feedback on possible problem areas in addition to giving direction on testing strategies

A Case Study on the Adoption of Measurable Agile Software Development Process

Agile methodologies for software development meet the challenges of the current highly dynamic and competitive business environment. The aim of this case study is to improve existing software development process in a project for the public administration, following the basic principles of agile methodologies. Appropriate metrics for continuous evaluation of the process are introduces to help evaluating and improving the methodology. The main objectives of the new methodology are to improve communication with customers, to improve communication among different distributed teams and inside the teams, and to continuously evaluate the way software is developed through selection and usage of software metrics. The paper presents the results of methodology adoption in two subsequent iterations of a real project

Mining developer communication data streams

This paper explores the concepts of modelling a software development project as a process that results in the creation of a continuous stream of data. In terms of the Jazz repository used in this research, one aspect of that stream of data would be developer communication. Such data can be used to create an evolving social network characterized by a range of metrics. This paper presents the application of data stream mining techniques to identify the most useful metrics for predicting build outcomes. Results are presented from applying the Hoeffding Tree classification method used in conjunction with the Adaptive Sliding Window (ADWIN) method for detecting concept drift. The results indicate that only a small number of the available metrics considered have any significance for predicting the outcome of a build

Who are Metrics Team’s Stakeholders and What Do They Expect? Conducting Stakeholder Mapping with Focus on Communication in Agile Software Development Organization

As an increasing number of organizations create metrics teams, conducting stakeholder mapping is pivotal for identifying and analyzing metrics stakeholders’ expectations for reducing the risks of miscommunication and project failure. Further, though team-stakeholder communication is essential for successful collaboration, few studies focus on it in software measurement context. This case study seeks to identify and analyze metrics team’s stakeholders, with a special focus on communication challenges in team-stakeholder contacts. Inspired by Bryson\u27s Basic Stakeholder Analysis Techniques and Mitchell, Agle, and Wood\u27s theoretical model for stakeholder identification, a stakeholder mapping exercise was conducted using interactive workshops and follow-up interviews with 16 metrics team members and their stakeholders. The results illustrate the complexity of identifying stakeholders in agile organizations, the importance of developing a metrics culture, and enhancing transparency in team-stakeholder communication. The study aims to contribute to the development of stakeholder theory and offers insights into communication in software engineering context

Performance-Measurement Framework to Evaluate Software Engineers for Agile Software-Development Methodology

In spite of the marked benefits agile development brings, it has several shortcomings in quantitative quality measurement, especially in evaluating the performance of individual software engineers. The evaluation criteria for software engineers’ performance have been traditionally driven by metrics that don’t fit into agile-development principles. This study proposes a measurement framework to evaluate the performance of software engineers. The proposed measurement framework aligns with agile-development core values and principles. This framework can be applied to various agile methods, although the research assumes the use of the Scrum methodology by the software-development team and organization. The proposed framework is simple and doesn’t impose overhead on the development team or organization, as it is driven by key agile and Scrum development metrics such as team velocity, escaped-defects rate, defect-cycle time, defect spill-over rate, and individual communication and social skills.Keywords : Agile Software Management, Software Quality Management, Software Engineers Performance Measure, Scrum

A metrics paradigm for object-oriented analysis and design.

For several years, the software industry has been affected by a problem called the software crisis. Many software developers have worked hard to determine remedies for this crisis. The crisis deals with products being produced over costs, behind schedule, with low quality, and not meeting customer satisfaction. Processes are being used which waste resources and build low quality products. In dealing with the software crisis, software practitioners have used many tools, methodologies, and metrics to help produce better products, save resources, and increase productivity. Metrics are meaningful measures used to determine how well software is being produced, where weaknesses are in products, processes, or resources, and indicate where to make improvements. Today, the most popular methodology is the Object-Oriented (00) methodology. Users of this methodology want to prove that it helps resolve the software crisis. There is a belief that 00 systems are developed earlier, easier to understand and maintain, and contain reusable components. However, without metrics, the effectiveness of the 00 approach cannot be proven. Metrics must be used to show if the process or resources being used is responsible for the success or failure of software development, if management of the process is responsible, if the complexity or size of the product being produced is responsible, or if a lack of communication or misunderstandings of requirements is responsible. There are many, many reasons why metrics are used and can be seen in this Thesis. Many metrics are being used for traditional software development methodologies that deal with processes, products, and resources. However, there is no metric paradigm for the 00 development methodology. But, there is a small set of metrics proposed for 00 programming. We provide a 00 metric paradigm that contains metrics grouped into nine categories. We grouped the metrics into categories to make the selection of a particular· metric easier. These nine metrics fit nicely into the 00 methodology. The metrics can be used to measure processes, products, and resources. We provide a size estimation method that helps determine progress, costs, quality, effort, complexity, and schedule. The metrics can be used to prove the effectiveness of the 00 methodology and indicate areas for further improvement

A self-organising awareness system for distributed software engineering

Software engineers and other collaborative disciplines rely on informal "out-of-band" communication for ef- fective coordination of their activities, especially in agile methods. This type of communication is lost when development is distributed, with consequent deleterious effects on engineer effectiveness. In order to effectively support distributed software engineering, a replacement for this informal communication must be found. Much previous research focussed on either synchronous awareness such as radar views and shared editors, where participants were distributed in space not time, or asynchronous awareness such as change notification, which did not explicitly support concurrent activities. A unified approach is necessary to support software engineering. Furthermore, requiring co-location of engineering teams is not possible in today's marketplace where development is often outsourced, consequently a definite requirement for awareness tools to replace informal communication exists. To implement an awareness tool capable of providing awareness of activities distributed both in time (asyn- chronous awareness) and space (synchronous awareness). The tool will not rely on a centralised reflector; instead information will be distributed over a peer-to-peer network arranged using a self-organisation algorithm. Consequently awareness information need not travel more than a few hops from its originating peer, reducing network load and increasing relevance of information received. Unlike reflector-based CSCW systems, the network will scale and will not have a single point of failure in the reflector. Furthermore, without the need to setup a reflector, there is the capability for ad-hoc awareness, using low-complexity peer discovery by local broadcast for example. The tool will be integrated with the Eclipse development environment. The files a user is currently editing will determine the data they are interested in and fuzzy similarity metrics will be used to compare the collections of each peer in the network in order to drive the self-organisation process. To evaluate the success of self-organisation, a simulation approach will be used before deploying the algorithms in the wild. To evaluate the effectiveness of the awareness provision, initial deployment and controlled experiments will be conducted within the Distributed Software Engineering group at the University of Lincoln and a later version of the tool will be trialled with existing Eclipse user

WISE: Automated support for software project management and measurement

One important aspect of software development and IV&V is measurement. Unless a software development effort is measured in some way, it is difficult to judge the effectiveness of current efforts and predict future performances. Collection of metrics and adherence to a process are difficult tasks in a software project. Change activity is a powerful indicator of project status. Automated systems that can handle change requests, issues, and other process documents provide an excellent platform for tracking the status of the project. A World Wide Web based architecture is developed for (a) making metrics collection an implicit part of the software process, (b) providing metric analysis dynamically, (c) supporting automated tools that can complement current practices of in-process improvement, and (d) overcoming geographical barrier. An operational system (WISE) instantiates this architecture allowing for the improvement of software process in a realistic environment. The tool tracks issues in software development process, provides informal communication between the users with different roles, supports to-do lists (TDL), and helps in software process improvement. WISE minimizes the time devoted to metrics collection, analysis, and captures software change data. Automated tools like WISE focus on understanding and managing the software process. The goal is improvement through measurement