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 didnt 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 OKane (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 projects
  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 dont 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

17
(No Transcript)
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 doesnt.
• 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 ? texts
  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