Software Process Improvement and Human Judgement Heuristics

This paper exemplifies how better knowledge about human judgement strategies known as heuristics can be used to improve software processes, especially estimation and prediction processes. Human judgement heuristics work well when they exploit a fit between their structure and the structure of the environment in which they are used. This use of environmental fit may lead to amazingly good judgements based on little information and simple computations compared with more formal approaches. Sometimes, however, the heuristics may lead to poor judgements. Knowing more about the strengths and weaknesses of human judgement heuristics we may be able to (1) know when to use formal process improvement approaches and when to use less expensive expert judgements, (2) support the experts in situations where the experts’ judgements strategies are known to perform poorly, (3) improve the formal processes with elements from the experts’ strategies, and (4) train the experts in the use of more optimal judgement strategies. A small-scale experiment was carried out to evaluate the use of the representativeness heuristic in a software development effort estimation context. The results indicate that the actual use of the representativeness heuristic differed very much among the estimators and was not always based on an awareness of fit between the structure of the heuristic and the structure of the environment. Estimation strategies only appropriate in low uncertainty development environments were used in high uncertainty environments. A possible consequence of this finding is that expert estimators should be trained in assessing how well previous software projects predict new software projects, i.e., the uncertainty of the environment, and how this uncertainty should impact the estimation strategy

Software Constraint Models – A Means to Improve Maintainability and Consistency

As application systems live longer and grow in size and complexity, there is an ever increasing need for methodologies, models and tools that can aid software builders in developing maintainable, correct and consistent systems. Imposing constraints, representing architectures, conventions, guidelines, etc., on the software is one step in that direction. One may distinguish between constraints within programs, constraints between programs, and constraints between programs and secondary storage. A coherent set of constraints are collected in a software constraint model. Automatic verification tools are crucial to the usefulness of such models. The paper describes a constraint model and a corresponding verification tool that have been developed in a persistent programming environment

Software Constraint Models - A Means to Improve Maintainability and Consistency

As application systems live longer and grow in size and complexity, there is an ever increasing need for methodologies, models and tools that can aid software builders in developing maintainable, correct and consistent systems. Imposing constraints, representing architectures, conventions, guidelines, etc., on the software is one step in that direction. One may distinguish between constraints within programs, constraints between programs, and constraints between programs and secondary storage. A coherent set of constraints are collected in a software constraint model. Automatic verification tools are crucial to the usefulness of such models. The paper describes a constraint model and a corresponding verification tool that have been developed in a persistent programming environment. Keywords: programming environments, maintenance, consistency, software constraints 1 Introduction Large, long-lived and data-intensive application systems that satisfy a complete area of information-processi..

Managing Change in Information Systems: Technological Challenges

: Information systems and other computer-based systems must continuously undergo change in order to reflect change in their environments. The present technology used to implement such systems, including models, methods, tools and languages, does not have an inherent understanding of the nature of evolution. The rigidity of existing systems is a hindrance for user requested enhancements. Propagating changes correctly is a particular problem. It is common to find that necessary changes consequent on some other change have not been made, so that the system is inconsistent and will eventually fail to operate correctly. The paper discusses tools for system maintenance and focuses on the issue of automation. A tool that automatically generates and maintains all the information it needs is presented. To provide more information about the form and extent of the evolution in real-world systems, the same tool was instructed to collect change measurements. Information about the evolution of a lar..

An Evaluation of Applying Use Cases to Construct Design versus Validate Design

Use case models capture and describe the functional requirements of a software system. A use case driven development process, where a use case model is the principal basis for constructing an object-oriented design, is recommended when applying UML. There are, however, some problems with use case driven development processes and alternative ways of applying a use case model have been proposed. One alternative is to apply the use case model in a responsibility-driven process as a means to validate the design model. We wish to study how a use case model best can be applied in an object-oriented development process and have conducted a pilot experiment with 26 students as subjects to compare a use case driven process against a responsibility-driven process in which a use case model is applied to validate the design model. Each subject was given detailed guidelines on one of the two processes, and used those to construct design models consisting of class and sequence diagrams. The resulting class diagrams were evaluated with regards to realism, that is, how well they satisfied the requirements, size and number of errors. The results show that the validation process produced more realistic class diagrams, but with a larger variation in the number of classes. This indicates that the use case driven process gave more, but not always more appropriate, guidance on how to construct a class diagram The experiences from this pilot experiment were also used to improve the experimental design, and the design of a follow-up experiment is presented