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.
(with existing social 16 1 Introduction cultural values), (d) result demonstrability (how easy it is to see when improvement happens), (e) visibility (of the team member’s work to more senior people), (f) triability (the extent to which the methodology can be tested prior to full-scale adoption) and (g) reinventibility (the degree to which the methodology can be tailored). Clearly it is this last attribute that has most direct relevance to SME. Personality testing in the IT context was also
requirements team with significant inputs from the domain experts team. It can be started as soon as the software-specific parts of the system requirements specification and system architecture specification are relatively stable. It is maintained during the life of the application to remain relevant as new requirements are added and existing requirements are changed. The following usage guidelines are relevant to the Software Requirements Specification: Consider removing the quality requirements
of the name component clashes with our use of it in this book). They show that a method chunk consists of process fragment(s) and a product fragment (two subtypes of Method Fragment). They also introduce two other kinds of method element: pattern and road-map. Patterns may be generic conceptual patterns 2.4 Fragments, Chunks and Components: A Comparison 39 Component: Pair Programming Origin: eXtreme Programming Input artefacts: User story, Source code, Coding standard, Test cases Output
Henderson-Sellers and Gonzalez-Perez (2011) explain how granularity affects method fragments by focussing on a single example—that of fragment generation from the Task subtype of the WorkUnit meta class (Fig. 2.1). These and other quality issues are discussed in more detail in Chap. 8. 2.7 2.7 Guidelines and Descriptors 49 Guidelines and Descriptors Guidelines and descriptors were mentioned briefly in Sect. 2.2. Here, we examine these important concepts in more detail. Guidelines originate
Henderson-Sellers et al. 2008). #IEEE reproduced with permission Outcome. Constraints are subtyped into Precondition and Postcondition; Guidelines give advice on how to use the method fragment during method enactment and Outcome is defined as ‘observable result of the successful performance of any work unit of a given kind’, used to assess the performance of work units. The main difference between the fragment approach and the method rationale ˚ gerfalk and colleagues (A ˚ gerfalk and Wistrand