This report is going to involve the study of a video rental service and the name of the shop is The Entertainment Zone. Every entertainment zone shop has one database assigned to it that cannot be accessed from outside the store. The database contains information on the customer’s details and the stock levels. The customer details include the following entities: Name, Address, Telephone number, Membership number, and Credit Card detail. The stock details include the following entities: Title, ex/rental, and status, number of copies in stock, number of copies on loan, price, and genre and age certification.
The system allows searches for customers on name or membership number, and stock on part number and title. The system is used to check out titles on customer accounts as well as checking them back into the entertainment zone. If a customer requests, a title that is not currently available, the store assistant can call another store on the customer’s behalf and check to see if that shop has the request. This is very time consuming and a waste of resources. The customer must also hold another account with the particular store in order to rent a video from there.
The problem with the current system is that the database in one shop is not linked to any databases from other shops. This creates problems when customers from other stores wish to rent a video. E.g., an entertainment zone cardholder who is registered with a store in Llanelli could not use their card in Swansea. Also within the stores, staff cannot search other store’s stock levels. This is helpful to customers who require a rental that their store does not currently have available. The entertainment zone needs a new system that will be able to link all the video store databases around the country together, which will enable the searching of all store databases within the selected region. For example, all the stores, databases in region of Carmarthenshire can be linked together. This would create regions within the database. There will be a function to search with a particular region for use when searching for customers.
Prototyping VS SSADM
This report will evaluate two different methods for creating a new system that will correct the current problems with the video rental service. The two ISD methods that will be evaluated will be Prototyping and SSADM (Structured Systems Analysis and Design Methodology).
Prototyping is an iterative process of systems development in which requirements are converted to a working system that is continually revised through close work between analysts and users. “The prototyping model is a software development process that begins with requirements collection, followed by prototyping and user evaluation. Often the end users may not be able to provide a complete set of application objectives, detailed input, processing, or output requirements in the initial stage. After the user evaluation, another prototype will be built based on feedback from users, and again the cycle returns to customer evaluation. The cycle starts by listening to the user, followed by building or revising a mock-up, and letting the user test the mock-up, then back” from http 1.
“Prototyping comes in many forms – from low-tech sketches or paper screens from which users and developers can paste controls and objects, to high tech operational systems using CASE (computer-aided software engineering) or fourth generation languages. Many organizations use multiple prototyping tools. For example, some will use paper in the initial analysis to facilitate concrete user feedback and then later develop an operational prototype using fourth generation languages, such as Visual Basic, during the design stage” from http 2.
Prototyping ensures that any design created is evaluated in a realistic context, based on real experiences with the system. The users are shown something tangible rather than a review of an abstract specification. The hands on approach help to deepen the insight and learning process for developers and users, ensuring a more complete specification of requirements. Users are unable to specify their requirements in advance but are able to recognise it when they see it. Prototyping ensures that the developers achieve better communication and establish greater rapport with their users and the user participation and commitment should increase, which should lead to increased user acceptance of the system.
Prototype systems can be developed in a few days and analysts can receive rapid feedback from users, so that the iterative cycle can work quickly. Real test data can be used to check the system can handle what is thrown at it because without a prototype, this might not happen until late in the development process. The earlier problems are discovered, the cheaper and easier they are to fix. Because prototypes inherently increase the quality and amount of communication between the developer/analyst and the end user, its’ use has become widespread.
In the early 1980’s, organizations used prototyping approximately thirty percent (30%) of the time in development projects. By the early 1990’s, its use had doubled to sixty percent (60%). Although there are guidelines on when to use software prototyping, two experts believed some of the rules developed were nothing more than conjecture from http 2.
There are two main types of prototyping:
- Throwaway – The early creation of a working model of various parts of the system, solely to help establish and elicit the user requirements. The prototype is then thrown away and the system is developed based on the requirements identified.
- Evolutionary – A prototype is built, and then refined for improvements, adding further requirements until it meets a level of acceptability decided by the user – the prototype evolves into the actual, final system.
There are alternative forms of prototyping such as:
- Functional prototyping for demonstrating, testing and evaluating the functionality of a system.
- Process prototypes for demonstrating, testing and evaluating the process, sequence and responses of a system.
- Design prototypes for demonstrating and evaluation a variety of alternative designs.
Prototyping may address the problems of communication between developers and customers, customer acceptance, delivering early proof of concept, fuzziness in early stages of design, gathering valid requirements and increasing constructive user participation. Prototyping may introduce the problems of deciding how much iteration is enough, gauging progress without traditional milestones, managing conflict between developers and customers, managing the schedule for a development cycle, processing excess change requests from customers and runaway customer expectations.
“Prototyping’s obvious strengths lie within areas of unique application settings, or where developers have little or no experience, or where costs or risks of error may be high. It can be an extremely efficient means of establishing user requirements, by gaining their feedback stage by stage as the system evolves”. Systems Analysis Techniques by Mark Lejk and David Deeks
Advantages of Prototyping:
- Reduces development time.
- Reduces development costs.
- Requires user involvement.
- Developers receive quantifiable user feedback.
- Facilitates system implementation since users know what to expect.
- Results in higher user satisfaction.
- Exposes developers to potential future system enhancements.
Disadvantages of Prototyping from http 2:
- Can lead to insufficient analysis.
- Users expect the performance of the ultimate system to be the same as the prototype.
- Developers can become too attached to their prototypes
- Can cause systems to be left unfinished and/or implemented before they are ready.
- Sometimes leads to incomplete documentation.
- If sophisticated software prototypes (4th GL or CASE Tools) are employed, the time saving benefit of prototyping can be lost.
Prototyping does have some problems, such as managing, a project may become more difficult without the ‘comfort factors’ of built in phases with milestones and specific deliverables. Rapid prototyping may result in failure to develop an overall systems plan, which can lead to problems with systems integration and the documentation of the system might be neglected. Prototyping may be difficult to apply on large systems development projects where it is not clear how the system should be divided for the propose of prototyping.
SSADM (Structured Systems Analysis and Design Methodology) is a methodology developed by UK consultants Learmonth and Burchett Management Systems (LBMS) and the central computing and telecommunications agency (CCTA). The methodology provides project development staff with the very detailed rules and guidelines to work to. It is highly structured. A reason for its success has been in the standards provided. SSADM is most appropriate for medium/large scale projects.
It is a methodology used in the analysis and design stages of systems development. SSADM has been used by the government in computing since its launch in 1981. It was commissioned by the CCTA (Central Computing and Telecommunications Agency) in a bid to standardise the many and varied IT projects being developed across government departments. Since 1981 SSADM has been further refined and version 4 was launched in 1990. SSADM is an open standard, i.e. it is freely available for use in industry and many companies offer support, training and Case tools for it.
Within government departments, SSADM has to be used. External contractors producing software for the government also have to use SSADM. SSADM is used by other companies because they expect the use of a disciplined ‘engineering approach will eventually improve the quality of the systems they produce. Many companies have been willing to incur the considerable expense of implementing SSADM (e.g. staff training) with this expectation in mind.
“The main user of the method is, of course, the UK government, and its use is mandatory on many public sector projects. However, the fact that it is an established and open method, and that SSADM skills are widely available, means that it is becoming a de facto standard method in the wider marketplace”. Systems Analysis and Design by Donald Yeates and Tony Wakefield.
The application of SSADM aims at the development of information systems based on database systems and less at the development of real-time-oriented software. Therefore, the method concentrates on data flows, data models, and-as a specialty-the chronological life cycles of entities.
SSADM was based on four previously specified approaches; Yourdon’s Structured Design, De Marco’s Structure Analysis, the French system MERISE and Jackson’s Structured Programming, a precursor of Jackson System Development.
SSADM has seven stages and the activities of each stage are precisely defined, as are their associated end products.
- Prepare for the feasibility study
- Define the problem
- Select feasibility options
- Create feasibility reports
- Establish analysis framework
- Investigate and define requirements
- Investigate current processing
- Investigate current data
- Derive logical view of current services
- Assemble investigation results
Business system options
- Define business system options
- Select business system options
- Define requirements
- Define require system processing
- Develop required data model
- Derive system functions
- Enhance required data model
- Develop specification prototypes
- Develop processing specification
- Confirm system objectives
- Assemble requirements specification
Logical system specification
- Define technical system options
- Select technical system options
- Define physical design module
- Define user dialogues
- Define update processes
- Define enquiry process
- Assemble logical design
- Prepare for physical design
- Create physical data design
- Create function component implementation map
- Optimize physical data design
- Complete physical data design
- Consolidate process data interface
- Assemble physical design
These modules cover the life cycle from feasibility study to design, but not implementation and maintenance. SSADM revolves around the use of three key techniques, namely Logical Data Modelling, Data Flow Modelling and Entity/Event Modelling and they are used to aid the different stages.
Logical Data Modelling – This is the process of identifying, modelling and documenting the data requirements of a business information system. A Logical Data Model consists of a Logical Data Structure (LDS – The SSADM terminology for an Entity-Relationship Model) and the associated documentation. LDS represents Entities (things about which a business needs to record information) and Relationships (necessary associations between entities).
Data Flow Modellin – This is the process of identifying, modelling and documenting how data flows around a business information system. A Data Flow Model consists of a set of integrated Data Flow Diagrams supported by appropriate documentation. Data Flow Diagrams represent processes (activities which transform data from one form to another), data stores (holding areas for data), external entities (things which send data into a system or receive data from a system and finally data flows (routes by which data can flow).
Entity Event Modelling – This is the process of identifying, modelling and documenting the business events, which affect each entity, and the sequence in which these events occur. An Entity/Event Model consists of a set of Entity Life Histories (one for each entity) and appropriate supporting documentation from http 3.
“SSADM has a number of points in its favour. It is a mature method, which has undergone several evolutions to reach its present stage, so it can be used with confidence as a reliable and stable platform for development”. Systems Analysis and Design by Donald Yeates and Tony Wakefield.
Advantages to using SSADM:
- Creates very solid software on even the first iteration.
- Forces developers to understand all the problems that could happen and plan for them.
- Makes projects more resilient to loss of staff.
- Easy to use CASE (computer-aided software engineering) tools to help in the production of the software.
- Combines several techniques and the most important is there is a framework existing to tell the users how and when to use each of the techniques.
- SSADM is an ‘open’ method and it means there is no license fee for its use.
Disadvantages to using SSADM:
- Requirements are set in stone after being created meaning errors in that area will be costly and time consuming to repair.
- Very slow and laborious.
- Expensive in comparison to some rapid application techniques.
- Can be unwieldy for anything but industrial strength software.
- A Varity of early learning and a significant investment is required.
- Development and implementation does not exist in the SSADM method, only addresses analysis and design
SSADM (Structured Systems Analysis and Design Methodology) is an integrated process and data driven approach to designing information systems. The process has a set of guidelines and steps to follow to enable an information system to be designed. SSADM is mainly used as a requirement for government computing projects. It is increasingly being adopted by the public sector in Europe.
SSADM divides an application development project into modules, stages, steps, and tasks, and provides a framework for describing projects in a fashion suited to managing the project. SSADM’s objectives are to:
- Improve project management & control
- Make more effective use of experienced and inexperienced development staff
- Develop better quality systems
- Make projects resilient to the loss of staff
- Enable projects to be supported by computer-based tools such as computer-aided software engineering systems
- Establish a framework for good communications between participants in a project
SSADM would be a good choice for developing a new system for the entertainment zone because it has a set of guidelines and steps to follow so if you go wrong somewhere the designer can just go back a step and then follow all the instructions. SSADM uses a disciplined ‘engineering approach which will eventually improve the quality of the systems they are used to produce. Many companies have been willing to incur the considerable expense of implementing SSADM (e.g. staff training) with this expectation in mind.
Prototyping would not be a good method to use to develop a new system for the entertainment zone because prototyping is mainly used to design user interfaces and smaller systems and not used with systems, which have databases. Prototyping is a rapid approach to developing information systems and a system could be developed in a couple of days using prototyping. Prototyping can help to establish the suitability of the interface at the task level once the requirements for a system have been determined and its functionality is defined. This ensures that the user can perform the tasks necessary for the job as well as guarantee that a task sequence can be completed successfully.
Prototyping can resolve uncertainty about how well a design fits the user’s needs. It helps designers to make decisions by obtaining information from users about the necessary functionality of the system, user help needs, a suitable sequence of operations, and the look of the interface. It is important that the proposed system have the necessary functionality for the tasks that users may want to perform anywhere from gathering information to task analysis.
SSADM would be the better method out of SSADM and Prototyping for creating a new system for the entertainment zone. The reason for this is that SSADM provides a structured analysis and design in order to overcome the identified constraints. Then once the analysis and design stages are complete, the implementation of the system will occur in the video stores. Another reason that SSADM would be a good choice is that SSADM is suited to large systems where a database is primarily used.
A different methodology can be used to overcome the problem of design and implementation because SSADM does not include ways in which to implement a system. Prototyping can be used throughout the implementation. Each individual area can be prototyped first before full implementation of the system to the UK. This would be beneficial as bugs will be present in the system and will need to be fixed as they are spotted from prototyping, also operational problems may occur after implementation and these will need to be fixed before full integration to the UK.