INFS8005 System Development Methodologies

1. INFS8005 System Development Methodologies Seminar 10The Framework-in-action: Method Tailoring

2. Aims of Seminar This seminar considers how methods are tailored. We focus on the following issues:- Research on the tailoring of methods:- contingency factors research method engineering research Method tailoring at Motorola in Ireland (Telco):- Information processing systems The development context The Developers Formalised method tailoring  at industry level & organisational level

3. Aims of Seminar Project level tailoring: method-in-action Roles of method Other papers

4. Introduction Developers rarely follow formal methods exactly  even when explicitly specified. So new versions of existing methods recommend some contingent tailoring. But little guidance on how to tailor method  have to rely on intuition of developer. Means that tailoring is tacit, and ad hoc, so not able to inform others. Are there any principles we can extract from the literature to help here?

5. Method Tailoring Research While very little literature on method tailoring directly we consider:- contingency factors research method engineering 1. Contingency Factors (CF) Research Specific features of the development context (DC) are mapped to the selection of an appropriate ISD method from a portfolio of methods. For example:- Davis (1982)  uncertainty in DC determines method used to gather requirements Gremillion & Pyburn (1983)  commonality, impact, and structure determine method used

6. Method Tailoring Research Iivari (1989)  method needs to incorporate a “built in” contingency framework (eg. Multiview, Multiview2). Benyon & Skidmore (1987)  tool kit approach including soft systems, structured approach, data-centered approach, and participative approach (inadequate? Avison et al., 1988) Shomenta, Kamp, Hanso & Simpson (1983)  various characteristics of application determine method used. 2. Method Engineering (ME) Research ME proposed (see R72, R79, R80, R82, R83, R90) because of perceived problems with contingency approach, namely:- existing methods didn’t cover all contingencies

7. Method Tailoring Research cost of sourcing and training for each method required by contingencies is prohibitive few guidelines as to how methods or tools could be mapped to development contingencies Kumar and Welke (1992) proposed ME to overcome these contingency problems  but not grounded in practice. ME traced back to mechanical engineering in the 1930s. Need a strategy for constructing situational methods (SM) out of existing proven method fragments (MF).

8. Method Tailoring Research Use a method based repository that contains method fragments. Use a “meta method” (MM) to design SMs cheaply quickly and efficiently. The method components (the component base) in these MMs are discrete predefined and pre-tested and constructed seamlessly. The component base is based on stakeholder values. Tutorials and training aids are also part of the package. 8

9. Method Tailoring Research Used a recursive approach with metamodeling which captures information on:- concepts, representational forms uses of methods. Metamodels divided into 2 sub-categories  meta-data models (static aspects of methods) and meta-process models (dynamics of method). Metamodeling provides advantages in terms of representing, systematising, and comparing methods. Software to help  MetaEdit

10. Method Tailoring Research Nb. both approaches (CF & ME) are deductive since based on theoretical arguments. Little practical application of their ideas. R6 discusses ME for OO systems development. Is there anything we can do to validate their concepts? Fitzgerald, Russo, and O’Kane (2003) (R44) looked at how relevant these concepts applied at Motorola in Ireland  Telco in the text.

11. The Method Tailoring Framework Figure 9.1 depicts the overall situation at Motorola in Ireland (Telco)  next slide. (This is an example of the application of the framework in the text  you might want to apply this to a project you have worked on in the past.)

12. The Method Tailoring Framework Figure 9.1 depicts the overall situation at TELCO.

13. The Method Tailoring Framework Lets consider each part of the model in turn. 1. Information Processing Systems Large telephone systems with high levels of reliability – ‘dial-tone’ criteria. Telco technology constantly evolving with new products and services on offer. Systems constantly adapted to incorporate interfaces to new developments Systems developed in C++ and C.

14. The Method Tailoring Framework 2. The Development Context Large teams of developers on each project and development environment is very formalised. Also, development process is very formalised  they have documented the development process (organisational standard software process, or OSSP) OSSP tailored precisely to each project’s development process, and followed rigorously on all projects as part of CMM. CMM requires large amount of metric data on development process subsequently displayed on notice boards for the attention of developers

15. The Method Tailoring Framework Strong engineering culture consistent with:- strong belief that requirements can be defined in advance because  majority of development represents incremental functional changes to existing systems 3. The Developers 400+ developers in Ireland headquarters Developers have strong technical background in engineering or computer science New employees are made aware of OSSP in induction training sessions. The process engineering group ensure that projects follow CMM.

16. The Method Tailoring Framework Some developers don’t like the highly formalised development environment at Telco so they leave for other jobs. 4. Formalised Method Tailoring Telco do some macro tailoring to get their organisational ISD method (OSSP). This is the basis for micro-level tailoring at the project level  see method-in-action section. Macro-level tailoring at the Industry level Telco grounded development method in public domain IEEE 1074 software standard and the V software lifecycle model (V-SLCM) – next slide

18. The Method Tailoring Framework IEEE 1074: international standards specifying the set of mandatory activities for the proper development and maintenance of activities  see http://www.acm.org/tsc/lifecycle.html Fits well with the application of CMM IEEE 1074 specifies an SDLC process which is recognised to need tailoring to the context. TELCO use the V-model SDLC to complement the IEEE 1074 standard. IEEE 1074 describes the processes but not the products for the lifecycle  the deliverables must be mapped to the method. Thus, tailoring is an inherent requirement for the IEEE standard 18

19. The Method Tailoring Framework Macro-level tailoring at the Organisational level Some of more common software processes not covered in depth in IEEE 1074  eg., testing and maintenance. Also, differences between TELCO divisions GPD & GSG. Each has configured software processes to the exigencies of their development environment  eg., in GPD subcontractor management more relevant. Likely that future development wants processes not in current method  eg., intermediate delivery of product after design but prior to testing.

20. The Method Tailoring Framework OSSP tailored from basic elements  creating trusted, rigorous and reliable software process that is compatible with CMM. OSSP while stable is expected to evolve. OSSP is general process that each project is expected to follow  operational definition and fundamental process elements and their inter-relationships. This overcomes problem with CF and ME approaches  organisations in practice cannot afford to wait while a lengthy tailoring approach takes place!!!!

21. The Method Tailoring Framework Leaves relatively smaller amount of project tailoring to occur. 5. Project Level Tailoring: Method in action Project specific characteristics are factored in to OSSP at project level. Operational needs of project determine which aspects of OSSP are factored in  choose project specific practices (eg. Project planning, subcontractor management). Project manager responsible for this process. Further refinements made based on specific features of actual project.

22. The Method Tailoring Framework Some of tailoring decisions made at project start and included in project plan  eg., have high level and low level design specification (instead of detailed design specification) if project complex. Others tailoring decisions made as project progresses  eg., change in commitments may require project replanning or just absorb the impact in the current schedule. Also could give developer a waiver from training course if they satisfy certain criteria.

23. The Method Tailoring Framework 6. Roles of Method At Telco roles of method are rational intellectual ones  necessity to manage projects in highly competitive market place is paramount. Rigorous development process needed to satisfy “dial-tone” level of reliability. Errors and downtime should be kept to a minimum  errors should be handled in very precise process. All fixes undergo rigorous testing process  risk of regression errors minimised. Thus, it is a very formalised development environment

24. The Method Tailoring Framework Telco maintains vast amount of metric data which is used to inform future development. OSSP evolves in an attempt to capture high level lessons that have been learned and formally captured in the divisional software processes. This method is then taught as part of the induction process for new employees  SECI knowledge spiral.

25. Other Readings R6 Method Engineering (ME) for OO Systems Development OO methodologies are difficult to tailor because they are highly interconnected. Agile methodologies, such as XP, also must be strictly followed or else not XP  not allowed to tailor. Use ME approach  ME implicit in standards such as ISO 12207 Example of ME approach is the OPEN (Object oriented Process, Environment, and Notation) process framework (OFP).

26. Other Readings Process: description of phases, activities, tasks, techniques, hr, technology and the life-cycle to be used. OFP has a comprehensive library of process components used in a variety of software projects, namely:- work product  output of development process producer  responsible for creating, evaluating, iterating and maintaining work products work units  operation performed by producer language  used to document work product stage  duration where some achievement occurs Figure 3 (next slide) shows the OFP process

27. 27

28. Other Readings R7  High Speed Software Development Practices: What works, What doesn’t. In IT projects there is a tension between goals of (i) fast development, (ii) low cost, and (iii) high quality. Web development increases the tension between these goals. This study looks at the practices (Pn) used by high speed development in the US:- P1  parallel development and frequent releases to satisfy the demands of time to market compression. P2  tools and reusable components to improve programmer productivity

29. Other Readings P3  production prototyping to overcome ambiguous requirements P4  customer implantation to cope with fluid requirements P5  multi-tiered architecture to cope with lack of design time and experience P6 tailored methodology to cope with changing environment These 6 practices are not new but the demands of a high speed environment have bought them together. 29

30. Other Readings R23  Strong vs Weak approaches to Systems Development Systems development is a problem solving activity  look at the problem solving literature (PSL) for guidance. The PSL distinguishes between strong and weak problem solving approaches. Strong methods are designed to address a specific type of problem  optimal. Weak methods are general approaches applied to many problems  not as optimal.

31. Other Readings Need expertise in 2 areas  (i) application domain and (ii) software solutions domain. Traditional views of the ISD process have over-concentrated on the solutions domain  produced weak problem solving approach  too general to be powerful Also, a single application-independent methodology is not optimal for all ISD projects. What are the alternatives? match methodology to application disaggregate methodologies multi-paradigm approaches

32. Other Readings R39  A Framework for Understanding how a Unique and local Development Method Emerges in Practice. Method : organised collection of concepts, beliefs, values, and normative principles supported by material resources (Anderson et al, 1990). prescriptions for performing a certain type of work process with the help of principles, techniques, and computer based tools (Mathiassen, 1997). In practice IS developers rarely adopt methods in their entirety  they adapt and apply method elements in a pragmatic way.

33. Other Readings This paper explores the relationship between what influences and shapes the unique method in practice and how it emerges  emergent method. The paper uses 3 perspectives to understand emergent methods:- structuralistic perspective  text’s method-in-action framework, namely (i) context, (ii) developers, (iii) information system, and (iv) formalised method individualistic perspective  actions of IS developers influence and shape emergent method (repertoire, language, and media). interactive process perspective  emergent methods occur over time through the interaction between structural influences and the actions of individuals (social context, social process, and content of change) 33

34. Other Readings The study used the Multiview/WISDM methodology for the RDR ISD project. Figure 3 (next slide) is the method emergence map for the RDR project. Results? structuralist  explains choice of and extent to which Multiview/WISDM formalised method was used individualistic  expertise explains selection and sequence in which method elements were pasted together to form the unique method. interactive  facilites identification of the structural elements and influential actors that played a major role in shaping the system and emergent method over time.

35. 35

36. Other Readings Managers and developers should establish a clear business vision of what a project should achieve and organise work around this vision. Any formalised method is better thought of as a guide to organisation for the achievement of the vision rather than a prescriptive basis for project planning and action. 36

37. Other Readings R54  The Use of Systems Development Methodologies in Practice: A Field Study. The use of formalised methodologies are assumed to improve the process and product of ISD. But methodologies are not followed rigorously in practice.

38. Other Readings R67  A Framework for Redesigning ISD Methodologies to Enhance Global Information Infrastructure. An ISDM has 3 key characteristics:- breaks the IS development into phases and sub-phases provides tools and techniques and procedures to assist developers in their work provides a coherent view of the aspects of systems development for successful completion ISDMs are adapted during the course of projects. How are methodologies adapted to projects?

39. Other Readings ISDMs are technology innovations  technology as designed (TasD). Over time the technology is evaluated, explored and adapted to meet users’ needs  technology in use (TinU). TasD  TinU is technology appropriation This process is the model of technology appropriation (MTA). Figure 2 (next slide) shows this MTA model adapted for methodologies-in-use. 39

40. 40

41. Other Readings R81 Reinventing Methodology: Who reads it Anyway? ISDMs have been part of IS practice and research for over 20 years  used in 1/3 of IS practice. CMM and SIP require ISDMs This paper finds different types of ISDMs needed for “planners” and “doers”. Looked at Andersen Consulting (AC) (now Accenture) methodology  70 ISDM users. Findings! Most practitioners did not use methodologies

42. Other Readings Most practitioners did not use methodologies but AC makes extensive use of their ISDM  disconnect??? The developers produced (eg.) reports indicating they did use it!!!!!! The developers were interested in job aids  steps, checklists, questionnaires, and other how-to information ISDMs are often promoted by management to provide better project co-ordination and control  especially on large projects. 42

43. Other Readings R110  Customising Agile Methods to Software Practice at Intel Shannon Not much known about the tailoring and engineering of agile methods. Advocates of agile argue that they must be applied in their entirety. Only 6% of developers rigorously adhere to methods (Fitzgerald, 2000). The bureaucratic nature of methods has slowed development to the extent that developers are forced to abandon them (Fowler, 2000)  goal displacement.

44. Other Readings Agile manifesto arose from Agile Alliance in 2001. Agile methods are individually incomplete in supporting the development effort  need both But XP and Scrum are complementary XP provides good support for technical and coding aspects of ISD Scrum is a good framework for project planning and tracking So there was some “tailoring” of agile methods at Intel Shannon as combinations of fragments of XP and Scrum (figure 3 – next slide)  more like ME. 44

45. 45

46. Other Readings The tailoring process is more like the synergistic combination of individual agile practices  eg., they chose only 6 of 12 XP practices (table 3 – next slide). The use of the final “product” lead to better project outcomes. 46

47. 47