English
中文Introduction
This project researches the design and usability of information retrieval for students and staff at a University Business School for its induction week. This report in particular focuses on the various (prototyping) methodologies that can be used within this project, including a recommendation for the most valid method.
Each methodology will be presented with respective advantages and disadvantages, outlining why it is recommended for this project. Although all the methodologies are established and warranted, references to the project dimensions will assist in reiterating suitability.
Methodology
The different types of methodology to be reviewed are:
1. Structure Systems Analysis and Design Method (SSADM)
2. Rapid Application Development (RAD)
3. Soft System Methodology (SSM), focusing on CATWOE
4. Entity Relationship Modelling (ERM) – element of SSADM
5. Unified Modelling Language (UML)
SSADM – Potential Methods
SSADM is a product-oriented method, intended for a small number of activities. This particular system involves several activities; hence an activity method approach would be far beneficial than SSADM. Considerable commitment at management level is required to apply SSADM efficiently. In this instance, the Admin team are the driving force for this project to simplify their tasks, there is little direct Managerial level involvement. SSADM methodology is not applicable to all projects; it cannot be used as a universal methodology for all (IT) projects.
To identify if the application is suited to SSADM, the essential application information needs to be modelled in Logical Data Structure. There is significant cost of utilising SSADM techniques, which must be justified by the benefits or savings after the project is completed. Additionally, this Web driven database system is a small-scale project that does not require a complex, expensive and rigid methodology. Applying SSADM efficiently would require experienced and knowledgeable analyst(s), which would incur a very high overhead for this small project.
SSADM is primarily utilised for design of large database information systems based at one site. In contrast, the university business school project focuses on a small distributed database, enhanced with the web interface for updating. The distribution aspect of the database poses data integrity issues, with the risk of replicated across the different sites. Typically, SSADM focuses on the system analysis and design and not on system development and implementation.
Various Selected Methods
Entity Relayionship Model (ERM)
The ERM is also known by other names including Logical Data Structure (LDS) or Data Modelling. The ERM is part of the SSADM, featuring early in the SSADM lifecycle and updated several times during the lifecycle. The ERM focuses solely on databases, and is used to create database designs. The data captured and stored in the database is the entities, attributes and relationships of the entities. The ERM shows the underlying structure of the data, detailing the relationship between the logical groups of data.
ERM defines the entities and relationships within the database, not the system User requirements. Therefore, ERM can capture the data required for the database. However, it will not focus on the web interface required by the admin staff, students and other interested parties to update the information held in the database.
ERM alone would not be sufficient to use as a modelling technique for this project, but can be adopted to define, design and create the back end database for the web-enabled system. ERM also does not take into account the Admin teams’ process for updating student preferences and simplifying the process using an IT system. The ERM does not account for the activities that will occur when Users employ the web interface to renew and update the information held on the database. The ERM does not cater for the business rules of the Admin teams’ process/procedure.
Rapid Application Development
Developed initially by James Martin in the 1980s, RAD is “a method of developing information systems using prototyping to achieve User involvement and faster development compared to traditional methodologies such as SSADM” (Bocij et al, 2003). RAD was developed as a response to many failing projects, due to the length of time taken to deliver projects. During the timeframe, the original requirements were outdated, hence the rise of Rapid Application Development.
Other failings that RAD overcomes are:
1. Gap of understanding between Users and developers
2. Developers isolating themselves from Users
3. Quality measured by closeness of product to specification
4. Business needs change during the development process
5. “What Users get is not necessarily what they want.” (Bocij et. al, 2003, p307).
These failures are overcome as RAD uses prototyping to involve Users and accelerates the speed of development.
A drawback of RAD is that to complete the project quickly compromises the usability and functionality. As the web driven database system is an essential part to improve the Admin team and student process for changing requirements, it is critical that the usability and functionality of the system is not compromised.
A primary concern for the Admin staff was the students using the web interface to access the timetable information. If the application were made live with the compromises, students would be discouraged from using the web interface. This would effectively be a step back for the Admin team with an (new) application that is not improving the process or helping administration.
The final application will be accessible by Admin staff, registry office and other university contributors. It may not be practical or convenient for Users to be involved and dedicate time to the prototyping stages of the project. The Course Heads will be assigned lectures to different course programmes and may not be available to provide feedback. One of the Users will be the students, they are not available to test the prototype and provide feedback. Current students may be available as a secondary resource but subject to commitments and willingness to participate.
Prototyping is an iterative process where Users suggest improvements and a new prototype will be built until final approval and the system goes live. During the test phase, staff may start to change the original requirements and demand further functionality that will be out of project scope.
Prototyping would be suitable for this project as the primary User consist of Admin staff, who will be available to test the product but they are classified as project sponsors i.e. those who require the system to improve their process and reduce workload.
Soft System Methodology (SSM) -CATWOE
SSM emphasises the human interaction in the system and models behaviour as part of the system analysis. This methodology resolves the problem of system analysts applying their expertises in system development to ambiguous requirements. SSM argues that human beings are an integral part of system development; therefore the methodology must accept all Users involved in the development process. However, there may be conflict issues as different Users present their own requirements and objectives for the system.
Peter Checklands’ CATWOE is a Soft Systems Methodology (SSM) providing a checklist for a problem or goal definition. CATWOE considers six elements; the ‘Customers’, ‘Actors’, ‘Transformation process’, ‘World view’, ‘Owners’ and ‘Environmental constraints’. These six elements are used to clarify the root definition that Checkland describes, “as a concise, tightly constructed description of a human activity system which states what the system is” (Bocij et al, 2003, p412). However, if a system is represented by many root definitions, there may be difficulties in the system development process.
CATWOE would be recommended as a methodology for system development as it focuses on producing a root definition for the system, which compliments the methodology for developing the system. The focus is on the people that will interact or involved with the system, rather than how the system is going to be developed.
SSM as a full methodology would be suitable, as within the 7 steps of SSM, models are developed that can be utilised in the development of the application. The 7 steps are:
1. “Stage 1: The problem situation: unstructured
2. Stage 2: The problem situation: expressed
3. Stage 3: Root definitions of relevant systems (CATWOE)
4. Stage 4: Building conceptual models
5. Stage 5: Comparing conceptual models with reality
6. Stage 6: Assessing feasible and desirable changes
7. Stage 7: Action to improve the problem situation” (Bocij et al, 2003, p410).
The methodology for Soft Systems only produces models and does not describe methods for implementing the solution. Therefore using SSM as a methodology to implement a system at the Business School would be inadequate, as it does not provide the steps for implementation or User testing. SSM can be used as a tool to assist other methodologies that implement application systems, such as SSADM or RAD.
Unified Modelling Language
This project will also utilise UML as the analysis method. “The UML is the standard language for specifying, visualizing, constructing and documenting all the artefacts of a software system.” (Quatrani, 2003, p3). UML provides different views for different aspects of the project. The view of different Users is identified and illustrated diagrammatically, simplifying and capturing all aspect during the development process.
Within UML there are 13 different diagrams that can illustrate the various aspects of the system; they are grouped into three categories: structure, behaviour and interaction. Not all these diagrams are required for each project as only a selection applies in this project.
The different diagrams include:
1. Structure Diagrams include Class, Object, Component, Composite Structure, Package and Deployment.
2. Behaviour Diagrams include Use Case, Activity and State Machine.
3. Interaction Diagrams include Sequence, Communication, Timing and Interaction Overview.
(source: http://www.omg.org/gettingstarted/what_is_uml.htm , accessed 28/01/2007)
As Admin staff, registry office and teaching staff will be contactable; they will be able to provide vital information to produce the UML diagrams. This will form part of the identifying the problem, gathering requirements, system analysis and system design process. The completed diagrams will present an overview of what transactions need to be undertaken, by whom and what they will affect. The students are not required to be present or interviewed to communicate their actions; the Admin staff can provide detailed information about requirements anticipated for students and their interaction.
UML models the requirements of the software application prior to coding. Using UML, the project will ensure that it captures the business functionality and meets end User requirements. The diagrams identified within UML can capture every possible scenario that will occur within a system and represent the information in different views. The diagrams will also focus on ownership, time, end User (actors) and the transactions. UML will identify the system support requirements for scalability, robustness and security prior to any coding, which is expensive to amend following implementation.
An apparent key disadvantage of UML is the duplication of information duplicated into different views\diagrams. For any new User, UML is a technique that has to be learnt, therefore an experienced (costly) specialist would have to collate and produce the diagrams for the university.
Application of Selected Models
Elements of UML, ERM, SSM and RAD will all be applied to the analysing, designing and implementing the web-enabled database. This section focuses on what aspect of each methodology will be applied for the project.
UML
To identifying and producing the relevant diagrams to assist in identifying system requirements and specifications will apply UML. The diagrams will show the necessary processes\transactions that are required from the system.
The first step with UML would be to produce ‘Activity Diagrams’ that represent the flow within a process. Each activity flows to the next activity illustrated by arrows in the direction of flow, similar to a flow diagram. The activity diagram would be used in the system analysis stage, analysing the requirements and documenting in diagrams the business process workflow. The activity diagram can also be amended to show ownership of the activities by introducing “swim lanes”. This separates the diagram into different sections of ownership and plots the activities in a downward flow between ownership.
The next step is to produce the ‘Use Case Diagram’ that features an (external) actor that is someone or something interacting with the system. This can also be another external system interacting with the business school system, for example it can be a separate room booking system. The use case diagram illustrates a sequence of related transactions performed by different actors and their respective “use case”. This information is applied to produce the use case, documenting the flow of events from the actors’ perspective. The diagram will show:
1. Start and finish for each use case
2. Normal flow of event (Admin staff logs into account)
3. Abnormal flow of event (Admin staff password incorrect)
4. Action performed during use case (Admin staff updates database)
Sequence Diagrams will be used next to illustrate the interaction in time sequence between objects. This will determine what objects and interactions are required to complete a specified function. For instance, a student changing programme choice would involve logging into account, User account verification, accessing current details held in database, display the details onscreen, click “change\update” button, select from list of programmes, click “submit” button, confirm that change is correct by clicking ‘OK’. The student would be the “object” interacting with the system via the Internet. These diagrams are useful for system functionality, knowing which end Users require what functions and how each step should be designed.
Class Diagram is the final diagram that will be used, representing “a collection of objects with common structure, common behaviour, common relationships, and common semantics” (Quatrani, 2003, p.11). The class diagram is a static representation of the system that shows the class name, attribute and operation. This can be expanded to show the relationship between each class. Elements that can be added to each class are the association, aggregation, multiple navigation and inheritance relationship among many others.
Entity Relationship Model (ERM)
ERM will be applied to design and develop the back end database, which will be linked to a web interface. Applying ERM will allow the entities to be identified for the database, such as student, course, lecturer etc. The next stage would be to associate the entities by distinguishing the relationship between the entities and classify the type of relationship eg one-to-one, one-to-many. The final stage would be to associate attributes with each entity, this would capture information about each entity, for instance the entity student would have an attribute name, address etc.
Soft Systems methodology (SSM) – CATWOE
CATWOE will be applied to identify the human interaction with the web driven database. User will not be accessing the database directly, but utilising the web interface to make changes and update the database. CATWOE will be used to identify, similar to UML, the users of the system and the transaction that the user will execute. CATWOE also identifies the problem that Customers are experiencing and their views on the proposed solution. The information gathered from the six elements will be used to build a root definition for the system, which will be used to develop the system.
rapid Application Development (RAD)
Applying RAD methodology will allow the application (web enable database) to be developed rapidly and used as a prototype. As prototyping is an iterative process where Users suggest improvements and a new prototype will be built until final approval and the system goes live. As the main users will be University staff, they will have easy access to the prototype and are able to provide feedback.
Conclusion
The methodologies discussed in this analysis have been carefully considered with appreciation of the desired end result. This includes awareness of time and (potential) budget constraints, to which extent SSADM has not been chosen as a selected method. Elements of the chosen methodologies have been applied to the project.
UML provides a sound methodology for system development for the web driven database system in conjunction with RAD, ERM and SSM. UML models the requirements of the software application prior to coding, RAD produces a prototype showing usability and functionality, ERM is an (inherent) element from SSADM focusing on the relationship between entities and SSM provides the methodology for the analysis focusing on human interaction.
