Modelling Method Heuristics for Better Quality Products

2005

The main objective of software engineers is to design and implement systems that implement all functional and non-functional requirements. Unfortunately, it is very difficult or even generally impossible to deliver a software system that satisfies all the requirements. Even more seriously, failures in fulfilling requirements are generally detected after the realization of software systems. This is because design decisions are mostly taken based on estimations, which can turn out to be wrong at a later stage in the design process. Switching to different de-sign alternatives at a later stage can be very difficult since this may demand drastic changes in design and also may increase project time and costs. In this paper a model is proposed for modeling and tracing de-sign processes with respect to the selected design alternatives. Based on the model, two algorithmic definitions of design strategies are given, which enable software engineers to optimize design decisions with respect to quality and resource constraints.

IEEE Computer, 2011

Handbook of Product and Service Development in Communication and Information Technology, 2004

Quality management (QM) emerged in the century as a method to reduce errors and uncertainty in industrial mass production. The focus was on reducing variation in repetitive industrial processes and on fulfilling the requirements of rational market actors. At the innovative end of the modern high-tech environment, the basic assumptions of repetition and rationality will frequently not hold true. However, QM methods remain usable and useful at the routine end of the high-tech environment. By improving quality and success at the routine end they free up crucial resources for the frequent and rich communication that is required at the innovative end, thus improving the overall quality and success of the product or service. 6.1. What is Quality? Much of the development in QM was originally a practitioner-driven and methodology-oriented doctrine. Many of the taxonomies and formal definitions of quality remained for a long time vague, confusing, and, in some cases, even downright contradictory (Reeves & Bednar, 1994). Fortunately, this problem is now beginning to be a thing of the past. Over the past few decades, QM has evolved from being an airy fad into a well-defined body of knowledge. This was established especially in the 1990s in the codification of QM into ISO/GS9000 quality systems as well as in the quality awards, such 149

Companies create a variety of products, and different releases of those products, for many reasons. These range from market-testing trial balloons disguised as 'beta tests' to releases forced by incompatible changes in operating systems. Some have many changes, some have few. Some can tolerate fairly glaring defects, others have to be extremely reliable. Some are built on very speculative financial grounds, where others protect lucrative franchises.

Information and Software Technology, 2015

Context: Software quality models provide either abstract quality characteristics or concrete quality measurements; there is no seamless integration of these two aspects. Quality assessment approaches are, hence, also very specific or remain abstract. Reasons for this include the complexity of quality and the various quality profiles in different domains which make it difficult to build operationalised quality models. Objective: In the project Quamoco, we developed a comprehensive approach aimed at closing this gap. Method: The project combined constructive research, which involved a broad range of quality experts from academia and industry in workshops, sprint work and reviews, with empirical studies. All deliverables within the project were peer-reviewed by two project members from a different area. Most deliverables were developed in two or three iterations and underwent an evaluation. Results: We contribute a comprehensive quality modelling and assessment approach: (1) A meta quality model defines the structure of operationalised quality models. It includes the concept of a product factor, which bridges the gap between concrete measurements and abstract quality aspects, and allows modularisation to create modules for specific domains. (2) A largely technology-independent base quality model reduces the effort and complexity of building quality models for specific domains. For Java and C# systems, we refined it with about 300 concrete product factors and 500 measures. (3) A concrete and comprehensive quality assessment approach makes use of the concepts in the meta-model. (4) An empirical evaluation of the above results using real-world software systems showed: (a) The assessment results using the base model largely match the expectations of experts for the corresponding systems. (b) The approach and models are well understood by practitioners and considered to be both consistent and well suited for getting an overall view on the quality of a software product. The validity of the base quality model could not be shown conclusively, however. (5) The extensive, open-source tool support is in a mature state. (6) The model for embedded software systems is a proof-of-concept for domain-specific quality models. Conclusion: We provide a broad basis for the development and application of quality models in industrial practice as well as a basis for further extension, validation and comparison with other approaches in research.

Lecture Notes in Computer Science, 2001

Process assessment and process improvement are both very difficult tasks since we are either assessing or improving a concept rather than an object. A quality process is expected to produce quality products efficiently. Most of the existing models such as CMM, ISO 9001/9000-3 etc. intend to enhance the maturity or the quality of an organization with the assumption that a matured organization will put its processes in place which in turn will produce matured products. However, matured processes do not necessarily produce quality products [21, 6]. The primary reasons are: (i) In the process quality models, the relationship between the process quality and product quality is far from clear, and (ii) many of the process models take a monolithic view of the whole lifecycle process, and as a result, the idiosyncrasies of the individual processes do not receive proper attention. In this paper, we first define an internal process model in a formal manner. Next, we define a generic quality model whose scope covers all the development processes and most of the supporting processes associated with the development phase. The generic quality model is a parametric template and could be instantiated in a systematic manner to produce the quality model for any individual process. We then show such a customization for the formal specification process and use this customized model to formulate a GQM-based measurement plan for the same process. We then discuss how the generic model would be useful in process assessment and process improvement.

2003

Abstract There are a great number of different kinds of quality requirements. Consisting of a hierarchy of quality factors including associated quality characteristics and quality measures, a quality model provides a structured foundation on which to identify, analyze, and specify these quality requirements.

IEEE Transactions on Reliability, 1995

In recent years, many tools have been deveioped in the areas of programming techniques, design methodology, development processes, and test strategies. All of these are aimed at producing a quality product with a minimum cost. Together with emergence of these tools, there is a recognition of the problem of how to effectively implement them into a total systems development environment. One of the factors to a successful development is the ability to exercise proper control over the various development processes.

Design Science, 2022

Method development is at the heart of design research as methods are a formalised way to express knowledge about how aspects of design could or should be done. However, assuring that methods are in fact used in industry has remained a challenge. Industry will only use methods that they can understand and that they feel will give them benefit reliably. To understand the challenges involved in adopting a method, the method needs to be seen in context: it does not exist in isolation but forms a part of an ecosystem of methods for tackling related design problems. A method depends on the knowledge and skills of the practitioners using it: while a description of a method is an artefact that is a formalisation of engineering knowledge, a method in use constitutes a socio-technical system depending on the interaction of human participants with each other as well as with the description of the method, representations of design information and, often, tools for carrying out the method's tasks. This paper argues that crucial factors in the adoption of methods include how well they are described and how convincingly they are evaluated. The description of a method should cover its core idea, the representations in which design information is described, the procedure to be followed, its intended use, and the tools it uses. The account of a method's intended use should cover its purpose, the situations or product types within its scope, its coverage of kinds of problems within its scope, its expected benefit and conditions for its use. The different elements need to be evaluated separately as well as the method as an integrated whole. While verification and validation are important for some elements of methods, it is rarely possible to prove the validity of a method. Rather the developers of methods need to gather sufficient evidence that a method will work within a clearly articulated scope. Most design methods do not have binary success criteria, and their usefulness in practice depends as much on simplicity and usability as on the outcomes they produce. Evaluation should focus on how well they work, and how they can be customised and improved.