SSADM and CASE tools for project management
What does SSADM stand for?
- SSADM stands for Structured Systems Analysis and Design Method
- You can think of it of organising where people are at certain times and what activities people need to be doing.
Extract from theteacher.info
- How does a Project Manager go about managing a project? She will almost certainly use a project methodology!
- Methodologies are formal ways of doing things. SSADM is a project management methodology.
- According to the British Computing Society's 'A Glossary of Computing Terms', SSADM is "a standard method of analysis and design of large-scale software packages used within Government departments in the UK".
- It has been used in a wide range of project situations.
Why SSADM helps projects
- SSADM helps structure a project into manageable chunks. It breaks the project down into a very clear set of stages. This facilitates better estimation, management and control of costs and time.
- For each stage, there are well-defined activities that must take place. For each activity, there are clear deliverables that must be produced (diagrams that must be produced, letters that must be written and signed, lists and so on). All the required deliverables must be completed and signed off before the next stage in a project can start. Deliverables (for example Data Flow Diagrams, Entity Life Histories and E-R diagrams) are produced to tightly defined standards that ensure they are precise and clear to all.
- If any change takes place in the project, for example, the customer adds an extra feature to the project then there are clear procedures and paperwork that must accompany any change. SSADM promotes teamwork because employees are all using the same methodology. CASE tools are commonly used to aid SSADM.
How SSADM is different to a project life cycle.
- In the Systems Development Life Cycle chapter, a project was found to have distinct stages. One way to summarise the stages is to split them up under the headings: Feasibility study, Systems analysis, Design, Implementation (of the design), Testing, Installation and Maintenance.
- SSADM is very closely related to the project life cycle model shown above. There are some differences, however. For example, there is no SSADM stage that relates directly to the 'Implementation' stage in the life cycle. Having said that, many of the activities in SSADM can be mapped to the project life cycle. Certainly, many of the activities and documents produced in the project life cycle (which we have already discussed) appear as part of the SSADM methodology. SSADM can be summarised as comprising of the following stages: Feasibility study, Requirements analysis, Requirements specification, Logical design and Physical design.
SSADM and CASE tools
- We have already said that SSADM is a methodical approach to project development. It splits up projects into stages. It lays down rules about what must be done in each stage. Documentation is tightly defined and cross-checking and cross-referencing is a key feature of this approach. The approach of SSADM makes it an ideal target for computer programs. Why not write a program that allows a Project Manager to manage the stages in SSADM on computer? A program that does this is known as a CASE (Computer Aided Software Engineering) tool and there are various CASE tools on the market, such as SELECT SSADM. CASE tools help Project Managers using a methodology such as SSADM in many ways. These include the following:
- Templates are pre-defined. This promotes standard documents and cuts down the time to produce documents such as a DFD. In addition, standard naming conventions are used across all documents.
- Not only are documents pre-defined but also one document can be used to start off another document. For example, when a DFD level zero diagram (the context diagram) is drawn, the start of the level one diagram is automatically generated with the correct number of data flows into and out of the system.
- Cross-checking can take place. If someone makes a change in one document then the CASE tool can flag up where any changes should be made in other documents.
- If a Project Manager leaves a project then another will take over. By using an 'industry standard' methodology it should be easy for a new manager to take over. If the new manager had to pick up a project that followed an unfamiliar methodology, it would take time to learn.
Prototyping
- One particularly effective technique at the disposal of a systems analyst/designer is the use of prototyping. This is where a designer makes a simplified version of a program to illustrate how the final product might look and feel.
- A prototype may show a customer or others in a design team what input screens might be present, what the reports may look like and what functions would be available. Many of the features may not work but it is a very good way of illustrating to a customer what the designers are think of. You may well use this approach for parts of coursework!
- There are often marks available in coursework for considering different approaches and showing good user involvement. What better way of providing evidence of these things than a number of prototypes! Once you have decided and justified a particular approach, you can then refine it in the light of feedback from your customer.
- Prototyping could be used to help you develop a Requirements Specification. It could also be used in the design section, to involve the user in the final ‘look’ and ‘feel’ of the product.
- The prototyping approach is also known as the Rapid Application Development methodology.
Pros of RAD (prototyping method)
- You can quickly explore and compare a range of approaches by developing a number of prototypes.
- Prototyping can help in the production of a clear Requirements Specification because it can be used as an aid to discussion. This is especially true when technical people and non-technical people need to communicate together. The final specification can be refined through discussion and feedback.
- It can be used in the design section to involve the user in the product at all stages, for example, in the detail of how a report will be laid out. Involving your user as much as possible is a good way of ensuring that mistakes or 'nasty surprises' in the end product don't happen because your user will be able to highlight them with you at one of your regular meetings.
- It's possible, of course, that the prototypes you put together one afternoon will give your customer the wrong idea of how long it will take to do the final product! For example, it might only take an afternoon to put together some input screens with function buttons on them in Access. Actually coding up the function buttons so they carry out the functions they're supposed to may involve weeks of design, coding and testing!
The importance of Documentation
- System designers use documents. Documents are useful tools for a number of reasons. They summarise data, bringing it together into a compact form.
- Diagrams aid understanding. A designer can visualise what is happening in a Data Flow Diagram, for example, a lot easier than a number of written down steps. Diagrams act as a discussion tool between team members. A first-draft E-R Diagram, for example, can be used in a meeting to discuss whether it is the best design for a project or to see if anything has been missed out.
- Documents can be used to help a new team member pick up a project in the middle of it. Technical documents can go in the Technical Manual. If system maintenance is needed in the future then they will greatly assist whoever is doing the maintenance. The design team can use diagrams when they meet customers. Customers are not designers and designers do not know the customer's business as well as the customer does.
- Diagrams can help bring the customer and designers together. They can have a discussion around a diagram that they all can understand.