Research in Methodologies
- Aims and Objectives
- Information Systems Failure
- Stable Corporate Data Structures
- Corporate Information Management Strategy
- Dynamic Business Activity
- Flexible Applications Development
- Influencing Factors
- Comparison and Critique of SSADM and DSDM
- SSADM4+
- Required Features
- Methodology Development
- Enabling Rapid Application DevelopmentAD
- Enabling End-User Systems Development
The aim of the research program is to develop a holistic methodology for information systems engineering based on a Corporate Information Management Strategy (CIMS).The intention is to realise the methodology by integrating a wide variety of contemporary approaches from the fields of business process re-engineering, strategic information systems planning, project management, socio-behavioural development, structured methodologies, the object oriented paradigm, rapid application development and end-user systems development.
Objectives
- To define the class of information systems for which the methodology is applicable and explain why such a methodology is required based on an analysis of information systems failure.
- To demonstrate that the majority of corporate data structures are fundamentally more stable and common across business areas than the majority of business processes and thus form a strong foundation for strategic information systems planning.
- To demonstrate the importance of adopting, a strategic, rigorous approach to the development of corporate data structures.
- To demonstrate the dynamism of the activities which organisations carry out in order to achieve their objectives.
- To demonstrate the importance of adopting a flexible, evolutionary approach to the development of applications which support and enable business processes.
- To review the following fields and identify the implications for the development of the methodology:-
- Business Process Re-Engineering,
- Socio-Behavioural Development,
- Structured Methodologies,
- Object Orientation,
- Rapid Application Development,
- End-User Systems Development.
- To document the features required of the methodology.
- To develop and illustrate the methodology.
- To describe how the methodology enables rapid application development.
- To describe how the methodology enables End-User Systems Development.
The objective of this section is to define the class of information systems for which the methodology is applicable and explain why such a methodology is required based on an analysis of information systems failure. Much of the work in this area will be based on the material in Sauer’s book entitled Information Systems Failure: A Case Study Approach (Sauer, 1995).
Stable Corporate Data Structures
Corporate Information Management Strategy
The objective of this section is to demonstrate the dynamism of the activities which organisations carry out in order to achieve their objectives.
Flexible Applications Development
The objective of this section is to demonstrate the importance of adopting a flexible, evolutionary approach to the development of applications which support and enable business activities.
Comparison and Critique of SSADM v4 and DSDM
The objective of this section is to document the features required of the methodology.
The framework should have the following aims :-
- Application for a wide variety of information systems;
- Facilitation of consistent and long term RAD (through data and software re-use)
- Effective development, facilitation and management of End-User Computing (EUC).
The objective of this section is to develop and illustrate the methodology.
Overview
Figure <> provides an overview of the proposed methodology. The subsequent sections provide more detailed descriptions of the phases of the methodology.
|
Figure <> Information Systems Engineering Methodology |
It should be noted that the remits of phases 2, 4 and 6 have to cut across any artificial project boundaries.
Corporate Data in Action
In this section the methodology is illustrated by using an example based on a hypothetical University environment. A common shortcoming of many methodologies is that they assume a greenfield site. The illustration will show how the methodology can be used in a more typical site, i.e. one in which there exists a confusing and sometimes conflicting variety of corporate, departmental and personal systems running on a variety of hardware and software platforms.
Scenario
Lecturers in a college are responsible for teaching modules and assessing the students taking the modules through a mixture of coursework and examination. The college has a central Student Administration System (SAS) which records data regarding which students are taking which modules.
The SAS holds data on the contributions that coursework and examination make to the final grade for the module but no detail concerning the number of courseworks and the format and structure of the examination.
At the start of each semester lecturers receive a printed list of students taking their modules from the SAS. The lecturer wants a system which enables the marks students achieve in courseworks and examinations to be recorded and presented back to the SAS. Faced with this problem in previous years lecturers have been left to their own devices and many have resorted to building their own spreadsheets and re-keying the names of the students on the pre-printed list. This uncontrolled approach has lead to
- duplication of data, the same student is recorded by different lecturers and by the SAS,
- duplication of effort, each lecturer builds their own spreadsheet and
- inconsistency of data, e.g. T.D. Hutchings is recorded up to six times (once by the SAS and up to five times for the modules they are taking), ‘Mr. T.D. Hutchings’, ‘Hutchings, Timothy D’, ‘Tim Hutchings’, ‘Timothy David Hutchinson’ etc. (which is correct?).
The implications of this approach on the correct recording of students grades are obvious. Adopting the CDMS via the proposed methodlogy could address some of these problems.
Phase 1: BusinessActivity Analysis
Aims & Objectives:
- To identify how the current business processes are carried out.
- To identify the data structures required to support the current business processes
Inputs
<>
Structure
The business process analysis phase concentrates on identifying and documenting low level business activities and consists of two overlapping tasks :-
- Detailed Data Flow Analaysis using low level Data Flow Diagrams;
- Detailed Data Structure Analysis using Relational Data Analysis (Normalisation)
The relationship between the tasks is shown in figure <>. The approach accepts the fact that conducting detailed data structure analysis may dictate further data flow analysis and therefore that this phase is iterative in nature.
|
figure <> Phase 1 Busines Process Analysis |
Techniques
<>
Deliverables
The deliverable from this process is a series of detailed process descriptions each consisting of a low level DFD and a set of normalised tables.
Practice
The first task for the systems analyst is to identify and document the processes which lecturers carry out in terms of assessing students. The following business processes are identified :-
The ‘Students Taking Module’ print out is received from the administrative stafff of the department.
During the first few weeks of the semesters the lecturer maintains the list by taking registers, crossing off drop outs and including late starters.
The corrected list is returned to administrative staff in order to update the SAS.
A spreadsheet is created and the names of the students are keyed in. A column or columns are included for each coursework and the examination.
Periodically the courseworks set are marked and the results keyed into the appropriate columns.
The examination is marked and the results entered.
Formulae are created which calculate the overall coursework and examination percentages for each student.
The appropriate columns from the spreadsheet are extracted and passed on to administrative staff for input to the SAS.
A detailed data flow diagram to represent these business processes is shown in figure <>
figure <> 1st Draft Data Flow Diagram |
The key data structure which supports these processes is obviously the lecturers spreadsheet, an example of which is shown in figure <>.
 |
figure <> Example Spreadsheet |
Analysing the data structure using a combination of normalisation, top-down entity-relationship modelling, common sense and business awareness reveals the following model:
|
figure <> External Schema for Student Assessment |
Phase 2: Business Activity Re-Engineering
Aims & Objectives
- To identify improved ways of conducting business activities. NB It is relatively easy to identify and remove duplication and inconsistency, however substantial improvements rely on creative input from the people involved.
- To ensure that the newly engineered business processes are consistent with the results of any overarching business process re-engineering initiatives and with other processes in the value chain of the organisation.
- To describe the external schema requirements of the re-engineered business processes.
Inputs
<>
Structure
| | This phase begins with the relatively straightforward task of rationalising the process descriptions produced in phase 1 to remove duplication and inconsistency. The result of this rationalisation is a single set of normalised tables and a hierarchic set of DFDs.
Then begins the difficult task of re-engineering the business process. In this area there are no magic wands there is no substitute for detailed business knowledge and experience. The systems analyst should adopt a facilitatory role. It should be clear that this kind of task cannot be carried out within the boundaries of a particular project.
The final task in this phase involves carrying out any changes to the DFD’s and the normalised tables, necessitated by the re-engineering process.
|
| NB:It should be noted that information collected in tasks 3 and 4 may necessitate revisiting phase 1. | figure <> Phase 2 Business Activity Re-engineering
|
Techniques
<>
Deliverables
The deliverables of this phase are (a) a set of hierarchic DFD’s with supporting documentation consisting of text, decision tables, structure charts, algorithms etc. as considered appropriate by the analyst and (b) a set of normalised tables with supporting documentation. The set of normalised tables forms the beginning of an external schema definition for the application.
Practice
During this phase the Data Flow Diagrams and External Schema are rationalised to remove duplication and inconsistency. The next step is to consider ways in which the business process could be re-engineered. Finally the Data Flow Diagrams and External Schema are redrafted to support the re-engineered activity.
Phase 3: Functional Model Iteration
Aims & Objectives
- To iteratively build a prototype which embodies the functional requirements of the system.
Inputs
Analysis & Design Reports from phases 1 and 2.
Technical Standards (e.g. hardware / software platforms and HCI standards).
Structure
The structure of this phase is again iterative, allowing for the creation and refinement of the prototype based on feedback. Ths structure is shown in figure <>.
NB This phase is very close to the identically named phase as part of standard DSDM.
|
figure <> Phase 3 Functional Prototyping |
Techniques
<>
Deliverables
The result of the prototyping process should be agreement on the functional requirements of the application and a revised external schema definition.
Practice
During this phase the analyst adopts the iterative prototyping approach in order to prove the functional requirements of the system. Ideally a CASE tool would be used to support the analysis process and be capable of generating a first cut prototype with little or no extra work from the analyst. Furthermore the use of a scaleable implementation platform within a common technical architecture should enable the functional prototype to be used as a baseline for the forthcoming design and build prototype.
Phase 4: Corporate Data Design
Aims & Objectives
- To evaluate how the corporate database definition (the conceptual schema) affects and is affected by the new external schema.
- To design and implement the required changes to the conceptual schema.
- To design and implement the required changes to the internal schema and to create the new external schema in a test environment.
Inputs
<>
Structure
The Corporate Data Design phase consists of three tasks as illustrated in figure <>
|
During tasks 1 and 2 the required external schema definition (possibly represented as a set of normalised tables or an Entity-Relationship Model) is integrated with the conceptual schema. At the logical level i.e. in meta-data terms.
During task 3 the identified changes are implemented into a test environment
|
| figure <> Phase 4 Corporate Data Design
|
During this phase the External Schema is integrated with the Conceptual Schema. If there is no conceptual schema, i.e. this is the first project to adopt the CDMS, then the External Schema needs to be re-examined in the light of corporate requirements and appropriate parts of the External Schema used to form the beginnings of the conceptual model. (In this example the entities Student, Module and Student taking module would become the beginnings of the corporate database.)
The next task is to implement the changes to the internal schema in a test environment. This is the stage at which many attempts to adopt a CDMS fail due to a lack of commitment and understanding. The problem is that student data, currently held in the central SAS, has to be unlocked. Student data has to become centrally managed in a new internal schema independent of the SAS or any other system. The SAS itself has to be amended in order to work with a view of the new internal schema rather than its own student file. The seemingly wasted effort of amending the SAS is very difficult to justify in the short term, however only by bearing this cost can long term RAD be consistently achieved and EUC effectively enabled.
The Corporate Data Design phase by its very nature cuts across system boundaries and only at this stage can the knock on effects of systems development be identified.
The External Schema is realised by creating views of the internal schema and combining these views with local tables.
Techniques
<>
Corporate Object Modelling
At this stage the techniques of Entity/Event modelling may be used in order to provide a start point for the production of ‘method’ specifications. Some explanation is required at this point. An object consists of data and methods. Methods are essentially modules of code which can be kicked into action in order to create, update, query or delete the object depending on which messages are received from other objects.
This may seem far removed from the entity/event modelling technique found in the SSADM methodology. However, on looking at the technique in detail, Entity Life History Diagrams describe not simply the business events which cause entities to be created, updated and deleted but furthermore the order in which these events should occur. Therefore the combined usage of Entity-Relationship Modelling and Entity Life Histories provides a good starting point for the definitions of classes and methods. Effect Correspondence Diagrams (ELH diagrams show how a particular entity type is affected by the system’s events, Effect Correspondence Diagrams show how a particular event affects the system’s entities) may prove useful for identifying messages.
Deliverables
<>
Phase 5: Design and Build Iteration
Aims & Objectives
To iteratively build a prototype which embodies the functional and non-functional requirements of the system in a test environment which is, so far as possible, identical to the live or production environment.
Inputs
<>
Structure
This phase largely adopts the structure of the identically named phase of the DSDM methodology. However it should be noted that during this phase it may be necessary to ‘software engineer’ certain key methods, algorithms and modules / programs. Using software engineering techniques such program structure diagrams and formal methods as deemed appropriate.
It should be noted that this phase may indicate new or changed corporate data requirements and necessitate returning to the previous phase.
During this phase the local External Schema used by the Functional Prototype is replaced by the new External Schema. The prototype is then developed iteratively to prove both functional and non-functional requirements.
Techniques
<>
Deliverables
<>
Practice
<>
Phase 6: Production Implementation Control
Inadequate systems implementation can probably be blamed for a number of systems failures. Implementation could be inadequate for many reasons including (a) the failure to distinguish between final test versions and production or live systems, (b) inadequate training and (c) failure to co-ordinate production implementation when different systems are developed in parallel.
Aims & Objectives
- To identify, plan and schedule appropriate ‘delivery units’;
- To conduct the production implementation of delivery units.
Inputs
<>
Structure
A simple technique is to invoke a regular production implementation slot, prevent implementations at other times and adopt quality assurance procedures for implementation plans. This should enable delivery units and training to be scheduled accurately and avoid uncontrolled implementation.
Techniques
<>
Deliverables
<>
Practice
<>
Enabling Rapid Application Development
The objective of this section is to describe how the methodology enables rapid application development.
Enabling End-User Systems Development
The objective of this section is to describe how the methodology enables End-User Systems Development.
No comments:
Post a Comment