Situational Method Engineering
Pär J. Ågerfalk
Format: PDF / Kindle (mobi) / ePub
While previously available methodologies for software – like those published in the early days of object technology – claimed to be appropriate for every conceivable project, situational method engineering (SME) acknowledges that most projects typically have individual characteristics and situations. Thus, finding the most effective methodology for a particular project needs specific tailoring to that situation. Such a tailored software development methodology needs to take into account all the bits and pieces needed for an organization to develop software, including the software process, the input and output work products, the people involved, the languages used to describe requirements, design, code, and eventually also measures of success or failure.
The authors have structured the book into three parts. Part I deals with all the basic concepts, terminology and overall ideas underpinning situational method engineering. As a summary of this part, they present a formal meta-model that enables readers to create their own quality methods and supporting tools. In Part II, they explain how to implement SME in practice, i.e., how to find method components and put them together and how to evaluate the resulting method. For illustration, they also include several industry case studies of customized or constructed processes, highlighting the impact that high-quality engineered methods can have on the success of an industrial software development. Finally, Part III summarizes some of the more recent and forward-looking ideas.
This book presents the first summary of the state of the art for SME. For academics, it provides a comprehensive conceptual framework and discusses new research areas. For lecturers, thanks to its step-by-step explanations from basics to the customization and quality assessment of constructed methods, it serves as a solid basis for comprehensive courses on the topic. For industry methodologists, it offers a reference guide on features and technologies to consider when developing in-house software development methods or customising and adopting off-the-shelf ones.
can represent both method knowledge and a (sub) process aspect, as well as supporting the combination of a process-focussed part and a product-focussed part. As well as a guideline, the chunk has an associated descriptor (as we noted earlier). This descriptor is said to extend the contextual view captured in the signature or interface, in order to define the context in which the chunk can be reused (see also Fig. 2.3). Formally, we can say descriptor ¼< reuse situation, reuse intention > ð2:1Þ
values and ethical principles to which an action conforms. Thus, we cannot judge whether or not means and ends are rational without considering the value base upon which we consider the possibilities. In this view of method rationale, all fragments or components of a method are related to one or more goals (see also Sect. 6.4 on goal-based method construction techniques). If a fragment is proposed as part of a method, it should have at least one reason to be there. We refer to this as the goal
using one of the four strategies, as shown in Fig. 5.3, originally developed in the context of method chunks but in fact more generally applicable. The decomposition and aggregation discovery strategies have obvious meaning: the alternative discovery strategy substitutes a previously existing strategy and the progression discovery strategy helps to create a new section as a progression from an existing one. Strategies associated with the next section (Define a guideline) are threefold:
template-based, guided and modification; the last of these linking together changes in guidelines and changes in sectioning. For Identify a method part, there are three suggested strategies. The first (section-based discovery) assumes that every section of the map may be regarded as a method part with an associated intention achievement guideline (IAG)—actually the IAG associated with this section forms the basis for the method part. The parallel section discovery strategy identifies the IAG
annotated with is_hidden? refers to is destination of has has Postcondition Firing Condition Fig. 5.8 Method part for merger of statechart and class diagram to form Fusion’s object chart—as presented by Brinkkemper et al. (figure 3, 1998) (With kind permission of Springer Science + Business Media) is no overlap but several connection points (e.g., between class and state); furthermore, the granularity and level of abstraction of each of these method parts is the same. Had it not been, then