IT Systems in Organizations (IB)
The IT personnel are those that deal with policy issues related to IT systems and also day to day running of IT systems (both hardware and software). They include:
Information system (IS) managers,
Play a vital role in the implementation and administration of technology within their organizations
Support staff
Aid users in days to day running of their computers
Network managers
Are responsible for designing, implementing and administering computer network systems within an organization or between organizations.
Both the network and system administrators work below them.
Most of the time they deal with troubleshooting simple hardware and software problems which users encounter in their daily usage of the computer
Database administrator
Are responsible for the performance, integrity and security of a database.
Chief information officers (CIO)
Are responsible for IT, IS and information strategy. They also align these to the needs of the business as a whole. They understand the impact of global digital economy and are usually part of organizations top management team. They plan, coordinate, and direct research on the computer-related activities of firms. In consultation with other managers, they help determine the goals of an organization and then implement technology to meet those goals. They oversee all technical aspect of an organization, such as software development, network security, and Internet operations.
The development personnel are those that deal the creation and deployment of IT systems in organization. They include:
Programmers
They code and develop a system in a computer programming language
System analysts
Specify the requirements for a system and the outline designs and solutions that will meet the requirements. Typically the are the interface and liaison between the business users / analysts and the programmers
Business analysts
Understand the complexity of the business and its needs and liaise with the system analyst. They are typically from the business side of the organization but adopt this role in the context of a particular development project for a specific period.
Project managers
Manage the project with particular emphasis on schedule and resources
Complex projects will require a systems analyst. A systems analyst is an information specialist who performs systems analysis, design, and implementation. His or her job is to study the information and communications needs of an organization and determine what changes are required to deliver better information to people who need it, when they need it. Better information means information that is accurate, timely, and useful. The systems analyst achieves this goal through the problem solving method of systems analysis and design (SDLC).
The SDLC has an enormous influence as a general approach to develop information systems. Although there are many variants, it has the following basic structure:
Feasibility study looks at the present system, the requirements that it was intended to meet, problems in meeting these requirements, new requirements that have come to light since it was first implemented and briefly investigates alternative solutions. These must be within the terms of reference (TOR), given to the analyst relating to the boundaries of the systems and the constraints particularly those associated with resources. The possible solutions proposed as outcomes could be:
Leave the system as it is
Improve the current system
Completely replace the current system
For each of these three possible outcomes the following descriptions are given:
Legal perspective
Organization and social perspective
Technical perspective
Economic perceptive
In summary, the following is done this stage:
a) Conduct preliminary analysis – includes stating objectives, defining nature and scope of the problem.
b) Propose alternative solution- includes making decisions such as leaving the system alone, making it more efficient, or build a new system
c) Description of cost and benefits of each solution.
d) Submit a preliminary plan with recommendations.
Analysis is used to get a clear idea of what the existing system does. With projects of any size, the analysis stage is essential because you can gain clear insight into data input, processing, and output without thinking about the computer system that may eventually be used.
This process is sometimes referred to (or sometimes taken to include) fact finding. The classic fact-finding methods are:
Conduct interviews
Carry out questionnaires
Study existing documents
Search the literature for other solutions to the same problem.
Observe people working with the existing system
Sample data taken from a carefully selected representation of the entire data source, if the data source is too large to be collected
Studying existing documents will give details of the data collected while questionnaires can be used to gain general information from many people. Interviews will yield more detailed information (from fewer people or using more time). One can also observe the existing system and take into account the views of users of the existing system and users of the service the system provides (e.g. in a supermarket one would talk to customers as well as managers and check-out assistants).
Although the use of data flow diagrams and use case scenarios is not a requirement of student dossiers, we find that their use gives students valuable insight into real-world problems and help in the identification of system modules.
Summary of Phase Two – Analysis phase In this phase, the following steps are taken:
a) Gathering data using tools of written documents, interviews, questionnaires, observations, and sampling.
b) Analyze the data, using data flow diagrams, systems flowcharts, connectivity diagrams , grid charts and decision tables
c) Write a report.
In the third phase, (systems design), the analyst first does a preliminary design, next a detail design then writes a report.
This describes the general functional capabilities of a proposed system. Usually several alternatives (candidates) are considered and the cost – benefit analysis done on each. Three tools may be used in this case:
i. Prototyping Tools: Prototyping refers to building a working model or experimental version of all or part of a system so that it can be quickly tested and evaluated. A prototype is a limited working system developed to test out design concepts. A prototype can also be said to be a mockup or developmental model of a system for test purposes. Prototyping tools are software packages that can be used to design screen displays.
ii. CASE Tools :CASE is Computer Aided Software Engineering. CASE Tools are software support tools that help in the information system development process. Examples are HyperAnalsyst, PacBase, Excelerator, Select Enterprise, Project 2000 and Application Development Workbench.
Project Management Software: This consists of programs used to plan, schedule and control the people, costs and resources required to complete a project on time. The software often uses Gantt and PERT charts.
A Gantt chart uses lines and bars to indicate the duration of a series of tasks. The time Scale may range from minutes to years. Gantt chart allows you to see weather tasks are being completed on schedule. (See previous notes on 3.9 Introduction to project management about how to construct Gantt charts)
iii. CPM (Critical Perth Method): This is whereby different ways (paths) to solving the project are considered. The path that represents the greatest time span is called the critical path.
A longer, detail explanation of what a critical path is follows: The difference between an activity’s earliest start date and its latest start date (or equally, the difference between its earliest and latest finish dates) is known as the activity’s float or slack. It is a measure of how much the start or completion of an activity maybe delayed without affecting the end date of the project. Any activity with a float of zero is critical in the sense that any delay in carrying out the activity, will delay the completion of the project as a whole. There will always at least one path through the network joining those critical activities; this is called the critical path.
A PERT (Program Evaluation & Review Technique) chart shows not only timing but also relationships among the tasks of a project. The relationships are presented by lines that connect boxes describing the tasks. PERT is based on project network diagrams or charts with a particular feature for estimating the elapsed time of activities. PERT method is very similar to CPM technique (many books refer to them interchangeably); but instead of using a single estimate for the duration of each task as CPM, PERT requires three estimates:
Most likely time
Optimistic time
Pessimistic time
PERT coverage as a software development technique seems a bit advanced for an IB course like ITGS; it is mostly covered in later stages of undergraduate course.
A detail design describes how the proposed information system will deliver the general capabilities described in the preliminary design. The following are usually considered output requirement, input requirements, storage requirement, processing requirement and systems control and backup.
Input Design
In this design the analyst considers the type of input devices to be used and how to validate and verify input data. In designing input records, the analyst usually considers the following controls or tests into the entry system:
i) Data verification
ii) Data Validation
Verification means making sure that the data on the source documents is exactly the same as that input to the computer system.
Validation means attempting to make sure that the data input into the system makes sense.
If it helps, remember that verification (ve) means making the data equal whereas validation (va) means checking if the data is acceptable.
Verification
There are two main methods in common use:
Visual verification (or proof-reading) which means... (can you guess?)
Double entry verification which involves having the data from the source document entered twice as a check. Typically the application will lock the keyboard and give an audible warning so that the data entry person can check carefully.
One of these methods is more reliable than the other.
Validation
Data entered into the computer can be unreasonable, a data entry person in a medical clinic can easily mistype a person’s weight, say or the number of cigarettes they smoke per day. This type of error is not caught by verification since the data may have been written down wrongly in the first place.
Validation Methods:
a) length checks: This assumes that the data has predetermined length. This normally involves string data types. If the number of characters do not match the valid number then this data is rendered invalid and rejected
b) type checks: Here the type of data entered is checked. This check ensures that numeric data is not entered in a name field or, conversely , alphabetic data into a numeric.
c) range checks: The assumption here is that there is an upper and lower limit of the target data (this normally involves currency values). Range check has the task of ensuring that out-of-range values are not permitted in as valid data.
d) Presence check: Normally when data is entered the analyst may have designed it to be entered with a special symbol at the end or beginning. The symbol may be a mark , a dot or just any special character. When data is being validated the presence of this symbol is an indication of valid data.
e) check digit test: A check digit is "a digit used for the purpose of performing a check". However, if you give this answer in an exam you should not expect any marks. A check digit is a digit (single number) calculated from another number, added to that number and entered into the computer as a validation check
This is a large detailed report. The report is normally accompanied with a presentation speech.
This phase consists of acquiring hardware and software then testing the system. Decision on hardware and software acquiring is of the form make-or-buy? There are two stages of testing:
a) Unit Testing: Here the individual parts of the program are tested using test (made up) data. Normally different sections (modules) are tested separately.
b) System Testing: Here the parts of the system are linked together and test data used to see if the parts work together. At this point actual firm’s data nay be used
There are other variants of testing, which usually refer to the specific type of test that needs to be performed on the system under development: they include, integration testing, acceptance testing, product testing, alpha testing and beta testing.
In the case of commercial of the shelf (COTS) software, as soon as product testing is complete, versions of the complete product are supplied to selected possible future clients for testing on site. The first such version is termed as alpha release and the testing done by these potential customers is called alpha testing. The corrected alpha release is called beta release; in general the beta release is intended to be close to the final version.
At the end of this long process, the organization will have a workable information systemone ready for implementation
This consists of converting the hardware, software and files to the new system and of training the users. Conversion may proceed in four ways: direct, parallel, phased, or pilot.
a) Direct approach: means the user simply stops using the old system and starts using the new system.
b) Parallel approach: means the old and new systems are operated side by side until the new system has shown it is reliable, at which time the old system is discontinued.
c) Phased approach: means that parts of the new system are phased in separately.
d) Pilot approach: means that the entire system is tried out but only by some users.
In general the phased and pilot approaches are the most favorable. Phased is good for a large organization in which people are performing different tasks while pilot is good where people are performing the same task.
Training of users involves writing user manuals, video presentation and live classes – both one –on-one and group classes.
This is the last phase and it deals with adjusting and improving the system through systems audit and periodic evaluation. Auditing means an independent review of an organization’s information system to see if all records and systems are as they should be. The analyst designs an audit trail. Audit trail is a designed system (method) that helps independent auditors trace the record of a transaction from its output back through all processing and storage to its source. Evaluation may be done by an accountant (through auditing), system analyst, user or the client (intended owner).
SSADM (Structured Systems Analysis and Design Methodology) is a methodology (Def. a system of ways of doing things especially regular and orderly procedures), used in the analysis and design stages of systems development. SSADM does not cover SITP issues or the construction, testing and implementation of software.
"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. The CCTA investigated a number of approaches before accepting a tender from Learmonth & Burchett Management Systems to develop a method." (Eva, SSADM Version 4 - A Users Guide)
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.
SSADM is managed by the CCTA, however the Design Authority Board (DAB) is responsible for maintaining and developing SSADM and the NCC (National Computing Centre) produce and maintain the definitive SSADM documentation.
SSADM revolves around the use of three key techniques, namely Logical Data Modelling, Data Flow Modelling and Entity/Event Modelling.
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 s represent Entities (things about which a business needs to record information) and Relationships (necessary associations between entities).
Data Flow Modelling; 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. DFDs 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.
The success of SSADM may lie in the fact that it does not rely on a single technique. Each of the three system models provides a different viewpoint of the same system, each of which are required to form a complete model of the system. Within SSADM each of the three techniques are cross reference against each other to ensure the completeness and accuracy of the complete model.
SSADM consists of 5 main modules, which are in turn broken down into a complex hierarchy of stages, steps and tasks. slide 11
Feasibility Study; Module 1 the feasibility study consists of a single stage (Stage 0 Feasibility),which involves conducting a high level analysis of a business area to determine whether a system can cost effectively support the business requirements. In stage 0 an overview DFD is produced together with a high level LDS. At this stage the DFD will represent the existing system warts and all and the LDS may be incomplete and contain unresolved M:M relationships.
Requirements Analysis; Module 2 requirements analysis consists of 2 stages; Stage 1 Investigation of Current Environment and Stage 2 Business System Options (BSO). During stage 1 the systems requirements are identified and the current business environment is modelled in terms of the processes carried out and the data structures involved. During stage 1 DFDs and an LDS are used to produce detailed logical models of the current system During stage 2 up to 6 business system options are produced and presented. As a result one of these options (or indeed a hybrid solution) is adopted and refined. During stage 2 DFDs and LDS are produced to support each business system option and the final chosen option. The transition from stage 1 to stage 2 is a key part of SSADM, this is where we move from a logical model of the current system to a logical model of the required system, i.e. this is where the DFDs and LDS have to be refined to cater new/changed requirements.
Requirements Specification; Module 3 Requirements Specification consists of a single stage (Stage 3 Definition of Requirements) which involves further developing the work carried out in module 2, detailed functional and nonfunctional requirements are identified and new techniques are introduced to define the required processing and data structures. In stage 3 the DFDs and LDS are refined and cross validated in the light of the chosen business system option. The LDS is enhanced using relational data analysis (normalisation). The DFDs and LDS are validated against the ELHs also produced during this stage. DFDs LDS and ELHs are used as input to the subsequent stages of SSADM.
4. Logical System Specification; Module 4 Logical System Specification consists of 2 stages; Stage 4 Technical System Options and Stage 5 Logical Design. In stage 4 up to 6 technical options (specifying the development and implementation environments) are produced, one being selected. In stage 5 the logical design of update and enquiry processing and system dialogues (menus etc.) is carried out.
5. Physical Design; Module 5 Physical Design consists of a single stage (Stage 6 Physical Design) in which the logical system specification and technical system specification are used to create a physical database design and a set of program specifications.
The IT personnel are those that deal with policy issues related to IT systems and also day to day running of IT systems (both hardware and software). They include:
Information system (IS) managers,
Play a vital role in the implementation and administration of technology within their organizations
Support staff
Aid users in days to day running of their computers
Network managers
Are responsible for designing, implementing and administering computer network systems within an organization or between organizations.
Both the network and system administrators work below them.
Most of the time they deal with troubleshooting simple hardware and software problems which users encounter in their daily usage of the computer
Database administrator
Are responsible for the performance, integrity and security of a database.
Chief information officers (CIO)
Are responsible for IT, IS and information strategy. They also align these to the needs of the business as a whole. They understand the impact of global digital economy and are usually part of organizations top management team. They plan, coordinate, and direct research on the computer-related activities of firms. In consultation with other managers, they help determine the goals of an organization and then implement technology to meet those goals. They oversee all technical aspect of an organization, such as software development, network security, and Internet operations.
The development personnel are those that deal the creation and deployment of IT systems in organization. They include:
Programmers
They code and develop a system in a computer programming language
System analysts
Specify the requirements for a system and the outline designs and solutions that will meet the requirements. Typically the are the interface and liaison between the business users / analysts and the programmers
Business analysts
Understand the complexity of the business and its needs and liaise with the system analyst. They are typically from the business side of the organization but adopt this role in the context of a particular development project for a specific period.
Project managers
Manage the project with particular emphasis on schedule and resources
Complex projects will require a systems analyst. A systems analyst is an information specialist who performs systems analysis, design, and implementation. His or her job is to study the information and communications needs of an organization and determine what changes are required to deliver better information to people who need it, when they need it. Better information means information that is accurate, timely, and useful. The systems analyst achieves this goal through the problem solving method of systems analysis and design (SDLC).
The SDLC has an enormous influence as a general approach to develop information systems. Although there are many variants, it has the following basic structure:
Feasibility study looks at the present system, the requirements that it was intended to meet, problems in meeting these requirements, new requirements that have come to light since it was first implemented and briefly investigates alternative solutions. These must be within the terms of reference (TOR), given to the analyst relating to the boundaries of the systems and the constraints particularly those associated with resources. The possible solutions proposed as outcomes could be:
Leave the system as it is
Improve the current system
Completely replace the current system
For each of these three possible outcomes the following descriptions are given:
Legal perspective
Organization and social perspective
Technical perspective
Economic perceptive
In summary, the following is done this stage:
a) Conduct preliminary analysis – includes stating objectives, defining nature and scope of the problem.
b) Propose alternative solution- includes making decisions such as leaving the system alone, making it more efficient, or build a new system
c) Description of cost and benefits of each solution.
d) Submit a preliminary plan with recommendations.
Analysis is used to get a clear idea of what the existing system does. With projects of any size, the analysis stage is essential because you can gain clear insight into data input, processing, and output without thinking about the computer system that may eventually be used.
This process is sometimes referred to (or sometimes taken to include) fact finding. The classic fact-finding methods are:
Conduct interviews
Carry out questionnaires
Study existing documents
Search the literature for other solutions to the same problem.
Observe people working with the existing system
Sample data taken from a carefully selected representation of the entire data source, if the data source is too large to be collected
Studying existing documents will give details of the data collected while questionnaires can be used to gain general information from many people. Interviews will yield more detailed information (from fewer people or using more time). One can also observe the existing system and take into account the views of users of the existing system and users of the service the system provides (e.g. in a supermarket one would talk to customers as well as managers and check-out assistants).
Although the use of data flow diagrams and use case scenarios is not a requirement of student dossiers, we find that their use gives students valuable insight into real-world problems and help in the identification of system modules.
Summary of Phase Two – Analysis phase In this phase, the following steps are taken:
a) Gathering data using tools of written documents, interviews, questionnaires, observations, and sampling.
b) Analyze the data, using data flow diagrams, systems flowcharts, connectivity diagrams , grid charts and decision tables
c) Write a report.
In the third phase, (systems design), the analyst first does a preliminary design, next a detail design then writes a report.
This describes the general functional capabilities of a proposed system. Usually several alternatives (candidates) are considered and the cost – benefit analysis done on each. Three tools may be used in this case:
i. Prototyping Tools: Prototyping refers to building a working model or experimental version of all or part of a system so that it can be quickly tested and evaluated. A prototype is a limited working system developed to test out design concepts. A prototype can also be said to be a mockup or developmental model of a system for test purposes. Prototyping tools are software packages that can be used to design screen displays.
ii. CASE Tools :CASE is Computer Aided Software Engineering. CASE Tools are software support tools that help in the information system development process. Examples are HyperAnalsyst, PacBase, Excelerator, Select Enterprise, Project 2000 and Application Development Workbench.
Project Management Software: This consists of programs used to plan, schedule and control the people, costs and resources required to complete a project on time. The software often uses Gantt and PERT charts.
A Gantt chart uses lines and bars to indicate the duration of a series of tasks. The time Scale may range from minutes to years. Gantt chart allows you to see weather tasks are being completed on schedule. (See previous notes on 3.9 Introduction to project management about how to construct Gantt charts)
iii. CPM (Critical Perth Method): This is whereby different ways (paths) to solving the project are considered. The path that represents the greatest time span is called the critical path.
A longer, detail explanation of what a critical path is follows: The difference between an activity’s earliest start date and its latest start date (or equally, the difference between its earliest and latest finish dates) is known as the activity’s float or slack. It is a measure of how much the start or completion of an activity maybe delayed without affecting the end date of the project. Any activity with a float of zero is critical in the sense that any delay in carrying out the activity, will delay the completion of the project as a whole. There will always at least one path through the network joining those critical activities; this is called the critical path.
A PERT (Program Evaluation & Review Technique) chart shows not only timing but also relationships among the tasks of a project. The relationships are presented by lines that connect boxes describing the tasks. PERT is based on project network diagrams or charts with a particular feature for estimating the elapsed time of activities. PERT method is very similar to CPM technique (many books refer to them interchangeably); but instead of using a single estimate for the duration of each task as CPM, PERT requires three estimates:
Most likely time
Optimistic time
Pessimistic time
PERT coverage as a software development technique seems a bit advanced for an IB course like ITGS; it is mostly covered in later stages of undergraduate course.
A detail design describes how the proposed information system will deliver the general capabilities described in the preliminary design. The following are usually considered output requirement, input requirements, storage requirement, processing requirement and systems control and backup.
Input Design
In this design the analyst considers the type of input devices to be used and how to validate and verify input data. In designing input records, the analyst usually considers the following controls or tests into the entry system:
i) Data verification
ii) Data Validation
Verification means making sure that the data on the source documents is exactly the same as that input to the computer system.
Validation means attempting to make sure that the data input into the system makes sense.
If it helps, remember that verification (ve) means making the data equal whereas validation (va) means checking if the data is acceptable.
Verification
There are two main methods in common use:
Visual verification (or proof-reading) which means... (can you guess?)
Double entry verification which involves having the data from the source document entered twice as a check. Typically the application will lock the keyboard and give an audible warning so that the data entry person can check carefully.
One of these methods is more reliable than the other.
Validation
Data entered into the computer can be unreasonable, a data entry person in a medical clinic can easily mistype a person’s weight, say or the number of cigarettes they smoke per day. This type of error is not caught by verification since the data may have been written down wrongly in the first place.
Validation Methods:
a) length checks: This assumes that the data has predetermined length. This normally involves string data types. If the number of characters do not match the valid number then this data is rendered invalid and rejected
b) type checks: Here the type of data entered is checked. This check ensures that numeric data is not entered in a name field or, conversely , alphabetic data into a numeric.
c) range checks: The assumption here is that there is an upper and lower limit of the target data (this normally involves currency values). Range check has the task of ensuring that out-of-range values are not permitted in as valid data.
d) Presence check: Normally when data is entered the analyst may have designed it to be entered with a special symbol at the end or beginning. The symbol may be a mark , a dot or just any special character. When data is being validated the presence of this symbol is an indication of valid data.
e) check digit test: A check digit is "a digit used for the purpose of performing a check". However, if you give this answer in an exam you should not expect any marks. A check digit is a digit (single number) calculated from another number, added to that number and entered into the computer as a validation check
This is a large detailed report. The report is normally accompanied with a presentation speech.
This phase consists of acquiring hardware and software then testing the system. Decision on hardware and software acquiring is of the form make-or-buy? There are two stages of testing:
a) Unit Testing: Here the individual parts of the program are tested using test (made up) data. Normally different sections (modules) are tested separately.
b) System Testing: Here the parts of the system are linked together and test data used to see if the parts work together. At this point actual firm’s data nay be used
There are other variants of testing, which usually refer to the specific type of test that needs to be performed on the system under development: they include, integration testing, acceptance testing, product testing, alpha testing and beta testing.
In the case of commercial of the shelf (COTS) software, as soon as product testing is complete, versions of the complete product are supplied to selected possible future clients for testing on site. The first such version is termed as alpha release and the testing done by these potential customers is called alpha testing. The corrected alpha release is called beta release; in general the beta release is intended to be close to the final version.
At the end of this long process, the organization will have a workable information systemone ready for implementation
This consists of converting the hardware, software and files to the new system and of training the users. Conversion may proceed in four ways: direct, parallel, phased, or pilot.
a) Direct approach: means the user simply stops using the old system and starts using the new system.
b) Parallel approach: means the old and new systems are operated side by side until the new system has shown it is reliable, at which time the old system is discontinued.
c) Phased approach: means that parts of the new system are phased in separately.
d) Pilot approach: means that the entire system is tried out but only by some users.
In general the phased and pilot approaches are the most favorable. Phased is good for a large organization in which people are performing different tasks while pilot is good where people are performing the same task.
Training of users involves writing user manuals, video presentation and live classes – both one –on-one and group classes.
This is the last phase and it deals with adjusting and improving the system through systems audit and periodic evaluation. Auditing means an independent review of an organization’s information system to see if all records and systems are as they should be. The analyst designs an audit trail. Audit trail is a designed system (method) that helps independent auditors trace the record of a transaction from its output back through all processing and storage to its source. Evaluation may be done by an accountant (through auditing), system analyst, user or the client (intended owner).
SSADM (Structured Systems Analysis and Design Methodology) is a methodology (Def. a system of ways of doing things especially regular and orderly procedures), used in the analysis and design stages of systems development. SSADM does not cover SITP issues or the construction, testing and implementation of software.
"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. The CCTA investigated a number of approaches before accepting a tender from Learmonth & Burchett Management Systems to develop a method." (Eva, SSADM Version 4 - A Users Guide)
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.
SSADM is managed by the CCTA, however the Design Authority Board (DAB) is responsible for maintaining and developing SSADM and the NCC (National Computing Centre) produce and maintain the definitive SSADM documentation.
SSADM revolves around the use of three key techniques, namely Logical Data Modelling, Data Flow Modelling and Entity/Event Modelling.
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 s represent Entities (things about which a business needs to record information) and Relationships (necessary associations between entities).
Data Flow Modelling; 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. DFDs 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.
The success of SSADM may lie in the fact that it does not rely on a single technique. Each of the three system models provides a different viewpoint of the same system, each of which are required to form a complete model of the system. Within SSADM each of the three techniques are cross reference against each other to ensure the completeness and accuracy of the complete model.
SSADM consists of 5 main modules, which are in turn broken down into a complex hierarchy of stages, steps and tasks. slide 11
Feasibility Study; Module 1 the feasibility study consists of a single stage (Stage 0 Feasibility),which involves conducting a high level analysis of a business area to determine whether a system can cost effectively support the business requirements. In stage 0 an overview DFD is produced together with a high level LDS. At this stage the DFD will represent the existing system warts and all and the LDS may be incomplete and contain unresolved M:M relationships.
Requirements Analysis; Module 2 requirements analysis consists of 2 stages; Stage 1 Investigation of Current Environment and Stage 2 Business System Options (BSO). During stage 1 the systems requirements are identified and the current business environment is modelled in terms of the processes carried out and the data structures involved. During stage 1 DFDs and an LDS are used to produce detailed logical models of the current system During stage 2 up to 6 business system options are produced and presented. As a result one of these options (or indeed a hybrid solution) is adopted and refined. During stage 2 DFDs and LDS are produced to support each business system option and the final chosen option. The transition from stage 1 to stage 2 is a key part of SSADM, this is where we move from a logical model of the current system to a logical model of the required system, i.e. this is where the DFDs and LDS have to be refined to cater new/changed requirements.
Requirements Specification; Module 3 Requirements Specification consists of a single stage (Stage 3 Definition of Requirements) which involves further developing the work carried out in module 2, detailed functional and nonfunctional requirements are identified and new techniques are introduced to define the required processing and data structures. In stage 3 the DFDs and LDS are refined and cross validated in the light of the chosen business system option. The LDS is enhanced using relational data analysis (normalisation). The DFDs and LDS are validated against the ELHs also produced during this stage. DFDs LDS and ELHs are used as input to the subsequent stages of SSADM.
4. Logical System Specification; Module 4 Logical System Specification consists of 2 stages; Stage 4 Technical System Options and Stage 5 Logical Design. In stage 4 up to 6 technical options (specifying the development and implementation environments) are produced, one being selected. In stage 5 the logical design of update and enquiry processing and system dialogues (menus etc.) is carried out.
5. Physical Design; Module 5 Physical Design consists of a single stage (Stage 6 Physical Design) in which the logical system specification and technical system specification are used to create a physical database design and a set of program specifications.
