- Email: [email protected]
Model of system evolution
Model of system evolution B C Glasson
A meta-model of system development is described. The metamodel uses three main concepts: system evolution, system states, and development deliverables. The meta-model sees information systems evolving as they are developed and used. It uses system states to describe and control that evolutionary process. It uses deliverables, which are simply the outcomes of system-development work, to define a system as being in a particular state of evolution. Creating new deliverables causes a change of state. The meta-model can be used to build project-specific development strategies as an alternative to imposing a standard methodologybased approach. computer-based in/ormation system-development models, methodologies, support environments, evolution, system states, deliverables
Methods for the development of computer-based information systems have received considerable attention recently. The I F I P W G 8.1 CRIS Series (comparative review of information systems) is illustrative of the many attempts being made world wide to understand existing methods or to develop new ones t 3. As a result of this attention, there is a plethora of methods available to today's system developer (e.g., Longworth 4 identifies over 300 methods). This suggests one of two things: either there is some ideal method awaiting discovery or the method will always be contingent on the problem. The possibility of there being one ideal method for all problems is a myth. The reality is that each situation requires its own solution strategy. The immediate need is not for new methods. More versatile system-development approaches are needed that: • allow access to the full repertoire of known methods • provide a mechanism that enables a subset of those methods to be linked easily into an appropriate solution strategy for any given problem • can adapt as new problems and methods emerge Versatile approaches like these must be based on a meta-model of the system-development process that is flexible yet robust. The meta-model must address systems evolution in the broadest sense covering planning, development, and use and addressing evolution processes, management, and technical matters. It will be a meta-
School of Information Systems,Curtin Universityof Technology, Kent Street, Bentley WA 6102, Australia
vol 31 no 7 september 1989
model because it will incorporate and use other models. It needs to be flexible to have wide application. It needs to be robust as it will underpin each solution strategy. The author agrees with Macdonald 5, who argues that a single coherent meta-model is an essential component of any automated development environment. This paper introduces one such meta-model. This meta-model (called here the 'model' for simplicity) is built on three main concepts and a number of supporting ones. The model is an early outcome of research into the development of an automated system-development support environment 6. This paper outlines the model; explains the three main concepts it uses, namely, system evolution, system states, and development deliverables; and briefly illustrates its application. MODEL The model treats all systems as being in a state of evolution at any moment. The particular state of evolution is determined by the existence or otherwise of an agreed set of entities called 'deliverables'. Systems evolve through system-development effort. System development means creating new deliverables from previous ones according to some previously defined relationships. System development is controlled by defining the essential deliverabledependency relationships and any essential attribute values (e.g., owner or method). The process is kept flexible by allowing the model's user to set the other attribute values (e.g., form or notation) and to set the nonessential relationships. The model is represented diagrammatically in Figure 1. It is best explained through a discussion of the underlying concepts and a brief illustration of its use. SYSTEM
EVOLUTION
Information systems evolve. They exist in some form. They are developed into another. They are used and then developed further and so on until they are replaced. Information-system evolution is a fundamental concept of the model. The model assumes that the information system will change, it does not presuppose, however, what the pattern of change might be. That is, it makes no assumption as to what events might occur to bring about the change, what outcomes might result from it, the sequence of those events, or the rate of change. Attempts by methodologies to make such presumptions have led to much argument, the 'life-cycle' debate being a case in point 7 lo.
0950-5849/89/070351-06$3.00 (~-~1989 Butterworth & Co (Publishers) Ltd
351
State I
State 2
State 3 . . . . . . . . . . . . . . . . . . . . . . . . .
State n
Deliverable 2.1
Deliverable 2 . 2 .................... Deliverable 2. n
Deliverable 2.2.1
Deliverable 2 . 2 . 2 ............... Deliverable 2 . 2 . n
Principal deliverable relationships Deliverable 'defines' state Deliverable 'depends on' deliverable Deliverable 'contains' subdeliverable Principal deliverable attributes Form (notation, language) Owner (actioner, portic ipont ) Method (tool, technique)
Figure 1.
State B
Identified problem or opportunity
Specified requirements
State D
State C
Commissioned system
Designed solution
Figure 2. Possible set of system states
Model of system evolution
The model requires the user to define a change pattern or sequence before system development begins. However, it imposes no preconditions as to what that pattern might be. If the circumstances call for (say) a life-cycle approach, the model can accommodate it. If, in different circumstances, (say) a version of prototyping is deemed appropriate, the model can handle that as well. Furthermore, it can handle mixed approaches (e.g., prototyping to clarify user requirements followed by life-cycle to design, build, and implement). The model accepts that systems are dynamic without presupposing a particular change pattern. This is most important if different methods are to be linked to solve a particular problem (e.g., as is advocated for many CASE tools).
SYSTEM STATES If information systems evolve, then at any moment such a system is in a given state of evolution. The model calls these 'system states.' There may be any number of system-state instances during an information system's evolutionary cycle. To make the concept useful, the model imposes some structure. The model's structure requires the system developer or project planner 'user' to recognise some finite set of system states. The user defines a version of the model in terms of this recognised (by them) set of system states. That model version is used to build particular system-development solution strategies. The user might choose to recognise four states as shown in Figure 2. These may be decomposed for convenience into more detailed lower substates. An illustrative decomposition of one of the user's recognised states into a recognised (by that user) set of substates is shown in Figure 3. Decomposition continues insofar as it is helpful. The model allows this hypothetical user to choose to view information-system evolution in these terms. This is important. Different views of system evolution might be equally valid in different situations. The model defines system development as a transition path through a set of system states. It allows the users to define their own view of that evolutionary process, however, by having them define their own set of recognised system states.
352
State A
State B Slmeified r e q u i r e m e n t s B.a.
B.b.
A clarified and reaffirmed project
Present context description
B.d
B.c
Future context description
Change alternatives option descriptions
Figure 3. Illustrative decomposition of 'specified requirements" state As an illustration, an alternative system state set is shown in Figure 4. The criterion used in determining the number of, and descriptors for, system states is simple. The question is asked, 'Will this view of system evolution help people in this particular organization understand and manage the development of this particular system?'. The set of system states chosen allows: • the represention of a static view of the system evolution process • the description of a system as being in a particular state of evolution The agreed set of system states provides an organization with a common 'snapshot' view of the system-development process. If information systems evolve, however, the users must also have a way of representing that change process; in other words, a way of representing the dynamics of systems evolution. The model addresses the dynamics of system evolution in the same way it addresses the static aspects. It provides a flexible structure. System evolution means changing the focal system from one system state to another without unnecessarily disturbing its hierarchical or collateral relationships (the terms focal systems and collateral relationships are taken from Stamper12). The evolutionary transition path between states, however, is also situation dependent. The model requires
information and software technology
4.2 Packagedsolution
4.1 New applications and I
II
Strategy
Tactical plan
XII
III
Needing maintenance
System study details
XI
IV
System review
External design
X
V
Production
Technical design
IX
VI
Implemented
Procured resources
VIII
VII
major enhancements A
D4
4.3
Constructed
A
,.B
C
4.4 Minor enhancements
Conversions
A
B
De - ~ ' ~ ' ~ C
A
D=
B
=C
4.6 Prototype (requkements)
4.5 Prototype (design)
=B
0 4
Installed
~B
Figure 5.
l
~.C
Illustrative state transition paths
Figure 4. Alternative view of system states (adapted from Rock-Evans 11) the user to define a transition path to manage system development, that is, to choose an appropriate development sequence for the particular system-development project. The user might define a transition path within and between the agreed set of system states. The model provides a structure to enable development sequence definition. It does not impose a general view as to what that development sequence might be. There is no one preferred system-development sequence. There are a number of likely system-development scenarios, each requiring a different development sequence, as illustrated in Figure 5. The model can accommodate these scenarios and more. The discussion so far has emphasized the need for the model to accommodate a wide range of system-development views. However, this flexibility needs to be controlled13. Control is achieved by determining a particular solution strategy for a particular situation. The solution strategy must: • define an appropriate set of system states and substates to describe that system-development situation • define the process of system evolution as a series of sequenced state changes Now the last of the three main model concepts, namely, the development deliverable, is discussed. DEVELOPMENT
DELIVERABLE
A deliverable is simply the tangible outcome of systemdevelopment work (e.g., screen layout, coded module,
vol 31 no 7 september 1989
interview report, test data, or maintenance request). The model uses the deliverable concept in two ways. First, it uses deliverables to define more precisely the agreed system states. Second, it uses the dependency relationships between deliverables to define the system-development process. System states are comprised of, and defined by, a set of deliverables. The potential set of system-development deliverables is considerable. Work to date indicates a number in the order of 100013. Each system-development problem will use some subset. The user must define that subset, and the associations between its members, in each system-development situation. Again the choice lies with the user. However, the model allows organizations to build 'templates' of project types to assist in this process. An illustration of a system state/deliverable association at the highest level of decomposition is shown in Figure 6. The user may decompose deliverables into subdeliverables to the extent that is helpful. Once established, these associations define each system state more precisely. They determine the particular state of evolution of any given system. That is, it is the existence or otherwise of a given set of deliverables that determines a given system's evolutionary state. The first use of deliverables then is to define the agreed set of system states. The second, and more important, use of the deliverable concept is within the development process itself. Changing a system from one system state (with one set of deliverables) to another (with its set of deliverables) is system development. Creating output (new system state) deliverables from existing (previous system state) deliverables, according to some predetermined dependency rules,
353
A. Identified problem or opportunity
B. Specified requirements
• Broad project plan
• Defined project schedule and budget
notations are used 14. At the automated end, task-based methods must find tools that match their approach, techniques, and notation. The deliverable concept treats tool, technique, notation, and sequence as independent variables, which allows greater flexibility.
• Proposed business environment description
BRIEF ILLUSTRATION
• Actual or envisaged business environment description • Broad statement of data or information required
• Detailed specification of data/information requirements
• Business processes description
• Functional model
• Process/information relationship model
D. Commissioned system • Performance monitors • Department work practices in place • Production databases
• Detailed data model • Service level agreement
C. Designed solution • Updated project schedule and budget • Defined environment • Database specifications
• Position/duty statements
• Packaged or programmed application software
• Data dictionary
• New manual procedures
• Maintenance requests
• Data dictionary Performance predictions
Figure 6. tions
Illustrative system state/deliverable associa-
is the essence of system development. The development process is controlled through deliverable definition without introducing unnecessary rigidity. The deliverable concept offers more flexibility than the more usual system-development task. Task-based methodologies focus on the 'how' of systems development and not the 'what' and lead to counter-productive 'boxology' arguments. A deliverable-based approach focuses on the 'what' and treats the 'how' as an independent variable. The system-development task fuses information and form (e.g., it will require the production of an entity-relationship model). The concept of deliverable as used in the model is form independent. Form is a deliverable attribute. Users assign attribute values. The deliverable's information content identifies it as an entity (e.g., data model). The deliverable entity has attributes (e.g., form, notation). The user defines the set of permitted attribute values (e.g., 'form' value is 'relational', 'notation' value is '1 :M') as separate steps. This distinction between the all-consuming task and the more independent deliverable is important for both human and technical reasons. At the human end, task-based models force the developers to focus on notation issues rather than content. As they move through the problem domain they may have to alter their mental model of the problem as different, and often conflicting,
354
It is impossible to illustrate all aspects of the model within the confines of this paper. To demonstrate the model's potential, however, it is as well to attempt to illustrate one aspect. The aspect illustrated is its versatility with regard to development sequence. The life-cycle debate opened up the question of development sequence. Rather than come down in favour of one sequence or another, the model can support any sequence pattern. Assume that an organization is using the model to mangage system development. In setting up its version of the model it chose to view system evolution in three states, namely, planned, developed, and operational. Figure 7 shows a part of that organization's agreed map of system state to deliverable associations. The model, as interpreted by this organization, can be used to manage system-development work. For the purpose of illustration, one aspect is concentrated on, namely, development sequence. Development sequence is set by establishing the dependency relationships between deliverables. Two constrasting sequence paths can be diagrammatically represented through the same map. The first represents a situation where a system is being developed 'top-down' from a requirements specification (see Figure 8). The second represents the development of a system from an available package (see Figure 9). This is a 'bottom-up' situation. The task is to determine whether an existing set of software can satisfy requirements that, in this instance, have not yet been determined. The model's versatility enables it to be used to manage both processes. CONCLUSION The model as described here embraces three main concepts - system evolution, system states, and develop-
Planned
Identified opportunity
Developed
system ~
Specified
Operational
system
Designed
Commissioned
Change options
Future context description
requirements -~_ solution system or p r o b l ~ . . . ~ 1 ~ --~ ~-'~-~
Clarified project
Present context description~
Management/ ~ Performonce~ Function deliverobles/ ldeliverobles ~ a b l e s Environment Data/information Behoviour deliverables deliverables deliverables Figure 7.
Partial view of state~deliverable map
information and software technology
Planned __ a - ~ Developed system system
Identified opportunity - or problem
Specified c -~ requirements jJ f d/ Clarified b=~ Present project ~ _ context -~-~-~.~descriptio n k~
Operational system
Designed solution
Commissioned system
, Change t - - ~ opt ions
Future context description
Mono'ogement , Per~ormoence--~ - - ' ~ Function deliverobles "=-J-- detiverobles / deliverables
Environment deliverables
Data/information deliverobles
/
Behoviour deliverobles
Identified opportunity or problem
Developed system
Operational system
Specified .._ o_Designed requirements solution
Clarified project. J\ Management deliverobles
L J Environment deliverobles
Present context description
Commissioned system
Change Future options-E- c - context
Performance deliverobles
~e Data/information deliverobles
\d
description
F ction deliverobles l
g
Behaviour deliverobles
I
Figure 8. System development from known requirements. A "planned' system is to become a 'developed' one (a). First the focal system is more clearly identified (b). Then the focal system evolves into a 'specified requirements' ( c) and the focal system's boundaries are clearly delineated (d). Next deliverables that represent the present situation are produced, namely, present functions (e ), present data and information (f), present system behaviour or logic (g ), present environment (h), and present performance (i). Project management-related deliverables are defined (i). Present system context deliverbles are established (k). Finally, the various change options are developed (l).
ment deliverables. It is a meta-model of the systemdevelopment process that can be used: to understand the system-development process • as a foundation for a system-development environment • as a framework for integrating known methods • as the underlying model for an automated systemdevelopment support tool •
As the degree of ambition as regards application increases so does the degree of complexity. Once the meta-model is considered as a foundation for a system-development environment, such matters as version control and development object repositories need to be addressed. However, such matters are beyond the scope of this paper. Suffice it to say that this complexity will necessitate implementing the meta-model through an appropriate automated facility. As the 1990s approach, organizations will need meta-models of the system-development process like the one described here if they are to protect their informationsystems investment. The system-development models for the 1990s will be different from those of today. They will still be used as tools to manage and control the system-development process. However, they will need to be: • flexible to cope with a wider range of system application type
vol 31 no 7 september 1989
Planned system
Figure 9. System development from available package. A pre-written software package is found out about (a). Will it satisfy future needs? (b). How does it compare with other alternatives? (c). What system functions does it support? (d). Does it support the data~information requirements? (e). Does it provide for rules of logic? (f). Will it satisfy performance requirements ? (g). Will it work in the environment? (h). Produce the necessary project management deliverables to take the project to the next stage ( i). Identify thefocal system-development project (j ). • adaptable to allow for new methods and automated tools • able to facilitate system evolution through enhancement • consistent across end-user and professional development projects for human resource mobility • simple, to be understood Work to date with the model encourages the belief that it is a meta-model for the 1990s. It provides a broadly based, integrated, flexible yet robust framework for linking a variety of system-development models to provide unique evolution strategies. Its particular strength lies in its separation of process outcome and process method. It uses the process outcome to control and manage system evolution. It allows system developers to choose an appropriate process method thereby achieving flexibility.
REFERENCES I Olle, T W, Sol, H G and Verrijn-Stuart, A A (eds) Information system design methodologies: a comparative review North Holland, Amsterdam, The Netherlands (1982)
2 0 l l e , T W, Sol, H G and Verrijn-Stuart, A A Information system design methodologies: the practice North Holland, Amsterdam, The Netherlands (1986) 3 0 l l e , T W, Sol, H G and Tully, C (eds) Information systems design methodologies: afeature analysis North Holland, Amsterdam, The Netherlands (1983) 4 Longworth, G 'Specification and development of
355
5
6
7 8 9 10
software systems,' Technical paper for Task SD7 (joint research programme between GMD and NCC sponsored by the Commission of European Communities and national governments, working draft) (1985) MacDonald, I G 'Automating information engineering' Inf. Soft. Technol. Vo130 No 6 (July/August 1988) pp 393-400 Glasson, B C 'A model of computer-based information systems evolution as a basis for an integrated project support environment' D. Phil Thesis Department of Computer Science, University of York, UK (1986) Blum, B'The life-cycle-adebate over alternate models; Soft. Eng. Notes Vol 7 No 4 (1982) pp 18-20 Gladden, G R 'Stop the life-cycle, I want to get off Soft. Eng. Notes Vol 7 No 2 (1982) pp 35-39 Hall, P A V 'In defence of life-cycles' Soft Eng. Notes Vol 7 No 3 (1982) p 23 McCracken, D D and Jackson, M A 'A minority dissenting position' in Cotterman, W W e t al. (eds)
356
11
12
13
14
Systems analysis and design: a foundation for the 1980's North Holland, Amsterdam, The Netherlands (1981) pp 551 553 Rock-Evans, R A systems development and enhancement cycle for the 1990's (Seminar notes) DCE Ltd, Woking, UK (1988) Stamper, R 'Collateral systems' in Lecture notes on system methodology London School of Economics, London, UK (1983) Glasson, B C 'Supporting controlled variety in system development environments' in Olle, T W, Sol, H G and Verrijn-Stuart, A A (eds) Information system design methodologies: the practice North Holland, Amsterdam, The Netherlands (1986) pp 271-288 Tully, C J 'Towards a conceptual framework for system methodologies' in System development methodologies. Proc. IFIP TC2 Conf. System Description Methodologies (Kecskemet, Hungary, May 1983) North Holland, Amsterdam, The Netherlands (1985)
information and software technology
A meta-model of system development is described. The metamodel uses three main concepts: system evolution, system states, and development deliverables. The meta-model sees information systems evolving as they are developed and used. It uses system states to describe and control that evolutionary process. It uses deliverables, which are simply the outcomes of system-development work, to define a system as being in a particular state of evolution. Creating new deliverables causes a change of state. The meta-model can be used to build project-specific development strategies as an alternative to imposing a standard methodologybased approach. computer-based in/ormation system-development models, methodologies, support environments, evolution, system states, deliverables
Methods for the development of computer-based information systems have received considerable attention recently. The I F I P W G 8.1 CRIS Series (comparative review of information systems) is illustrative of the many attempts being made world wide to understand existing methods or to develop new ones t 3. As a result of this attention, there is a plethora of methods available to today's system developer (e.g., Longworth 4 identifies over 300 methods). This suggests one of two things: either there is some ideal method awaiting discovery or the method will always be contingent on the problem. The possibility of there being one ideal method for all problems is a myth. The reality is that each situation requires its own solution strategy. The immediate need is not for new methods. More versatile system-development approaches are needed that: • allow access to the full repertoire of known methods • provide a mechanism that enables a subset of those methods to be linked easily into an appropriate solution strategy for any given problem • can adapt as new problems and methods emerge Versatile approaches like these must be based on a meta-model of the system-development process that is flexible yet robust. The meta-model must address systems evolution in the broadest sense covering planning, development, and use and addressing evolution processes, management, and technical matters. It will be a meta-
School of Information Systems,Curtin Universityof Technology, Kent Street, Bentley WA 6102, Australia
vol 31 no 7 september 1989
model because it will incorporate and use other models. It needs to be flexible to have wide application. It needs to be robust as it will underpin each solution strategy. The author agrees with Macdonald 5, who argues that a single coherent meta-model is an essential component of any automated development environment. This paper introduces one such meta-model. This meta-model (called here the 'model' for simplicity) is built on three main concepts and a number of supporting ones. The model is an early outcome of research into the development of an automated system-development support environment 6. This paper outlines the model; explains the three main concepts it uses, namely, system evolution, system states, and development deliverables; and briefly illustrates its application. MODEL The model treats all systems as being in a state of evolution at any moment. The particular state of evolution is determined by the existence or otherwise of an agreed set of entities called 'deliverables'. Systems evolve through system-development effort. System development means creating new deliverables from previous ones according to some previously defined relationships. System development is controlled by defining the essential deliverabledependency relationships and any essential attribute values (e.g., owner or method). The process is kept flexible by allowing the model's user to set the other attribute values (e.g., form or notation) and to set the nonessential relationships. The model is represented diagrammatically in Figure 1. It is best explained through a discussion of the underlying concepts and a brief illustration of its use. SYSTEM
EVOLUTION
Information systems evolve. They exist in some form. They are developed into another. They are used and then developed further and so on until they are replaced. Information-system evolution is a fundamental concept of the model. The model assumes that the information system will change, it does not presuppose, however, what the pattern of change might be. That is, it makes no assumption as to what events might occur to bring about the change, what outcomes might result from it, the sequence of those events, or the rate of change. Attempts by methodologies to make such presumptions have led to much argument, the 'life-cycle' debate being a case in point 7 lo.
0950-5849/89/070351-06$3.00 (~-~1989 Butterworth & Co (Publishers) Ltd
351
State I
State 2
State 3 . . . . . . . . . . . . . . . . . . . . . . . . .
State n
Deliverable 2.1
Deliverable 2 . 2 .................... Deliverable 2. n
Deliverable 2.2.1
Deliverable 2 . 2 . 2 ............... Deliverable 2 . 2 . n
Principal deliverable relationships Deliverable 'defines' state Deliverable 'depends on' deliverable Deliverable 'contains' subdeliverable Principal deliverable attributes Form (notation, language) Owner (actioner, portic ipont ) Method (tool, technique)
Figure 1.
State B
Identified problem or opportunity
Specified requirements
State D
State C
Commissioned system
Designed solution
Figure 2. Possible set of system states
Model of system evolution
The model requires the user to define a change pattern or sequence before system development begins. However, it imposes no preconditions as to what that pattern might be. If the circumstances call for (say) a life-cycle approach, the model can accommodate it. If, in different circumstances, (say) a version of prototyping is deemed appropriate, the model can handle that as well. Furthermore, it can handle mixed approaches (e.g., prototyping to clarify user requirements followed by life-cycle to design, build, and implement). The model accepts that systems are dynamic without presupposing a particular change pattern. This is most important if different methods are to be linked to solve a particular problem (e.g., as is advocated for many CASE tools).
SYSTEM STATES If information systems evolve, then at any moment such a system is in a given state of evolution. The model calls these 'system states.' There may be any number of system-state instances during an information system's evolutionary cycle. To make the concept useful, the model imposes some structure. The model's structure requires the system developer or project planner 'user' to recognise some finite set of system states. The user defines a version of the model in terms of this recognised (by them) set of system states. That model version is used to build particular system-development solution strategies. The user might choose to recognise four states as shown in Figure 2. These may be decomposed for convenience into more detailed lower substates. An illustrative decomposition of one of the user's recognised states into a recognised (by that user) set of substates is shown in Figure 3. Decomposition continues insofar as it is helpful. The model allows this hypothetical user to choose to view information-system evolution in these terms. This is important. Different views of system evolution might be equally valid in different situations. The model defines system development as a transition path through a set of system states. It allows the users to define their own view of that evolutionary process, however, by having them define their own set of recognised system states.
352
State A
State B Slmeified r e q u i r e m e n t s B.a.
B.b.
A clarified and reaffirmed project
Present context description
B.d
B.c
Future context description
Change alternatives option descriptions
Figure 3. Illustrative decomposition of 'specified requirements" state As an illustration, an alternative system state set is shown in Figure 4. The criterion used in determining the number of, and descriptors for, system states is simple. The question is asked, 'Will this view of system evolution help people in this particular organization understand and manage the development of this particular system?'. The set of system states chosen allows: • the represention of a static view of the system evolution process • the description of a system as being in a particular state of evolution The agreed set of system states provides an organization with a common 'snapshot' view of the system-development process. If information systems evolve, however, the users must also have a way of representing that change process; in other words, a way of representing the dynamics of systems evolution. The model addresses the dynamics of system evolution in the same way it addresses the static aspects. It provides a flexible structure. System evolution means changing the focal system from one system state to another without unnecessarily disturbing its hierarchical or collateral relationships (the terms focal systems and collateral relationships are taken from Stamper12). The evolutionary transition path between states, however, is also situation dependent. The model requires
information and software technology
4.2 Packagedsolution
4.1 New applications and I
II
Strategy
Tactical plan
XII
III
Needing maintenance
System study details
XI
IV
System review
External design
X
V
Production
Technical design
IX
VI
Implemented
Procured resources
VIII
VII
major enhancements A
D4
4.3
Constructed
A
,.B
C
4.4 Minor enhancements
Conversions
A
B
De - ~ ' ~ ' ~ C
A
D=
B
=C
4.6 Prototype (requkements)
4.5 Prototype (design)
=B
0 4
Installed
~B
Figure 5.
l
~.C
Illustrative state transition paths
Figure 4. Alternative view of system states (adapted from Rock-Evans 11) the user to define a transition path to manage system development, that is, to choose an appropriate development sequence for the particular system-development project. The user might define a transition path within and between the agreed set of system states. The model provides a structure to enable development sequence definition. It does not impose a general view as to what that development sequence might be. There is no one preferred system-development sequence. There are a number of likely system-development scenarios, each requiring a different development sequence, as illustrated in Figure 5. The model can accommodate these scenarios and more. The discussion so far has emphasized the need for the model to accommodate a wide range of system-development views. However, this flexibility needs to be controlled13. Control is achieved by determining a particular solution strategy for a particular situation. The solution strategy must: • define an appropriate set of system states and substates to describe that system-development situation • define the process of system evolution as a series of sequenced state changes Now the last of the three main model concepts, namely, the development deliverable, is discussed. DEVELOPMENT
DELIVERABLE
A deliverable is simply the tangible outcome of systemdevelopment work (e.g., screen layout, coded module,
vol 31 no 7 september 1989
interview report, test data, or maintenance request). The model uses the deliverable concept in two ways. First, it uses deliverables to define more precisely the agreed system states. Second, it uses the dependency relationships between deliverables to define the system-development process. System states are comprised of, and defined by, a set of deliverables. The potential set of system-development deliverables is considerable. Work to date indicates a number in the order of 100013. Each system-development problem will use some subset. The user must define that subset, and the associations between its members, in each system-development situation. Again the choice lies with the user. However, the model allows organizations to build 'templates' of project types to assist in this process. An illustration of a system state/deliverable association at the highest level of decomposition is shown in Figure 6. The user may decompose deliverables into subdeliverables to the extent that is helpful. Once established, these associations define each system state more precisely. They determine the particular state of evolution of any given system. That is, it is the existence or otherwise of a given set of deliverables that determines a given system's evolutionary state. The first use of deliverables then is to define the agreed set of system states. The second, and more important, use of the deliverable concept is within the development process itself. Changing a system from one system state (with one set of deliverables) to another (with its set of deliverables) is system development. Creating output (new system state) deliverables from existing (previous system state) deliverables, according to some predetermined dependency rules,
353
A. Identified problem or opportunity
B. Specified requirements
• Broad project plan
• Defined project schedule and budget
notations are used 14. At the automated end, task-based methods must find tools that match their approach, techniques, and notation. The deliverable concept treats tool, technique, notation, and sequence as independent variables, which allows greater flexibility.
• Proposed business environment description
BRIEF ILLUSTRATION
• Actual or envisaged business environment description • Broad statement of data or information required
• Detailed specification of data/information requirements
• Business processes description
• Functional model
• Process/information relationship model
D. Commissioned system • Performance monitors • Department work practices in place • Production databases
• Detailed data model • Service level agreement
C. Designed solution • Updated project schedule and budget • Defined environment • Database specifications
• Position/duty statements
• Packaged or programmed application software
• Data dictionary
• New manual procedures
• Maintenance requests
• Data dictionary Performance predictions
Figure 6. tions
Illustrative system state/deliverable associa-
is the essence of system development. The development process is controlled through deliverable definition without introducing unnecessary rigidity. The deliverable concept offers more flexibility than the more usual system-development task. Task-based methodologies focus on the 'how' of systems development and not the 'what' and lead to counter-productive 'boxology' arguments. A deliverable-based approach focuses on the 'what' and treats the 'how' as an independent variable. The system-development task fuses information and form (e.g., it will require the production of an entity-relationship model). The concept of deliverable as used in the model is form independent. Form is a deliverable attribute. Users assign attribute values. The deliverable's information content identifies it as an entity (e.g., data model). The deliverable entity has attributes (e.g., form, notation). The user defines the set of permitted attribute values (e.g., 'form' value is 'relational', 'notation' value is '1 :M') as separate steps. This distinction between the all-consuming task and the more independent deliverable is important for both human and technical reasons. At the human end, task-based models force the developers to focus on notation issues rather than content. As they move through the problem domain they may have to alter their mental model of the problem as different, and often conflicting,
354
It is impossible to illustrate all aspects of the model within the confines of this paper. To demonstrate the model's potential, however, it is as well to attempt to illustrate one aspect. The aspect illustrated is its versatility with regard to development sequence. The life-cycle debate opened up the question of development sequence. Rather than come down in favour of one sequence or another, the model can support any sequence pattern. Assume that an organization is using the model to mangage system development. In setting up its version of the model it chose to view system evolution in three states, namely, planned, developed, and operational. Figure 7 shows a part of that organization's agreed map of system state to deliverable associations. The model, as interpreted by this organization, can be used to manage system-development work. For the purpose of illustration, one aspect is concentrated on, namely, development sequence. Development sequence is set by establishing the dependency relationships between deliverables. Two constrasting sequence paths can be diagrammatically represented through the same map. The first represents a situation where a system is being developed 'top-down' from a requirements specification (see Figure 8). The second represents the development of a system from an available package (see Figure 9). This is a 'bottom-up' situation. The task is to determine whether an existing set of software can satisfy requirements that, in this instance, have not yet been determined. The model's versatility enables it to be used to manage both processes. CONCLUSION The model as described here embraces three main concepts - system evolution, system states, and develop-
Planned
Identified opportunity
Developed
system ~
Specified
Operational
system
Designed
Commissioned
Change options
Future context description
requirements -~_ solution system or p r o b l ~ . . . ~ 1 ~ --~ ~-'~-~
Clarified project
Present context description~
Management/ ~ Performonce~ Function deliverobles/ ldeliverobles ~ a b l e s Environment Data/information Behoviour deliverables deliverables deliverables Figure 7.
Partial view of state~deliverable map
information and software technology
Planned __ a - ~ Developed system system
Identified opportunity - or problem
Specified c -~ requirements jJ f d/ Clarified b=~ Present project ~ _ context -~-~-~.~descriptio n k~
Operational system
Designed solution
Commissioned system
, Change t - - ~ opt ions
Future context description
Mono'ogement , Per~ormoence--~ - - ' ~ Function deliverobles "=-J-- detiverobles / deliverables
Environment deliverables
Data/information deliverobles
/
Behoviour deliverobles
Identified opportunity or problem
Developed system
Operational system
Specified .._ o_Designed requirements solution
Clarified project. J\ Management deliverobles
L J Environment deliverobles
Present context description
Commissioned system
Change Future options-E- c - context
Performance deliverobles
~e Data/information deliverobles
\d
description
F ction deliverobles l
g
Behaviour deliverobles
I
Figure 8. System development from known requirements. A "planned' system is to become a 'developed' one (a). First the focal system is more clearly identified (b). Then the focal system evolves into a 'specified requirements' ( c) and the focal system's boundaries are clearly delineated (d). Next deliverables that represent the present situation are produced, namely, present functions (e ), present data and information (f), present system behaviour or logic (g ), present environment (h), and present performance (i). Project management-related deliverables are defined (i). Present system context deliverbles are established (k). Finally, the various change options are developed (l).
ment deliverables. It is a meta-model of the systemdevelopment process that can be used: to understand the system-development process • as a foundation for a system-development environment • as a framework for integrating known methods • as the underlying model for an automated systemdevelopment support tool •
As the degree of ambition as regards application increases so does the degree of complexity. Once the meta-model is considered as a foundation for a system-development environment, such matters as version control and development object repositories need to be addressed. However, such matters are beyond the scope of this paper. Suffice it to say that this complexity will necessitate implementing the meta-model through an appropriate automated facility. As the 1990s approach, organizations will need meta-models of the system-development process like the one described here if they are to protect their informationsystems investment. The system-development models for the 1990s will be different from those of today. They will still be used as tools to manage and control the system-development process. However, they will need to be: • flexible to cope with a wider range of system application type
vol 31 no 7 september 1989
Planned system
Figure 9. System development from available package. A pre-written software package is found out about (a). Will it satisfy future needs? (b). How does it compare with other alternatives? (c). What system functions does it support? (d). Does it support the data~information requirements? (e). Does it provide for rules of logic? (f). Will it satisfy performance requirements ? (g). Will it work in the environment? (h). Produce the necessary project management deliverables to take the project to the next stage ( i). Identify thefocal system-development project (j ). • adaptable to allow for new methods and automated tools • able to facilitate system evolution through enhancement • consistent across end-user and professional development projects for human resource mobility • simple, to be understood Work to date with the model encourages the belief that it is a meta-model for the 1990s. It provides a broadly based, integrated, flexible yet robust framework for linking a variety of system-development models to provide unique evolution strategies. Its particular strength lies in its separation of process outcome and process method. It uses the process outcome to control and manage system evolution. It allows system developers to choose an appropriate process method thereby achieving flexibility.
REFERENCES I Olle, T W, Sol, H G and Verrijn-Stuart, A A (eds) Information system design methodologies: a comparative review North Holland, Amsterdam, The Netherlands (1982)
2 0 l l e , T W, Sol, H G and Verrijn-Stuart, A A Information system design methodologies: the practice North Holland, Amsterdam, The Netherlands (1986) 3 0 l l e , T W, Sol, H G and Tully, C (eds) Information systems design methodologies: afeature analysis North Holland, Amsterdam, The Netherlands (1983) 4 Longworth, G 'Specification and development of
355
5
6
7 8 9 10
software systems,' Technical paper for Task SD7 (joint research programme between GMD and NCC sponsored by the Commission of European Communities and national governments, working draft) (1985) MacDonald, I G 'Automating information engineering' Inf. Soft. Technol. Vo130 No 6 (July/August 1988) pp 393-400 Glasson, B C 'A model of computer-based information systems evolution as a basis for an integrated project support environment' D. Phil Thesis Department of Computer Science, University of York, UK (1986) Blum, B'The life-cycle-adebate over alternate models; Soft. Eng. Notes Vol 7 No 4 (1982) pp 18-20 Gladden, G R 'Stop the life-cycle, I want to get off Soft. Eng. Notes Vol 7 No 2 (1982) pp 35-39 Hall, P A V 'In defence of life-cycles' Soft Eng. Notes Vol 7 No 3 (1982) p 23 McCracken, D D and Jackson, M A 'A minority dissenting position' in Cotterman, W W e t al. (eds)
356
11
12
13
14
Systems analysis and design: a foundation for the 1980's North Holland, Amsterdam, The Netherlands (1981) pp 551 553 Rock-Evans, R A systems development and enhancement cycle for the 1990's (Seminar notes) DCE Ltd, Woking, UK (1988) Stamper, R 'Collateral systems' in Lecture notes on system methodology London School of Economics, London, UK (1983) Glasson, B C 'Supporting controlled variety in system development environments' in Olle, T W, Sol, H G and Verrijn-Stuart, A A (eds) Information system design methodologies: the practice North Holland, Amsterdam, The Netherlands (1986) pp 271-288 Tully, C J 'Towards a conceptual framework for system methodologies' in System development methodologies. Proc. IFIP TC2 Conf. System Description Methodologies (Kecskemet, Hungary, May 1983) North Holland, Amsterdam, The Netherlands (1985)
information and software technology