The aim of SSADM is to provide logical data modelling to identify, model and document the data requirements of the system being designed. The data is split into entities and relationships. Data flow modelling documents how data moves through a system and examines processes, entities, data flow and data stores. SSADM also provides tools for entity behaviour modelling.
The SSADM life cycle is a waterfall model, that is, one stage flows on to the next from the top to the bottom. The life cycle can also be used as an iterative loop model where the final product spawns the next phase in an ongoing system.
There are 11 stages to the SSADM system lifecycle that follow the system from the initial idea to completion. Each step is broken down into many smaller sub-steps or processes. Each stage follows logically after the previous, but it is an oversimplification to say that one stage is a distinct step after another.
All projects must start with an initial idea. Usually this consists of a brief definition on what is the project all about, what is its purpose and what the project aims to accomplish.
Expanding on the Initial Idea, the Feasibility Study involves drawing up the terms of reference, which state the objectives and scope of the project, how long it should take and how the results should be presented. The terms of reference are usually drawn up by senior management. The feasibility study must determine if development of the project is justified in terms of economic and managerial terms.
The main role of the analyst in the feasibility study is to analyse the current system at a high level. Data Flow Diagrams (DFD) are used to describe how the current system performs and to illustrate known problems.
The Requirements Analysis stage defines a series of possible solutions to the problem and presents them to management in terms of business options. These options may be supported by technical documents such as high-level DFD's, Logical Data Models (LDM) and Work Practice Models. The requirements analysis report must also contain financial and risk assessments to be presented and supported by outline implementation descriptions.
The steps involved within the requirements analysis will define the flow of data in the system, deriving system functions and to develop user role specifications, prototypes and process specifications.
Systems Analysis and Specification
The Systems Analysis stage is an extension to the feasibility study. If the project has a feasibility study then the bulk of the work has already been done. A terms of reference will also be required if one does not exist. The output from this stage is the System Specification which gives precise details of what the new system is required to do, but does not go into how it does it. It provides a logical model of the new system. Once agreed, the specification is the basis for the work done by the system designers.
This stage deals with how the requirements of the new system are carried out (how the logical model is implemented as a physical system). The system designer will develop a number of design options and test them against the requirements specification and design criteria. The one that comes closest to the design brief with the most cost effective use of equipment and personnel is selected and broken down into more detailed specs.
Because of this the design stage has two phases: produce outline designs based on requirements specification with input from users and the detailed designs produced from the selected design.
This is the only stage in the development where program code is written. The designs and specifications provide enough detail for the programmer to code and test individual modules. Each unit is tested to ensure that it meets the requirements of the specification.
Within the life cycle there are various levels of testing as well as the unit testing performed in the development stage.
Link testing ensures that programs work together, e.g. the data passed from one program to another has the correct format.
System testing ensures that the system as a whole performs according to the design specification. Recovery procedures must be tested as well as normal operation procedures.
Finally user acceptance testing is carried out by the users in stages to ensure that the system is usable.
Any modifications are passed back to the design stage where changes are made as necessary and passed to the development team.
When the testing has been carried out to the user's satisfaction the system, or parts of it, are put live. The "put live" phase can also be known as implementation, cutover or production. This is when the users start using the system to carry out their business activities.
There are two main approaches to implementation a project:
- Phased: Stand-alone subsets of the system are executed over a period of time.
- Big Bang: The whole system is put live in one go.
Some systems will require special programs or tasks to convert existing data to a format usable by the new system. The process of changing data from the old system to the new is called conversion.
Maintenance and Review
Once the system is put into place, maintenance is required to ensure satisfactory operation.
Maintenance should include regular reviews and evaluations to ensure that it is achieving its objectives, identify any aspects that can be improved or any operational problems. Maintenance falls into two categories, implementation of new features or elimination of errors.
[System Lifecycles and SSADM, http://sharpertutorials.com/design-methodology-and-system-lifecycle/]
The tools of SSADM consist of the three techniques stated below:
- Logical Data Modelling: this is the process of identifying, modelling and documenting the data requirements of a system. A Logical Data Model consists of a Logical Data Structure (LDS - also known as an Entity-Relationship Model) and the associated documentation. LDS represents Entities (things about which a business needs to record information, and usually proper nouns) and Relationships (links between entities).
- Data Flow Modelling: this is the process of modelling and documenting how data flows around a system. A Data Flow Model consists of a set of connected Data Flow Diagrams (DFDs) supported by appropriate documentation. Data Flow Diagrams represent processes and functions of the system (activities that transform data from one form to another), data stores (files or data storage), external entities (things that send data into a system or receive data from a system) and finally data flows (show the flow of data around the system).
- Entity Event Modelling: This is the process of identifying, modelling and documenting the business events that 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.
SSADM Tools, www.sqa.org.uk/e-learning/SDM01CD/page_03.htm
Benefits of SSADM
Timelines: Theoretically, SSADM allows one to plan, manage and control a project well. These points are essential to deliver the product on time.
Usability: Within SSADM special emphasis is put on the analysis of user needs. Simultaneously, the systems model is developed and a comprehensive demand analysis is carried out. Both are tried to see if they are well suited to each other.
Respond to changes in the business environment: As in SSADM documentation of the project's progress is taken very seriously, issues like business objectives and business needs are considered while the project is being developed. This offers the possibility to tailor the planning of the project to the actual requirements of the business.
Effective use of skills: SSADM does not require very special skills and can easily be taught to the staff. Normally, common modelling and diagramming tools are used. Commercial CASE tools are also offered in order to be able to set up SSADM easily.
Better quality: SSADM reduces the error rate of IS by defining a certain quality level in the beginning and constantly checking the system.
Improvement of productivity: By encouraging on-time delivery, meeting business requirements, ensuring better quality, using human resources effectively as well as trying to avoid bureaucracy, SSADM improves the overall productivity of the specific project and the company.
Cuts costs: SSADM separates the logical and the physical systems design. So the system does not have to be implemented again with new hard -or software.
Disadvantages of SSADM
SSADM puts special emphasis on the analysis of the system and its documentation. This causes the danger of over-analysing, which can be very time and cost consuming.8 Due to various types of description methods, checks of consistence cannot be carried out. Especially with large systems, the outline diagram can become very unclear, because all relevant data flows have to be included.
However, large companies carrying out various projects can profit from the fact that SSADM gives the possibility to reuse certain techniques and tools for other projects. This reduces cost and time spent enormously in the long run. So, the danger of spending too much, money on analysis can be compensated by the reuse of the developed systems and experience gained.
Marion Schumacher, 2001, The use of SSADM as a standard methodology on Information Systems Projects, http://www.grin.com/e-book/106034/the-use-of-ssadm-structured-systems-analysis-and-design-methodology-as, Date accessed: 24/1/10
System Development Life Cycle
System Lifecycles and SSADM, www.sharpertutorials.com/design-methodology-and-system-lifecycle/
Object Oriented Methodology
In simple terms, Object Modelling is based on identifying the objects in a system and their interrelationships
The Object Oriented Methodology of Building Systems takes the objects as the basis. For this, first the system to be developed is observed and analyzed and the requirements are defined as in any other method of system development. Once this is done, the objects in the required system are identified. For example in case of a Banking System, a customer is an object, a cheque book is an object, and even an account is an object.
It also follows a sequential process of system designing but with a different approach. The basic steps of system designing using Object Modelling may be listed as:
- System Analysis
- System Design
- Object Design
Advantages of the Object Oriented methodology
- Object Oriented Methodology closely represents the problem domain. Because of this, it is easier to produce and understand designs.
- The objects in the system are immune to requirement changes. Therefore, allows changes more easily.
- Object Oriented Methodology designs encourage more re-use. New applications can use the existing modules, thereby reduces the development cost and cycle time.
- Object Oriented Methodology approach is more natural. It provides nice structures for thinking and abstracting and leads to modular design.
Object Oriented Methodology Life Cycle Model,www.freetutes.com/systemanalysis/sa2-object-oriented-methodology.html
The project describes the creation of a new system to replace the previous. It is computerized, meaning that data will be saved in an intangible form. A database will be used to store all of the party's information. It will be based on a computer and will include information such as membership details, candidates, payments and the generation of reports.
Before the database could be designed however, the system was first analysed and designed. The object oriented methods were used throughout and allowed for a fast, accurate and reliable built system.
Firstly, use case diagrams were used in instances to determine how a task was completed and more importantly, who was responsible for doing so. This was done five times, as there were five specific tasks which must be functional. The specifications were done for each of the diagrams, which allowed for better understanding of the diagrams and gave a bit more detail to what would and could happen. Activity diagrams were also created so that the steps to the completion of tasks were very much understood, especially any decisions which might be needed.
The system was broken into parts and into classes. This allowed entities to be better understood so that their rolls could be defined, i.e. as attributes and operations. They were first determined/ named by drawing the actual diagram with their name, and then they were all defined through the use of attributes and operations. They were then defined a step further to complete the task. Lines were drawn to the classes based on hierarchy and used multiplicity (1 to many concept) to show a bit more description.
More analysis was done before the actual design. Diagrams such as sequence, communication and state machine were drawn so that even more understanding of the process was made.
After the diagrams were drawn, it basically signified the end of the analysis stage of the project. Legal issues pertaining to the system was researched and understood so that there would be no implications. The data protection laws, regulations and best practices were analysed so that there would be a better understanding as it applies to the computer system.
The prototype user interface for the new system was now needed in order to proceed. The interface is the face of the program and is a means of access to the entire program which has links to functions that the system must do. Adding a member, editing member details, receiving payments, searching for election candidates by county and listing the party's MP are some of the functions which were required to demonstrate the system's interface. Screenshots were taken for each of the functions, together with the actual change which was made. These were taken to prove the functionality of the system in document form.
Normalization is a technique used to design the database. It is usually done before the actual creation of the database so that the correct and best fields are used to support the system. There is first an unordered form, then a first normal form, then a second normal form and lastly a third normal form. Each form advances until the third form, which is used as the fields of tables within the database. The data dictionary is another tool used in the database design. It describes all the entries included in the database, identifying items such as: characters, names, purpose.
Object oriented methods were used in this project and comparisons were made to another methodology, called SSADM. Differences were explained and advantages and disadvantages were stated together with tools and modules. To complete the comparison, a table was drawn to show differences.
Throughout the project, assumptions were necessary and were made. First it was thought that the two paid members of each county share the various tasks and duties pertaining to the computer system. One paid member would deal with a portion of the tasks and duties and the other, a different portion.
The task of adding a new member to the system would be performed only when details are already filled out and the entry may be made at a later time.
To improve the outcome of this project, familiarisation of the scenario to the point of learning would have most definitely been an aid. Also, by understanding other methodologies (SSADM & Object Oriented) would have also assisted since comparisons were necessary in task four. This would have provided more time to other researching and tasks.
- author :unknown, December 2005, Ministry of Public Administration & Information, "NATIONAL POLICY ON DATA PROTECTION.", http://www.fastforward.tt/files/cms/Data%20Protection%20-%20Final%20Document.pd, Date accessed: 23/1/10
- author :unknown, December 2005, Ministry of Public Administration & Information, "NATIONAL POLICY ON DATA PROTECTION." , http://www.fastforward.tt/files/cms/Data%20Protection%20-%20Final%20Document.pdf , Date accessed: 23/1/10
- author :unknown, December 2005, Ministry of Public Administration & Information, "NATIONAL POLICY ON DATA PROTECTION." , http://www.fastforward.tt/files/cms/Data%20Protection%20-%20Final%20Document.pdf, Date accessed:23/1/10
- author :unknown, Nov 26th,System Lifecycles and SSADM, , www.sharpertutorials.com/design-methodology-and-system-lifecycle/, Date accessed: 24/1/10
- author :unknown, SSADM Tools, www.sqa.org.uk/e-learning/SDM01CD/page_03.htm, Date accessed:24/1/10
- Marion Schumacher, 2001, The use of SSADM as a standard methodology on Information Systems Projects, http://www.grin.com/e-book/106034/the-use-of-ssadm-structured-systems-analysis-and-design-methodology-as, Date accessed: 24/1/10
- author :unknown, Nov 26th, System Lifecycles and SSADM, www.sharpertutorials.com/design-methodology-and-system-lifecycle/, Date accesses: 24/1/10
- author :unknown Object Oriented Methodology Life Cycle Model,www.freetutes.com/systemanalysis/sa2-object-oriented-methodology.html, Date accessed: 24/1/10