Values and Principles

About Us

The People


Risk management





Muse Cases



Mix and Match Making sense of the Best Practices jigsaw: Attainability

by Paul Oldfield

Abstract: Not everyone favours mix and match approaches to agile methodologies. In some respects this attitude is quite correct, there is no need for another methodology consisting of pre-selected best practices. In other respects it is incorrect, existing methodologies are the result of such a mix and match effort, or alternatively advocate the selection of best practices as an ongoing process. Possibly of greater significance, those truly agile developers who decide how to do things as they proceed are, in effect, mixing and matching from their own repertoire of techniques and best practices, on the fly. Some of the ideas and techniques that get included into the mix may appear to have nothing to do with the development process but instead address, say, the environment or the social aspects of a team. Anything that helps delivery of working software is fair game for mix and match.

(This paper was originally published in Agile Times.)


Cost of Change - Modernised

by Paul Oldfield

Abstract: The Boehm model of Cost of Change has been generally accepted for years now, and has been used as the basis for arguments in favour of heavyweight processes that attempt to prevent errors early in the development cycle and at all stages thereafter. Various proponents of Agile methodologies have challenged the validity of the model. This paper tries to form a basis on which the arguments may be evaluated, should figures ever be measured.


Appropriate Process Approaches

(work in progress)

by Paul Oldfield

Abstract: This whitepaper summarises the approach for Appropriate Process.


Effective Modelling with Use Case Chains

by Hüseyin Angay

Abstract: Use case modelling requires a constant balancing of the trade-offs between the complexity of the networks of use cases and the complexity of the contents of the use cases. We can reduce some complexity in the use case text at the expense of increased complexity at use case relationship level. Or, we can simplify use case relationships at the expense of increasingly complex use case text. Use case chaining is a technique for reducing the negative impact of complex use case networks. We can model with relatively large numbers of use cases and using simpler use case text, but we can reduce the network’s complexity whenever we need it. The technique allows teams to work with use cases in a more agile manner, without worrying about complexity trade-offs but neither sacrificing the quality of the model. The paper gives a number of examples where the technique may be applied, including requirements elicitation, elaboration, verification and project scheduling.


Domain Modelling

by Paul Oldfield

Abstract: The concept of Domain Modelling takes several forms. This document is about one of those forms. The concept, its philosophy, its uses and advantages, and ideas on how to perform domain modelling of this form are all introduced. In depth discussion is not attempted, here you will find the merest introduction to the topics. (This document is not static and may be updated as the author sees fit.)


Pattern: Ask Five Times Why

by Paul Oldfield

Abstract: You are trying to gather requirements necessary for specifying a system, but some received requirements are design decisions that come from the stakeholder. You want to build a flexible system.


Use Case Pattern: Template Use Case

by Huseyin Angay

Abstract: There are many cases where we would like to model significantly different sets of interactions that still have underlying similarities. Modelling this functionality in use cases may lead to many nearly identical use cases, which will eventually become an expensive exercise in redundancy. For projects where modelling these requirements as use cases is still necessary, we propose the Template Use Case pattern that will preserve the consistency and benefits of a use case model without the associated overheads for creating and maintaining virtually identical sets of use cases.


CASE Tool Support for Use Cases

by Hüseyin Angay

Abstract: Use case modelling has long been viewed as a second class citizen next to object modelling. Some of this has to do with the relatively unglamorous image of requirements analysis compared with the design and implementation side of the business. Another reason for the unpopularity, however, is a lack of tool support for business and requirements analysis with use cases. This paper lists a set of essential requirements for supporting analysis and development with use cases.




Copyright 2002, Appropriate Process Movement