The SSADM method relies somewhat on the use of diagrams in its approach to building systems than the DSDM method which tends to focus more on building prototypes before the final product. However, as Bowman (2003, p. 5) rightly pointed out, these diagrams should be simple and easy to follow, almost like maps of the system.
The potential of a good quality system is high in SSADM due to a quality level being clearly defined at the beginning, and constantly checked throughout the development of the project. SSADM also separates the logical and physical design stages, thus ensuring the system’s design can be implemented over again with new hardware/software. This obviously brings about the potential to save money for the business in the long run.
The setbacks from SSADM include the potential time spent in assessing the requirements. This can pose a huge problem to businesses as delays can lead to financial problems. The functionality of the system is also set after the beginning stages are complete, thus making it hard to change functionality at a later stage if the user requires or calls for. Although some accuse the SSADM methodology of over-planning, it can be considered a strong point if implemented well. An accurate timeline of the project can be produced ensuring better management and control of the later stages.
2.3 Suitability
If an organisation needs a well-documented and accurate information system, then SSADM is very capable. Thus, it is suitable for Government organisations where Information Systems need to be precise and well documented. Government projects are usually large scale and have a particular responsibility. This can be taken into account by the SSADM methodology.
2.4 Stages
There are a number of set stages of the SSADM Method, they are:
- Feasibility Study
- Requirements analysis
- Business Systems Options
- Requirements Specification
- Technical Systems Options
- Logical Design
- Physical Design
2.4.1 The Feasibility Study
In SSADM the feasibility study might be left out. A Feasibility Study essentially attempts to show if a new system can meet user requirements both cost effectively and to the right timescale.
According to Yeates and Wakefield (2004, p.154) the feasibility report should address three types of feasibility:-
Evaluate if the costs and timescales are right for the business and if potential returns justify opening expenditure.
Can current and future needs of users be met?
A system has to be technically possible before carrying on, thus difficulties in building a system should be assessed, performance issues should be addressed and data shown to prove claims.
A feasibility prototype can show that the project is technically feasible. However, at this stage, producing a prototype is not always necessary especially if it does not show anything other than the contents of the feasibility report.
2.4.2 Investigation of Current System
A detailed analysis of the current system is the first step proper in SSDAM. Data Flow Diagrams feature in this stage. The first being a context diagram, which is a simple representation of the entire system under investigation. This is followed by a level 1 diagram; which provides an overview of the major functional areas of the business. (http://www.getahead-direct.com/gwbadfd.htm, 09 January 2009)
These DFDs must be produced so those aspects of the current system which need to be improved can be identified. The identification of major entities through Logical Data Models (similar to ERDs) also proves very useful in this stage. After this, producing a list of requirements for the new system should be easier.
2.4.3 Business Systems Options (BSOs)
A set of options are produced and presented as possible solutions in terms of functionality and based upon the requirements outlined in the previous stage. One option should fulfil all the basic requirements, while another must fulfil all the main requirements, and then another with extra features. After presenting these options to the customer, and selection of the best one, we move on the next stage.
2.4.4 Requirements Specification
A requirements specification document should be produced considering the selected business system. The DFDs and LDS should also be refined according to this criterion.
2.4.5 Technical System Options (TSOs)
A set of up to six technical options are produced in terms of its hardware/software. Details surrounding the implementation of the requirements specification should be discussed and any constraints such as cost, time etc. should be taken into account.
2.4.6 Logical Design
The following should be defined:
- How the user interacts with the program (user dialogues)
- How data is processed by the system (updating, error handling e.t.c)
2.4.7 Physical Design
In this stage, the details of the final system specification are finalized and the physical database design realized. All the finer details of the physical design such as those surrounding the actual programming language, the hardware/software platforms and the network environment to be used should be detailed. ( Accessed 10 January 2009)
2.5 Tools and Techniques
2.5.1 Data Flow Diagrams (DFD)
A Data Flow Diagram (DFD) is a graphical representation illustrating how data moves through a function and how input is transformed into output. SSDAM has standardised the symbols used in a DFD, making it a popular tool used within this methodology.
A DFD represents the following four entities with the following symbols:
- Data flows – the movement of data within the system
- Data stores - data that is stored and not moving
- Processes - input data transformed into output data
- External entities – that which is physically separate and outside of the system but influences it nonetheless
There are different levels of detail that data flow diagrams can show also known as levels of abstraction. The most abstract is the context level diagram.
2.5.2 Entity Relation Diagrams
ERDs, otherwise known as Logical Data Models, are useful to show the relationship between the data stores. The entities are the data stores and the relationships are defined by crow’s feet lines representing one to many, many to one, or many to many.
3. DSDM
3.1 Introduction
Direct Systems Development Method (DSDM) is in contrast to the SSADM’s waterfall approach, and is a nonproprietary methodology based on Rapid Application Development (RAD). RAD combines the analysis and design stages by means of Computer Aided Software Engineering (CASE) tools and prototyping.
3.2 Advantages / Disadvantages
DSDM makes heavy use of prototyping, shortening the development time. Long and Long (2004, p. 405) mention that CASE tools have enabled automation of much of a system’s development. Therefore in contrast to SSADM, this methodology is usually quicker. It is also a flexible methodology, being able to accommodate changes in user requirements throughout.
The end result quality may not be as good as that in SSADM. This is because the scope and purpose of the project is not always initially clear. The lack of assessing User Requirements before prototyping obviously contributes to this factor. High software and training expenses are also a major disadvantage.
3.3 Suitability
The DSDM approach better suits those customers whose requirements are not well recognised and their needs change often, as it is derived from best practice. In fact the first of the nine principles set by the DSDM Consortium is “Active User Involvement is imperative” (DSDM Consurtium, 2003). DSDM is designed for object-oriented programming, making it event-driven. One of the common disadvantages cited is that it is hard to control.
3.4 Stages
The DSDM Methodology is defined in a five-phase process consisting of:
- Feasibility Study
- Business study
- Functional model iteration
- Design & build iteration
- Implementation
The first two stages of DSDM are similar to the first two stages described above for SSADM. However, according to the DSDM Consortium (2003, p. 6) the Business Study should be carried out by ‘a series of facilitated workshops of knowledgeable staff who can quickly pool their knowledge’. This method better suits Rapid Application Development than say questionnaires, which often do not produce the answers needed to create prototypes.
3.4.1 Functional Model Iteration
In this Stage a usable model is created with functionality in mind. It may not be safe to place this model in the hands of the end user because testing is not yet complete. This functional prototype will act as a basis for the ongoing testing in the next stage.
As the prototype is being developed it will become clear what the schedule is for the final version. Therefore it is at this stage that a implementation plan is created and agreed upon.
3.4.2 Design and Build Iteration
The product is designed, developed and reviewed. This process continues until each area of the system has been completed to a good enough standard. Therefore, testing is an important ongoing activity in this stage.
3.4.3 Implementation
The tested system including user documentation is delivered to the users and training of future users is realized
3.5 Tools and Techniques
3.5.1 CASE Tools
CASE tools enable automation of much of a system’s development and can better adjust to changes in user requirements. Importantly, by enabling the modelling of systems using standardised notations and techniques, a CASE tool can often produce prototype code to help programmers.
3.5.2 Facilitated Workshops
Workshops are the process of interaction with a group of members from the organisation. Rather than picking the senior staff members off one by one, a process of consultation and direct relationships in workshops enable better interaction and teamwork. This can pave the way for fewer contradictions during the system development process.
4. Fact-finding
4.1 Document analysis
Documentary evidence is vital to the systems analyst in order that he/she can start designing a realistic solution. The study of the documents listed below is helpful as an insight into how the organisation works. However, other fact-finding methods are essential to complete the picture.
- Company policy
- Business plan
- Organisation chart
- Sales and Accounts records / reports
- Invoices
- Complaint forms
- Previous System Analysis reports (if applicable)
One of the major drawbacks from this method is it’s more possible to carry on something that was not working into the new system.
4.2 Observation
Direct contact with the staff and observation of them using the current system brings about a better understanding of the true needs of the organization. For example, one may spot mistakes which are frequently being repeated by a number of staff. When this is found, we can build a means of avoiding it in the system.
( Accessed 12th Mar 09)
4.3 Questionnaire
A questionnaire must have questions which are clear and concise. It is most suitable when only a small amount of information needs to be obtained from the masses. An advantage over other methods is that the responses are often confined to objectives we have set. However, a question may be misinterpreted by the masses, thus much time must be set aside to design the questionnaire.
4.4 Interviews
Interviews with the different managers allow us to look at specific sections/departments of the organisation in greater detail. This is the best method to use within this company (Whole Earth Restaurant) because it is not a big company. The management should have a good idea of how the business is running, and what problems the employees under their control are facing. I shall therefore be holding an interview with the Restaurant Manager.
4.5 Data Recording Techniques
DFDs, ERDs as already explained.
5. Existing System
5.1 Interview Transcript – Restaurant Manager
Me: Approximately, how many customers does the restaurant get in a week?
RM: 450
Me: How is the decision made on what amounts to order?
RM: Order amounts are estimated by the Head Chef.
Me: When are the orders made (i.e. daily, weekly, etc.)?
RM: As mentioned, orders are made on Monday, Wednesday and Friday. However, certain orders for Fresh Products are made when the accountant sends me a report of the estimated stock level. If that information is not relayed to me on time, one of the waiters buys any out-of-stock items from the local Tesco.
Me: How do you obtain each supplier’s details?
RM: I have a book of suppliers and their details. However, it is now damaged and messy. When a supplier changes his details, I have to scribble it out or tear the page.
Me: How do you choose which supplier to order from?
RM: Current favourite, if let down then I change to different supplier.
Me: How are orders to suppliers usually made?
RM: By phone.
Me: Is there is any documentary evidence for the orders?
RM: No.
Me: Where is the resulting delivery stored?
RM: There is no specific storage or waiting area. One of the waiters places the order direct to the Fridge and Larder.
Me: Is the delivered stock quantity checked against sales at regular intervals?
RM: There is usually a full Stock check once a month. It does not always occur if we happen to be very busy.
Me: How do you think the current procedures in the restaurant work?
RM: Quite well, apart from three issues; Stock sometimes goes missing, I can’t always get through on the phone to suppliers, and the problem with the supplier book is it is untidy and if I lose it, I do not have a back-up copy.
Me: How do you think the current procedures can be improved?
RM: The ordering process has to be quicker and easier for the staff.
5.2 DFDs
5.2.1 Context Diagram
The following is a context level diagram of the current ordering system at the Whole Earth Restaurant.
5.2.2 Level 1 Diagram
5.3 ERD
6. Design Specification
6.1 The problems associated with the current system
- Manual and prone to human error
- Difficult to discover when items go out of stock
- No documentary evidence of orders made to suppliers
- Difficult to obtain Suppliers details
- Difficult to assess the supplier’s performance
- Difficult to assess the supplier’s product quality
- Phone orders are time consuming
6.2 New system requirements
- Provide an easy to understand end-user interface
- Reduce the possibility of human error
- Simplify data input / output process
- Monitor Stock Level
- Produce Order Document automatically (i.e. Purchase Order)
- Make supplier details easily accessible
- Produce regular assessments of all used suppliers performances
- Produce regular assessments of all used suppliers quality
6.3 Business system Options
Below I have presented three possible business system options:
6.3.1 Personal Digital Assistants (PDA)
This Option requires that Personal Digital Assistants (PDAs), connected to a Wireless server-client Network, are carried by waiters/waitress’. The file server would contain the Database file with the PDAs being able to connect to it. This way, orders can be taken at the table of the customer, without the need to go back to the till to pass on the order details. Not only does this save time but also reduce the possibility of mistakes that arise in the manual sharing of information.
While this option does meet all the requirements with the additional advantages mentioned above, the expenses of the hardware and software involved are huge. This option is not within the budget of The Whole Earth Restaurant and truly, it is only required for very large restaurants. It can take up to five months for completion of this system.
6.3.2 Microsoft Access Database
Implementing a Microsoft Access Database solution on existing or new PC computers will fulfil all of the above mentioned requirements of The Whole Earth Restaurant, for example:
- User Interface Forms can be created allowing the end-user to enter information into the database without seeing the less user-friendly table format.
- The use of features such as Validation Rules and Input Masks for data input reduces the possibility of human errors within the data
- Input can be standardised by the use of forms, and outputs can be automated through the use of reports
- Access is a relational database management system (RDBMS) enabling relationships between the data to be established
- Calculations can be made on the data by the use of Queries and Macros
This solution should take no more than two months to complete and the costs involved are just a fraction of the PDA option previously mentioned. The hardware required can range from just one PC to a number of PCs plus Networking equipment. The minimum software required is Microsoft Windows and a compatible version of Microsoft Access. Costs including installation for this option will range from £2,000 – £5,000.
Sanger (2009) explains Microsoft Access is meant for individuals and small businesses. One of the reasons for this is that the data within the database is limited to an overall 2GB size. However, if the business grows, migrating Access data to a more robust database such as Oracle is possible. ( -Accessed 30th March 2009)
6.3.3 Excel
The third way possible is by the use of Microsoft Excel spreadsheets. The main function of Excel Spreadsheets is to perform calculations. However, the problem is that relationships between data are not possible as in Access. Thus, it is not possible to monitor stock level by this method.
The two advantages of using Microsoft Excel as a flat-file database are that it is more user-friendly than Access and also cheaper. The GUI of Excel is similar to Microsoft Word so staff will probably be more accustomed to using this. The cost (according to Amazon.co.uk on 31st March 2009) of the standard edition of Microsoft office 2007 suite which does not include Access is £274.68, whereas the professional edition which does is £326.03.
6.3.4 Selected Option
I suggest that database management system like Microsoft Access is used. This will enable…
6.4 Technical System Option
The option I have chosen to use is a wireless network of up to 5 Personal Computers at each functional area within the restaurant. They are all connected to a network by communicating via antennas to a wireless switch. Each PC must have Access 2007 pre-installed.
This option will satisfy the needs of the selected Business Option and provide the additional benefit of being able to use the system at multiple areas of the restaurant. The network will not require cables to achieve this and appearance can be considered an advantage. However, since the computers involved in this system are not portable, this is the only real advantage.
6.5 Diagrams
6.5.1 Context Diagram
6.5.2 Level 1 Data Flow Diagram & Explanation
The aim of this new System is to automatically add stock that is needed by the restaurant to the purchase order. To achieve this, the stock data should be updated when customer orders are made and when deliveries of new ingredients arrive.
The input of Suppliers Details, Delivery Details and Menu Details into the database is made easier by a Graphic User Interface. With the Delivery Details also being entered into the database, it is easier for the Restaurant manager to look up the discrepancies; that is by comparing it to the printed Purchase Order created by the system.
6.5.3 Entity Relationship Diagram with Explanation
The first table (CustomerOrder) will contain a unique number (OrderNo) for each customer order. Other useful details of the Customer Order are ‘the date of sale’ and ‘payment type’. These are included in this table so that valuable statistics can be produced later on.
The purpose of the ‘OrderItem’ Table is to contain each menu item ordered by the customer and link it to the unique ‘OrderNo’. To achieve this, the Primary Key consists of two columns – The Menu Item Number (DishNo) and the unique customer order number (OrderNo), which is a foreign key from the ‘CustomerOrder’ Table. A column to specify quantities of each menu item ordered has also been added to prevent duplicate entries.
Obviously, a menu table is required to determine what items the customer can actually order. The primary key in this table is the MenuID which is the DishNo used as a foreign key in the previous ‘OrderItem’ table. Within this table, important details of each menu item have been included. The dish title and price are valuable to understand exactly what is ordered and the overall price to be paid.
The MenuIngredient table is required as each Menu Item from the previously discussed Menu Table must have ingredients which are ordered when needed to make the menu Dishes. The table consists of two foreign keys, one from the Menu Table and one from the IngredientStock table which is discussed below.
The purpose of the IngredientStock Table is to enable stock monitoring. Not only are the quantities updated by its relationship to the MenuIngredient table, but the new deliveries of each ingredient also. Queries can be made in Access to estimate, for example, how many cases are needed for a weeks order.
A table has been created so that all new deliveries can be input onto to the database. These deliveries must also have a relationship to a suppliers table in order that new purchase orders can be made automatically. Purchase Orders can also be made in a more manual fashion by entering details into the BusinessOrder table.
6.6 Data dictionary
6.7 Input/output formats
6.7.1 Customer-Order - Input
This customer order form is one of the forms that can be selected from the start-up main menu. The order data should be entered on this form. If the item boxes are not ticked then a quantity cannot be entered. The Customer Order No. and date should be automatic and cannot be edited. After submitting the order, the total price for the order should appear.
Once submitted, the order will automatically update the ingredient stock because each menu item has ingredient details.
6.7.2 Menu-Ingredients - Input
This form enables ingredients to be assigned to an existing or newly created dish. Creating a new dish is done by clicking the last button at the footer. The Ingredients, their quantities and suppliers are validated by combo boxes to ensure that only valid values from existing tables are selected.
6.7.3 Business-Order - Input
Sometimes there are circumstances when orders of ingredients need to be initiated by the user, rather than being computer automated. This form allows exactly that by creating an automatic Purchase Order No. and a combo box of all approved suppliers. Once submitted, a Purchase Order will be created and printed.
The ‘Suppliers’ form allows the user to add new supplier details along with which products they supply. The products entered are put into the ‘IngredientStock’ table with the qty field default to 0. Each product will have a minimum amount set, so that when the stock reaches below that level it can be added to the purchase order report.
6.7.5 Menu - Output
This is the menu for the Whole Earth Restaurant which should be produced from the MenuItem table.
6.7.6 Purchase Order - Output
The Purchase Order is an essential output document necessary to make an order for Menu Ingredients. In many cases this document will be automated.
6.8 Structured English
DO-WHILE Stock to be processed
IF Quantity < Amount THEN
ADD ITEM TO Purchase Order
END-IF
IF Order Quantity > Bulk1 THEN
Discount = 10%
ELSE IF Order Quantity > Bulk2 THEN
Discount=20%
ELSE
Discount=0%
END IF
END LOOP
6.9 Flowchart
7. Evaluation
7.1 Strengths of the System
The system I designed can successfully help the restaurant to monitor resources and automate the orders of stock when necessary.
The system is very user-friendly. The forms are neat, tidy and consistent throughout. On all forms headings were used, and command buttons, combo and tick boxes were all added for easier navigation. I also made sure to size all related controls to equal proportions. Through the use of data relationships, it was possible to add sub forms to the main forms which can potentially save time of the end-user by making sure the same data does not have to be repeatedly inputted. The company logo is found on all reports so that all company documentation can be identified.
7.2 Weaknesses of the System
One of the main weaknesses of the system is due to its software environment. The 2GB maximum data size may prove too little in the future and this DBMS is not powerful enough to run on a server for multiple branches to use. However, as mentioned, Access databases can be converted to different formats in number of different ways.
7.3 Potential Improvements
The tables and relationships allow for new functions to be added to the system. For example, with no modification to the tables or relationships, a report could be added with a number of charts in order to make analysis on a yearly, monthly or a daily basis. Through the use of VBA code, a spreadsheet can be linked to the system through the click of a button on one of the forms. This would allow more advanced calculations and chart designs for management reports.
A dynamic website can also be created to enable customers to order food online. The current database of the system can be converted to a Microsoft SQL server database so that orders from online will also have an effect on the stock level.
7.4 Personal Performance
I found that using the SSADM methodology to design my system gave me confidence that this system could work and fulfil the requirements set by the restaurant. However, in hindsight I would prefer to use CASE tools and prototyping to make sure of the functionality. I also feel this would have increased my speed in finishing this assignment because it was hard for me had to adapt to the use of SSADM; completing one stage before moving to another.
I do feel that in my interview with Sherri, a few of my interview questions could have been stronger worded in order for me to gain a more definite understanding of the requirements. I also feel that more questions could have been asked during the allocated amount of time and these elements of poor planning before the interview could have had a bigger effect in a real-life situation. This is definitely something I hope to look out for in future work.
I initially found the use of flow charts particularly difficult in SSADM because of the use of shapes that I had not become accustomed to. However through the help of a website and a book from the college library, I was able to come overcome this. Even though SSADM was designed to be a single-structured approach there are in fact different takes, views and versions of SSADM. This made my research long and cumbersome and as I result I found it really difficult to finish the assignment on time.
I am disappointed that I did not have time to focus more on the security features of the system. Built in functions of Access can provide password protection before being able to enter the system an VBA code could be used to turn off all modification for certain user groups.
8. Bibliography
8.1 Books
-
Yeates, D. & Wakefield, T. Systems Analysis and Design (2004) Second Edition
-
Long, L. & N. Computers: Information Technology in Perspective (2005) Twelfth Edition, Pearson Education
-
The DSDM Consortium, DSDM: Business Focused Development (2003) Second Edition, Pearson Education
-
Bowman, K. Systems Analysis: A Beginner's Guide (2004) Hampshire: Palgrave Macmillian
-
Weaver, P., Lambrou, N. & Walkley, M. Practical SSADM 4+: A Complete Tutorial Guide (1998) Second Edition, London: Pitman Publishing
8.2 Websites
-
[Accessed 09 January 2009]
-
[Accessed 15 February 2009]
-
[Accessed 16 December 2008]
-
[Accessed 05 January 2009]
-
[Accessed 03 February 2009]
-
[Accessed 20 March 2009]
-
[Accessed 20 March 2009]
-
[Accessed 20 February 2009]
8.3 Software
- Microsoft® Student 2008 [DVD]. Redmond, WA: Microsoft Corporation, 2007
Analysis and Design of Information Systems p. 51
