Metamodeling and method engineering Introduction to ISD and ISD methods

1
Metamodeling and method engineering Introduction
to ISD and ISD methods

• Juha-Pekka Tolvanen
• 25.2.2004
• Lecture 2 Introduction into ISD and ISD methods
• Contents
• Introduction to ISD
• ISD methods
• Advantages and disadvantages of method use
• Modeling methods
• Types of models

2
Systems development and object systems

• Definition Information systems development (ISD)
  is
• a change process taken with respect to a number
  of object systems in set of environments by a
  development group to achieve or maintain some
  objectives held by some stakeholders.
• These concepts relate in the following way
• Object system
• arbitrary boundary set by purpose and perspective
• phenomena/ objects relationships
• contradictions / ambiguity / overlapping
• emergent properties

3
Systems development and change process

• Change process
• change in the state (object and / or
  relationships)
• purposefulness
• social nature
• uncertainty
• means
• impacts
• problem
• regularity / uniqueness

4
Systems development and environment

• Environment
• everything outside the development group and
  object systems
• a web of conditions and factors which affect the
  development group and the change process
• consist of several sub environments
• labor
• economy
• technology / infrastructure (like tools,
  techniques, and methodologies)
• normative (laws and regulations)
• stakeholders (see below)

5
Systems development and development group

• Development group
• organization
• roles
• task structure
• authority/responsibility
• informal organization
• power bases
• hidden agendas
• collegial relationships
• personal involvement

6
Systems development and goals

• Goals
• what is good, how one should behave
• implicit vs. explicit
• outcomes of negotiation / given
• equivocality vs. non-ambiguous
• multipurpose
• contradictory vs. supportive

7
Systems development and stakeholders

• Stakeholders
• can set claims about the object systems and their
  properties
• are driven by specific interests and goals
• internal (users, management, organizational
  units), external (clients, government bodies,
  professional associations, computer
  manufacturers, software houses etc.)
• some members of development group / others not

8
How can we manage information system development?

• Make it repeatable (prediction / control)
• Make it efficient (productivity)
• Make it adaptable (effectiveness)
• Most these goals are sough by the use of
  conceptual structures and description languages
  i.e. through modeling methods

9
Information Systems Development Methods

• Definition of a method(ology) ambiguous
• In ISD it generally denotes
• communicable
• formalizable
• enactable
• knowledge about ISD, i.e. how to
• identify
• specify
• implement
• evaluate changes and
• organize the ISD process

10
Information Systems Development Methods

• Definition Information systems development
  method is
• an organized collection of concepts, beliefs,
  values, and normative principles (knowledge)
  supported by material resources to carry out
  changes in object systems in an effective and
  systematic manner.

11
Characteristics of ISD methods

• Good engineering methods (Berard, 1993)
• can be characterized by measures of quantity and
  quality
• can be repeated with similar kind of results
• can be thought to others
• can be applied by others with reasonable success
• lead constantly to better results than stetson
  approach
• can be applied in several design situations (not
  unique)

12
Structure of ISD method

• Method knowledge deal with

13
Conceptual structure

• Identifies key concepts to focus on
• Identifies a set of concepts, relationships among
  the concepts and rules
• Restrict attention to certain aspects of IS and
  others are ignored
• Underpins all types of method knowledge
• Conceptual structure is often application- or
  domain specific
• One key reason why so many methods exist!
• Some method developers formalize the conceptual
  structures (e.g. UML) whereas most others dont

14
Notation

• Concepts can be only discussed and represented
  with a notation
• Various representations
• diagram
• text
• matrix
• table
• Various formal semantics
• formal (logic, rules)
• semi-formal (structured, OO)
• free form (rich pictures)

15
Process

• ISD is a change process Method should include
  guidelines for carrying out ISD
• Modeling related processes
• Management related processes

16
Participation and roles

• ISD is a group activity
• Methods should identify roles and
  responsibilities
• commissioning agent
• informant
• acceptor
• user
• analyst / project manager
• designer
• constructor

17
Development objectives and values

• Development objectives and goals
• Methods should include explicit statements about
  what kind of development solutions are considered
  good!
• Often these are implicit
• Deal with technical aspects
• Values and assumptions
• Epistemology
• constructivistic
• objectivistic
• mentalistic

18
Types of method knowledge example of SA/SD
19
Benefits of method use

• Benefits of methods use (Smolander et al. 1990)
• Enhance standardization of documentation and
  system work,
• Methods make systems work easier and faster,
• Act as a "Guarantor" for quality of outcomes,
• Support communication,
• Support reuse and system maintenance,
• Decrease dependency from key persons (teaching,
  learning), and
• Make testing more easy.

20
Method use in practise, 1

• Characteristics of methodology use (Smolander et
  al. 1990) in Finland
• Almost every company applied some methodology or
  framework,
• Applied methodologies however left phases "open",
  and
• None of the companies used methods systematically
  in their ISD
• In 2001 Still state of the art e.g. in
  TietoEnator

21
Method use in practise, 2

• Low acceptance of methods
• 26 use formal methods (Fitzgerald 1995)
• 40 use methods (Fitzgerald 1995)
• 62 use a structured approach (Necco et al. 1987)
• 66 use methods frequently (Russo et al. 1996)
• 82 use methods (Hardy et al. 1995)
• Selected sample, definition of method and the
  actual question explains differences among
  results
• Paradox if methods are considered feasible, why
  are they not used systematically?

22
Disadvantages of method use

• Disadvantages of method use (Smolander et al.
  1990)
• Methods mean more work and more bureaucracy
• Methods slow down the actual development work,
• Methods are difficult to learn, and training will
  take time and cost money,
• Decrease freedom of professionals because they
  force to follow a strict procedure, which are
  unsuitable for some purposes,
• Work load in the first phases of IS development
  increases and the benefits are seen only later,
• The maintenance of descriptions is tedious,
• Methods are not mature yet, and
• It is hard to select a proper method for a given
  situation.

23
Experiences of method use

• Wynekoop, Russo and Clomparens (1995) studied
  method use through survey study (ngt 100
  organizations)

24
When methods should be used?

• Methods are not needed, if
• Project is a small one (few thousands row of
  code) and
• Project is not a critical (e.g. need to be
  maintained over a long period of time)
• Few notes about the small
• 100K lines is not 10 times 10K lines! Often in
  practice 50-75 times 10 lines
• Complexity increases exponentially with the size
  of the software
• Ripple effect" error correction in the
  maintenance causes easily by side-effect new
  errors when the size of the program grows

25
Why methods are used?

• To just support communication, any systematic
  method is better than no method!
• The number of face-to-face communication channels
  increases radically when the development team
  becomes larger
• n developers ? n(n-1)/2 communication channels!

26
Why modeling?

• Complex
• many levels of change
• overwhelming amount of detail
• different views
• Uncertain
• why to change
• what to change
• how to change?
• Contextual and contingent
• past history
• development group
• domain
• technology

27
Modeling procedures

• Requirements
• effectivity (effectiveness)
• efficiency
• completeness
• consistency
• accuracy
• well-defined products
• determinism
• relevance
• formalisability
• communicable
• reducing complexity
• stepwise
• integrated

28
Types of models

• State models
• Data models
• Process models
• Object models
• Interaction models
• Flow models
• Use Case models
• Collaboration models
• Component models
• Deployment models
• etc.

29
State models
30
Data models
31
Data flow models
32
Process models
33
Object models
34
Use Case models