- Email: [email protected]
Towards a new development framework
Traditionalsoftwaredevelopmenttechniquesare out of date as far as modern applicationsare concerned.A workingparty from the BritishComputer Societyhas been lookingat new frameworksfor analysisand design
Towardsa new developmentframework by KEITH HINDLE ave you ever tried driving through some unfamiliar city, only to find yourself lost because your streetmap is out of date? Although it is obvious that accurate maps are necessary if you are to get to your destination on time, many installations still seem to be developing their new applications using the equivalent of out of date maps. The conventional project framework is more likely to hinder rather than help their work. Systems are still being built using methods and techniques originally invented for batch processing, standalone applications. New techniques are appearing in response to the rapid changes in computing. For example, the increasing use of databases has resulted in the development of database design techniques, whilst the much-publicized structured methodologies are introducing more rigour into the analysis and design procedures. Yet, to implement these new techniques requires more than just education and a determination to overcome inertia. There is a fundamental incompat-
H
Abstract: The basic design of computer systemshas shifted radicallyfrom batchprocessing, standalone applications to complex, integrated information systems, based on database technology. The system development techniques, however, have failed to keep pace with these rapid changes. This article examines the changing nature of computer applications and their corresponding analysis and design approaches, commenting on the limitationsof the latter. It outlines the work undertaken by a BCS working party in formulating a framework which accommodates both current and future developments.
Keith Hindle is a senior lecturer at North Staffordshire Polytechnic and is a member of the BCS information systems analysis and design working party.
0011-684x/84/01000&05$03.00
0
Life-cycle approach to systems development In the early 197Os, the job of the systems analyst been to be formalized. Up till then, systems analysis was little more than a random collection of techniques, such as interviewing and file design. It began to be recognized, however, that development projects had a uniform structure, consisting of
Systemsare still being built usingmethods and techniquesoriginallyinventedfor batch processing,standaloneapplications
Keywords: systemsdevelopment, system design, database.
6
ability between the new techniques and the old project framework which is forcing us to rethink how the development project should be organized. This article outlines the result of such a rethink by the British Computer Society information systems analysis and design working party (ISADWP). The development framework it proposes is designed to accommodate both current and future techniques. To establish the need for a new framework it is necessary to examine the conventional approach, showing not only its inherent limitations, but also why it is incapable of accommodating the new techniques.
1984 Butterworth
&Co (Publishers)
Ltd.
data processing
policy the study, design, development and operation phases, each of which could be further broken down into more detailed tasks and activities, see Figure 1. Although there might be some overlap, these phases and tasks were usually thought of as being carried out sequentially. This concept of the development life cycle both clarified the work from the systems analyst’s point of view, and allowed the use of project planning and control techniques. These phases have been refined in the light of experience and are now accepted working practice by many system developers. Whilst the traditional life-cycle approach has proved useful in the past, recent advances are making it inappropriate. The limitations of the old approach may be summarized as follows: l
l
l
individual projects are considered in isolation the available analysis and design methods are incapable of handling large development projects the sequencing of the phases is rigid and does not allow for itera-
STUDY (Detailed investigation and analysis)
DESIGN (Logical and physical)
DEVELOPMENT (Program, files and procedures)
J, OPERATION Figure I. Conventional approach .
~0126 no 1
life-cycle
januaryifebruary
1984
Database design is much more than file design ‘writ large’ * the development work is to be carried out by computer specialists, who are unable to involve the users sufficiently.
Shifts in the scope and nature of appIications The development of isolated applications has been common in the past, but is likely to be less so in the future with increased emphasis on databases and integrated data processing. Standalone applications cause problems when data is duplicated, or when data from several, probably incompatible, systems are to be brought together. The use of databases aims to overcome such problems, but introduces difficulties of its own; if a database is to be used by several applications, how, when and by whom should it be designed. When data is co be shared by many applications, database design cannot be performed by the designer of a particular application. Many compromises and tradeoffs will have to be made during the design process to reflect the different requirements of the many users. As a result, database design is much more rhan file design ‘writ large’. The move towards database systems is paralleled by a greater use of data communications facilities. In both cases, expensive and technically complex facilities are being shared amongst several applications. Thus, planning must be at a higher level than the individual application, if the appropriate database and communication facilities are to be obtained. This
problem is highlighted by the availability of ever-cheaper microcomputer hardware and packages. Without proper planning, many end users will acquire their own machines, resulting in a profusion of incompatible hardware and applications.
Inappropriate anaiysis and design methods
The life-cycle approach evolved handin-hand with the traditional analysis and design techniques such as factflow-charting and gridfinding, charts. The analyst, whilst advocating the use of the computer for everyone else in the organization, did not use it in his own work. The available techniques might just have got by on standalone applications, although users were often dissatisfied with the resulting systems. As rhe applications became larger, the techniques were unable to handle the complexity and sheer volume of detail, leading to errors, omissions and inconsistencies in the final design. In addition the techniques relied on experienced practitioners. The quality of the work was very variable. Whereas the best systems analysts could produce very workabie systems, there were many examples of systems which failed to work because of poor analysis and design. The resulting maintenance work is only now being recognized as a major problem.
Constraints approach
of the life-cycle
The phased approach, which is at the heart of the project life cycle, results from management’s dislike for committing resources to a project without retaining some control. So, instead of allocating money for the whole project, it is broken down into discrete and money is allocated a phases, phase at a time. Management has the right to check progress at the end of each phase and, if satisfied, releases resources for the next. This idea of
7
‘creeping commitment’ is obviously sensible from the investor’s point of view. Moreover, it aids project planning and control by splitting a large job down into smaller units which are easier to understand and control. The main problem with this approach, however, is that the phases are independent units of work, carried out in a strict sequence. Thus, analysis precedes design and must be completed before design can start. In practice, however, problems occur in later phases which require the reworking of earlier ones. Such goingson are not recognized by the life-cycle
cess, but they were consistently excluded. The four problem areas outlined above result from the inadequacies of the traditional approach, and are becoming increasingly obvious. Attempts to revive this approach by the introduction of new techniques are doomed to failure, not because the techniques are at fault, but because they cannot be integrated into the life cycle. Growing use is being made of database design methods, structured systems analysis and design, prototyping and various forms of planning. System developers face overwhelming
By formalizingthe developmentwork, lessrelianceis placedon the experience of the staff approach. The situation is more difficult in those types of applications, such as management information systems, where user requirements are very difficult to identify initially. Development specialists
by computer
In traditional development project, emphasis was placed on the technical aspects of systems analysis and design, for which only experienced computer professionals were qualified. Unfortunately, few computer professionals were also experienced in the user’s business and the resulting systems were often difficult to use, did not do all the right things, or did some things incorrectly. Users and developers were unable to communicate effectively because they spoke different languages; even the pictures that the developers drew were ineffective. The situation was made worse by the users’ increasing awareness of the potential of the computer. They knew that the computer could help them, they wanted to contribute to the development pro-
8
difficulties when they try to combine these techniques with the traditional approach. Database-oriented
design
A major reason for the development of databases is that the basic data of an organization is relatively stable. The data which is of interest to the organization does not vary, although the applications which use that data can and do change in order to satisfy user requirements. Instead of designing the files for each application, it is more sensible to design the overall database first. Although individual applications will change over time, total maintenance costs will be kept down if the database does not change radically. The first stage of database design then is to define the basic data of the organization. This should be done without any consideration of the type of database management system that will be used (and may be a very useful exercise even if no database is to be designed). The designer builds up a picture of the relevant parts of the real
world by identifying entities which are important, such as customers and orders, and their relationships, e.g. a customer places an order. The resuhing diagram is called a conceptual or logical data model. As it is free of computer details, it can be checked by users to ensure its completeness and accuracy. The second stage is to convert this conceptual model into a database definition for the particular database software. This physical data model is the database schema. Thus, the technical design is separated from the logical design. When should the database design work be carried out? The preliminary data analysis is independent of individual applications and should precede detailed application design. On the other hand, detailed physical design of the database depends on information such as transaction volumes and required response times, so must be integrated with individual application development. The project life cycle does not allow for this kind of scheduling, nor does it allow for the evolution of the database, which must change and grow as new applications are added. Thus, database design is not a once-off exercise but a continuing task. Structured systems design
analysis and
The term ‘structured systems analysis and design’ covers a wide variety of commercial and other offerings, which formalize in some way or other the analysis and design process. Their usual aims are to ensure that the resulting systems are appropriate, complete and accurate, thus, satisfying user requirements and requiring less maintenance. This is achieved by facilitating better communication between users and developers and providing tools, techniques and guidelines for analysis and design, such as data modelling, functional analysis and data dictionaries. By formalizing the development
dataprocessing
..I
Version
ing activities must relate to the basic objectives of the organization. These plans must be periodically updated. Lower level activities must be planned, monitored and controlled. Such
I Version 2
Version 3 -
Figure 2. Prototyping -- an interactive approach. work, less reliance is placed on the experience of the staff. The great differences between the various structured offerings cause problems for installations choosing a development methodology. Several of the structured methods are enhancements of the older, established database design methods, and consist of data analysis with additional techniques to cover the processing aspects, known as functional or process analysis. There may be an underlying assumption that these particular offerings are aimed at data-sharing applications, normally using a database. On the other hand, !some of the best known structured methods are based upon the use of data flow diagrams (DFDS) and are predominantly process-oriented. Some methodologies offer a ‘tool-kit’ approach, providing a set of techniques such as DFDS and structured walkthrou~hs, which can be used by the systems analyst as and when he/she wishes, whilst others offer a much more rigidly defined methodology in which every step in the development process is spelt out in detail. The correspondence between the phases of a structured methodology and those of the traditional life cycle are often quite blurred. There are differences in the phases covered by the various methodologies. Many only cover analysis and design, whereas some extend to implementation and others include some form of initial long-term planning. Structured meth-
~0126 no 1 january!february
1984
ods introduce new tasks and phases. The terminology also varies considerably; with the structured methodologies, analysis becomes very important and may include much of the traditional approach’s logical system design.
Some types of planning are in conflict with the life-cycle approach to systems development
Prototyping Prototyping means development by repeated refinement of a trial version of a system, see Figure 2. In many situations, users cannot specify their requirements in full detail. So the analyst, in conjunction with the user, produces a limited version of the system in a few days or weeks. The user tries this out and suggests improvements and enhancements for the next version. Refinement continues until the user’s requirements are satisfied. The point about prototyping is that analysis, design and implementation are not separate phases. Instead, the user and the development work together, analysing, designing and implementing. The user involvement ensures an appropriate system. The contrast with the traditional life cycle could not be greater.
Planning Planning of computer developments is required at several different levels, especially with the introduction of organization-wide systems, built around complex databases and consisting of many integrated applications. At the highest level, data process-
planning and control, not being an integral part of the life cycle, may have to be ‘bolted-on’. Some types of planning, however, are in conflict with the life-cycle approach. Thus, it may be unnecessary to check out the feasibility of an individual application when it is part of a larger, integrated development, the feasibility of which has previously been determined at a higher level. Incompatabilities in the four areas listed are causing real problems, as the new techniques become increasingly widespread, forcing the system developers to take stock of the traditional approach. The information systems analysis and design working party (ISADWP), a subgroup of the KS database specialist group, was set up specifically to propose a framework for the development of information systems, regardless of their size or complexity or the development techniques employed. In trying to accommodate all the new techniques and methods, the ISADWP came to the conclusion that the phased, life cycle approach was not suitable. A radical rethink was required.
* production of reports Business strategic planning
‘7
The corresponding resources include: * end users l business systems analysts l computer facilities, for the computer-based data dictionary
Information systems strategic planning
~,
~,
*...
,~,
Detolled planning for phases
Figure 3. Hierarchy
of plans.
Hierarchy of plans The new approach does not eliminate the individual activities such as analysis and design, but rather the strict sequencing of phases of the life cycle. The approach emphasises the wellestablished management cycle of planning, monitoring and control. Moreover, a complex activity such as the development of information systems implies a hierarchy of plans.
Within a particular task, the sequence in which activities are carried out will vary. As well as the conventional linear sequence, the current activity may be repeated until a satisfactory result is obtained, or previous activities or tasks may be repeated. Feasibility also changes. No longer is it evaluated once only at the beginning of a project; rather, it becomes a check to be carried out whenever a decision is to be made. Thus, a
The Journal is an interim document. Much work remainsto be done At the highest levels within an organization, there must be a close link between the computing strategy and the overall aims of the organization. Senior management must define the organization-wide objectives in a business strategic plan. The implications of this for computing are expressed at a lower level in the form of an information system strategic plan, only one current version of which will be required per organization. Under this single umbrella, there will be individual plans for each information system, referred to as the ~nfo~~ti~ system tactical plan. Finally, there will be the detailed plans for each task within the development projects, see Figure 3.
10
feasibility check can be made at different levels, by performing a little of various lower-level activities. The ISADWP defined the tasks to be carried out in each development phase. They developed a uniform structure for describing the phases, listing information under objectives of the phase, prerequisites, task list and descriptions, product list and descriptions, resources, techniques and tools. For example, the task list for the analysis phase includes: * 0 0 0
data analysis functional analysis requirements analysis and completeness checking
consistency
The same uniform method is used to describe the user design and technical design phases, as well as the various levels of planning. The proposed framework accommodates both the established and new analysis and design techniques. The ISADWP is now more than halfway through its planned life of three years. Sufficient progress has been made to produce a Journal of ~~e~op~~t, to be published before the end of the year, which describes the proposed framework in detail. The Journal will allow the working party: to report back to its parent, the database specialist group, on what has been achieved so far, to disseminate its ideas and receive feedback from practitioners and to form a base to which changes can be made as a result of future work. In the light of this, the members of the working party welcome comment, criticism and especially future assistance from everyone interested in the subject. The Journal is an interim document. Much work remains to be done; for example, no detailed consideration has yet been given to the implementation phase. Furthermore, the ISADWP needs to answer a number of questions concerning the applicability of the proposed system, such as: how useful will the framework be to end users developing their own systems? will the framework facilitate the development of decision support and expert systems? •1 Department of Computing, North Staffordshire Polytechnic, Blackheath Stafford, UK. Tel: (0785) 53511.
Lane,
data processing
Towardsa new developmentframework by KEITH HINDLE ave you ever tried driving through some unfamiliar city, only to find yourself lost because your streetmap is out of date? Although it is obvious that accurate maps are necessary if you are to get to your destination on time, many installations still seem to be developing their new applications using the equivalent of out of date maps. The conventional project framework is more likely to hinder rather than help their work. Systems are still being built using methods and techniques originally invented for batch processing, standalone applications. New techniques are appearing in response to the rapid changes in computing. For example, the increasing use of databases has resulted in the development of database design techniques, whilst the much-publicized structured methodologies are introducing more rigour into the analysis and design procedures. Yet, to implement these new techniques requires more than just education and a determination to overcome inertia. There is a fundamental incompat-
H
Abstract: The basic design of computer systemshas shifted radicallyfrom batchprocessing, standalone applications to complex, integrated information systems, based on database technology. The system development techniques, however, have failed to keep pace with these rapid changes. This article examines the changing nature of computer applications and their corresponding analysis and design approaches, commenting on the limitationsof the latter. It outlines the work undertaken by a BCS working party in formulating a framework which accommodates both current and future developments.
Keith Hindle is a senior lecturer at North Staffordshire Polytechnic and is a member of the BCS information systems analysis and design working party.
0011-684x/84/01000&05$03.00
0
Life-cycle approach to systems development In the early 197Os, the job of the systems analyst been to be formalized. Up till then, systems analysis was little more than a random collection of techniques, such as interviewing and file design. It began to be recognized, however, that development projects had a uniform structure, consisting of
Systemsare still being built usingmethods and techniquesoriginallyinventedfor batch processing,standaloneapplications
Keywords: systemsdevelopment, system design, database.
6
ability between the new techniques and the old project framework which is forcing us to rethink how the development project should be organized. This article outlines the result of such a rethink by the British Computer Society information systems analysis and design working party (ISADWP). The development framework it proposes is designed to accommodate both current and future techniques. To establish the need for a new framework it is necessary to examine the conventional approach, showing not only its inherent limitations, but also why it is incapable of accommodating the new techniques.
1984 Butterworth
&Co (Publishers)
Ltd.
data processing
policy the study, design, development and operation phases, each of which could be further broken down into more detailed tasks and activities, see Figure 1. Although there might be some overlap, these phases and tasks were usually thought of as being carried out sequentially. This concept of the development life cycle both clarified the work from the systems analyst’s point of view, and allowed the use of project planning and control techniques. These phases have been refined in the light of experience and are now accepted working practice by many system developers. Whilst the traditional life-cycle approach has proved useful in the past, recent advances are making it inappropriate. The limitations of the old approach may be summarized as follows: l
l
l
individual projects are considered in isolation the available analysis and design methods are incapable of handling large development projects the sequencing of the phases is rigid and does not allow for itera-
STUDY (Detailed investigation and analysis)
DESIGN (Logical and physical)
DEVELOPMENT (Program, files and procedures)
J, OPERATION Figure I. Conventional approach .
~0126 no 1
life-cycle
januaryifebruary
1984
Database design is much more than file design ‘writ large’ * the development work is to be carried out by computer specialists, who are unable to involve the users sufficiently.
Shifts in the scope and nature of appIications The development of isolated applications has been common in the past, but is likely to be less so in the future with increased emphasis on databases and integrated data processing. Standalone applications cause problems when data is duplicated, or when data from several, probably incompatible, systems are to be brought together. The use of databases aims to overcome such problems, but introduces difficulties of its own; if a database is to be used by several applications, how, when and by whom should it be designed. When data is co be shared by many applications, database design cannot be performed by the designer of a particular application. Many compromises and tradeoffs will have to be made during the design process to reflect the different requirements of the many users. As a result, database design is much more rhan file design ‘writ large’. The move towards database systems is paralleled by a greater use of data communications facilities. In both cases, expensive and technically complex facilities are being shared amongst several applications. Thus, planning must be at a higher level than the individual application, if the appropriate database and communication facilities are to be obtained. This
problem is highlighted by the availability of ever-cheaper microcomputer hardware and packages. Without proper planning, many end users will acquire their own machines, resulting in a profusion of incompatible hardware and applications.
Inappropriate anaiysis and design methods
The life-cycle approach evolved handin-hand with the traditional analysis and design techniques such as factflow-charting and gridfinding, charts. The analyst, whilst advocating the use of the computer for everyone else in the organization, did not use it in his own work. The available techniques might just have got by on standalone applications, although users were often dissatisfied with the resulting systems. As rhe applications became larger, the techniques were unable to handle the complexity and sheer volume of detail, leading to errors, omissions and inconsistencies in the final design. In addition the techniques relied on experienced practitioners. The quality of the work was very variable. Whereas the best systems analysts could produce very workabie systems, there were many examples of systems which failed to work because of poor analysis and design. The resulting maintenance work is only now being recognized as a major problem.
Constraints approach
of the life-cycle
The phased approach, which is at the heart of the project life cycle, results from management’s dislike for committing resources to a project without retaining some control. So, instead of allocating money for the whole project, it is broken down into discrete and money is allocated a phases, phase at a time. Management has the right to check progress at the end of each phase and, if satisfied, releases resources for the next. This idea of
7
‘creeping commitment’ is obviously sensible from the investor’s point of view. Moreover, it aids project planning and control by splitting a large job down into smaller units which are easier to understand and control. The main problem with this approach, however, is that the phases are independent units of work, carried out in a strict sequence. Thus, analysis precedes design and must be completed before design can start. In practice, however, problems occur in later phases which require the reworking of earlier ones. Such goingson are not recognized by the life-cycle
cess, but they were consistently excluded. The four problem areas outlined above result from the inadequacies of the traditional approach, and are becoming increasingly obvious. Attempts to revive this approach by the introduction of new techniques are doomed to failure, not because the techniques are at fault, but because they cannot be integrated into the life cycle. Growing use is being made of database design methods, structured systems analysis and design, prototyping and various forms of planning. System developers face overwhelming
By formalizingthe developmentwork, lessrelianceis placedon the experience of the staff approach. The situation is more difficult in those types of applications, such as management information systems, where user requirements are very difficult to identify initially. Development specialists
by computer
In traditional development project, emphasis was placed on the technical aspects of systems analysis and design, for which only experienced computer professionals were qualified. Unfortunately, few computer professionals were also experienced in the user’s business and the resulting systems were often difficult to use, did not do all the right things, or did some things incorrectly. Users and developers were unable to communicate effectively because they spoke different languages; even the pictures that the developers drew were ineffective. The situation was made worse by the users’ increasing awareness of the potential of the computer. They knew that the computer could help them, they wanted to contribute to the development pro-
8
difficulties when they try to combine these techniques with the traditional approach. Database-oriented
design
A major reason for the development of databases is that the basic data of an organization is relatively stable. The data which is of interest to the organization does not vary, although the applications which use that data can and do change in order to satisfy user requirements. Instead of designing the files for each application, it is more sensible to design the overall database first. Although individual applications will change over time, total maintenance costs will be kept down if the database does not change radically. The first stage of database design then is to define the basic data of the organization. This should be done without any consideration of the type of database management system that will be used (and may be a very useful exercise even if no database is to be designed). The designer builds up a picture of the relevant parts of the real
world by identifying entities which are important, such as customers and orders, and their relationships, e.g. a customer places an order. The resuhing diagram is called a conceptual or logical data model. As it is free of computer details, it can be checked by users to ensure its completeness and accuracy. The second stage is to convert this conceptual model into a database definition for the particular database software. This physical data model is the database schema. Thus, the technical design is separated from the logical design. When should the database design work be carried out? The preliminary data analysis is independent of individual applications and should precede detailed application design. On the other hand, detailed physical design of the database depends on information such as transaction volumes and required response times, so must be integrated with individual application development. The project life cycle does not allow for this kind of scheduling, nor does it allow for the evolution of the database, which must change and grow as new applications are added. Thus, database design is not a once-off exercise but a continuing task. Structured systems design
analysis and
The term ‘structured systems analysis and design’ covers a wide variety of commercial and other offerings, which formalize in some way or other the analysis and design process. Their usual aims are to ensure that the resulting systems are appropriate, complete and accurate, thus, satisfying user requirements and requiring less maintenance. This is achieved by facilitating better communication between users and developers and providing tools, techniques and guidelines for analysis and design, such as data modelling, functional analysis and data dictionaries. By formalizing the development
dataprocessing
..I
Version
ing activities must relate to the basic objectives of the organization. These plans must be periodically updated. Lower level activities must be planned, monitored and controlled. Such
I Version 2
Version 3 -
Figure 2. Prototyping -- an interactive approach. work, less reliance is placed on the experience of the staff. The great differences between the various structured offerings cause problems for installations choosing a development methodology. Several of the structured methods are enhancements of the older, established database design methods, and consist of data analysis with additional techniques to cover the processing aspects, known as functional or process analysis. There may be an underlying assumption that these particular offerings are aimed at data-sharing applications, normally using a database. On the other hand, !some of the best known structured methods are based upon the use of data flow diagrams (DFDS) and are predominantly process-oriented. Some methodologies offer a ‘tool-kit’ approach, providing a set of techniques such as DFDS and structured walkthrou~hs, which can be used by the systems analyst as and when he/she wishes, whilst others offer a much more rigidly defined methodology in which every step in the development process is spelt out in detail. The correspondence between the phases of a structured methodology and those of the traditional life cycle are often quite blurred. There are differences in the phases covered by the various methodologies. Many only cover analysis and design, whereas some extend to implementation and others include some form of initial long-term planning. Structured meth-
~0126 no 1 january!february
1984
ods introduce new tasks and phases. The terminology also varies considerably; with the structured methodologies, analysis becomes very important and may include much of the traditional approach’s logical system design.
Some types of planning are in conflict with the life-cycle approach to systems development
Prototyping Prototyping means development by repeated refinement of a trial version of a system, see Figure 2. In many situations, users cannot specify their requirements in full detail. So the analyst, in conjunction with the user, produces a limited version of the system in a few days or weeks. The user tries this out and suggests improvements and enhancements for the next version. Refinement continues until the user’s requirements are satisfied. The point about prototyping is that analysis, design and implementation are not separate phases. Instead, the user and the development work together, analysing, designing and implementing. The user involvement ensures an appropriate system. The contrast with the traditional life cycle could not be greater.
Planning Planning of computer developments is required at several different levels, especially with the introduction of organization-wide systems, built around complex databases and consisting of many integrated applications. At the highest level, data process-
planning and control, not being an integral part of the life cycle, may have to be ‘bolted-on’. Some types of planning, however, are in conflict with the life-cycle approach. Thus, it may be unnecessary to check out the feasibility of an individual application when it is part of a larger, integrated development, the feasibility of which has previously been determined at a higher level. Incompatabilities in the four areas listed are causing real problems, as the new techniques become increasingly widespread, forcing the system developers to take stock of the traditional approach. The information systems analysis and design working party (ISADWP), a subgroup of the KS database specialist group, was set up specifically to propose a framework for the development of information systems, regardless of their size or complexity or the development techniques employed. In trying to accommodate all the new techniques and methods, the ISADWP came to the conclusion that the phased, life cycle approach was not suitable. A radical rethink was required.
* production of reports Business strategic planning
‘7
The corresponding resources include: * end users l business systems analysts l computer facilities, for the computer-based data dictionary
Information systems strategic planning
~,
~,
*...
,~,
Detolled planning for phases
Figure 3. Hierarchy
of plans.
Hierarchy of plans The new approach does not eliminate the individual activities such as analysis and design, but rather the strict sequencing of phases of the life cycle. The approach emphasises the wellestablished management cycle of planning, monitoring and control. Moreover, a complex activity such as the development of information systems implies a hierarchy of plans.
Within a particular task, the sequence in which activities are carried out will vary. As well as the conventional linear sequence, the current activity may be repeated until a satisfactory result is obtained, or previous activities or tasks may be repeated. Feasibility also changes. No longer is it evaluated once only at the beginning of a project; rather, it becomes a check to be carried out whenever a decision is to be made. Thus, a
The Journal is an interim document. Much work remainsto be done At the highest levels within an organization, there must be a close link between the computing strategy and the overall aims of the organization. Senior management must define the organization-wide objectives in a business strategic plan. The implications of this for computing are expressed at a lower level in the form of an information system strategic plan, only one current version of which will be required per organization. Under this single umbrella, there will be individual plans for each information system, referred to as the ~nfo~~ti~ system tactical plan. Finally, there will be the detailed plans for each task within the development projects, see Figure 3.
10
feasibility check can be made at different levels, by performing a little of various lower-level activities. The ISADWP defined the tasks to be carried out in each development phase. They developed a uniform structure for describing the phases, listing information under objectives of the phase, prerequisites, task list and descriptions, product list and descriptions, resources, techniques and tools. For example, the task list for the analysis phase includes: * 0 0 0
data analysis functional analysis requirements analysis and completeness checking
consistency
The same uniform method is used to describe the user design and technical design phases, as well as the various levels of planning. The proposed framework accommodates both the established and new analysis and design techniques. The ISADWP is now more than halfway through its planned life of three years. Sufficient progress has been made to produce a Journal of ~~e~op~~t, to be published before the end of the year, which describes the proposed framework in detail. The Journal will allow the working party: to report back to its parent, the database specialist group, on what has been achieved so far, to disseminate its ideas and receive feedback from practitioners and to form a base to which changes can be made as a result of future work. In the light of this, the members of the working party welcome comment, criticism and especially future assistance from everyone interested in the subject. The Journal is an interim document. Much work remains to be done; for example, no detailed consideration has yet been given to the implementation phase. Furthermore, the ISADWP needs to answer a number of questions concerning the applicability of the proposed system, such as: how useful will the framework be to end users developing their own systems? will the framework facilitate the development of decision support and expert systems? •1 Department of Computing, North Staffordshire Polytechnic, Blackheath Stafford, UK. Tel: (0785) 53511.
Lane,
data processing