A History Of Structured Systems Analysis & Design Methodologies
Dr. Vicki Sauter
What is SSADM ?
Sometimes referred to as SSADM is “a set of standards developed in the early 1980s for systems analysis and application design. “ SSADM uses a combination of text and diagrams throughout the whole life cycle of a system, from the initial design idea to the actual physical design of the application.” (1) . In general, large-scale system computing for the management of accounting, billing and human resource functions emerged in the mid 1970s. At the time, there were no standardized development methodologies to follow. Most requirements analysis was performed on an ad-hoc basis and mainly depended on the impressions of small groups of people. Often this resulted in systems that did not meet the requirements of the business units.
Why SSADM ?
SSADM was sought to help reduce the lifecycle development costs through improved and enhanced design and development. SSADM was also believed to improve the quality of the systems it delivered. It was also thought to improve project management planning and control as well as provide more effective control of inexperienced staff. SSADM suggested an improvement in global understanding and communication. SSADM, by its emphasis on thorough documentation was supposed to assure project stakeholders that system documentation would take a more prominent role. (2)
1970s pre SSADM – First Generation (Classical) Methodologies
In the 1970s the “first generation methodologies” of structured analysis attempted to mainly create a computerized model of the administrative functions of the typical office. “Computerized systems were seen as having the same structure and functions as the manual systems and consequently, the underlying idea was simply to model the existing system and then design a computerized version it. “ (3) These “semi formal” design strategies and methodologies of the 1970s focused on mimicking the logical flows of the business. Systems designers acknowledged an incompleteness with this approach. Kimble describes it as having “an anti-realist ontology and rationalist epistemology” (3). This refers to design strategies that rationalized and approximated logical flows believing that “through the application of reason we can begin to make reality more explicable. “(3). The anti-realist ontology refers to the shortcomings of these first generation methodologies to reach outside of the logical for design ideas and guidance. The first generation methodologies required documentation that spelled out the document flows and the functional requirements in detailed terms. Edward Yourdon published his first criticisms of traditionalist approaches in his 1979 book “Structured Design”.
Criticisms of Classical Systems Analysis Approaches:
Classical Methods Were Monolithic:
Functional specifications were a large and often cumbersome required document for the early design methods. The specifications dealt with the entire system and therefore required that the developers had to understand them in their entirety. “If you didn’t read the last page, you had little idea of how the story would end.” (8) This shortcoming hindered emerging design approaches that sought a more modular approach to design where user may have sought an understanding of one of the building blocks of the system without necessarily needing to understand the others (6).
Classical Methods Contained Redundancies :
Information was often repeated several times in different sections of the functional requirement document. Consider that when the user requirements changed, the adjustments would need to be made in several different areas of the functional specifications document. In the early 1960s updates and revisions could prove to be a challenge in the absence of the word processing capabilities of today (6).
Classical Methods Contained Inconsistencies:
Redundancy and the need to revise several areas of the functional document often created the related problems of inconsistency. Several revisions that needed to follow through to several different sections of the functional document often meant occasional errors. Sections that had not been updated correctly caused inconsistencies.
Classical Methods Were Ambiguous:
Detailed user requirements were sometimes interpreted differently by users.
Classically Based Systems Were Difficult To Maintain: Functional specifications were often obsolete by the end of the systems development process. Since the design methodology did not consider modular operations, it became more complicated to maintain and update without the guidance of the original documents which, would also by then no longer represent the major functions adequately.
1980s – SASD and SSADM in Evolution:
The shortcomings of the classical approaches were in debate in the early 1980s and studies that suggested new ideas were beginning to take center stage. These new ideas espoused the need for more modular design methods that allowed programmers insight into sections of the process rather than the process as a whole. This new approach was generally referred to as SASD for systems analysis and systems design. The evolution generally emerged at the time of the migration from the legacy systems to the newer object oriented (OOP) approaches. Unfortunately these changes led to a new complexity where several different information professionals too often understood only pieces rather than the system as a whole. A new emphasis on a more wholesome graphic breakdown of the system with partitioned sections that reduced redundancy emerged. DeMarco in his 1978 book “Structured Analysis” argued against the use of several classical approaches citing the complexity and volume of functional requirements.
DeMarco claimed (to some debate) that developers were not fully engaged in reviewing the functional requirements which was causing final product to lack in adherence to the original requirements (5). Edward Nash Yourdon in his 1989 book – Modern Structured Analysis, fully claimed to be replacing the “Top Down” approach of classical systems analysis with a more event-driven process illustrated in the graphic of the Data Flow Diagram. Modern structured analysis uses functional decomposition, data flow diagrams, process descriptions and a data dictionary to model information systems. (9). Yourdon’s approach detailed out steps as follows A physical model of the existing system was created using data flow diagrams and supporting documentation. Then, the physical details were removed from the diagrams and supporting documentation to produce a logical model of the existing system. Finally, changes were made and functions were added to the logical model of the existing system.
Criticisms of SASD Methodologies:
SASD was Time Consuming:
The weaknesses of the new SASD methodologies began to emerge. Developers considered the process of modeling the existing physical system and then stripping away those very same physical components prior to creating a logical model and then modifying the logical model as too time consuming.
SASD Retained Unnecessary Ties To The Old System:
There was also the retention of many unnecessary artifacts from the existing system which made the old system the foundation for the newer system. This was fine if the older system had not been originally flawed or ill performing.
Data Flow Diagramming Methods Differed:
Data flow diagrams were useful but lacked a guideline or standard for their creation. Different developers and analysts working on the same system came up with very different ways of developing them and therefore confusing impressions of the requirements of the new system. These competing views of the system and its interactions caused costly reworking efforts to bring different teams on the same page.
The main techniques encompassed by SSADM include Logical Data Modeling where the process data requirements are identified, modeled and documented. (4). The system’s data are then separated into entities (system players and actors) and relationships (the associations between the entities). There is also Data Flow Modeling where the data movements around the information system are identified, modeled and documented. Data Flow Modeling examines the processes; activities that transform data from one form to another; the data stores and the external entities which are the external sources of data for the system. It also looks at the data flows and directions in which the data move. This was adopted from the prior models set forth by Yourdon and DeMarco. Finally there is Entity Behavior Modeling which is the process of identifying, modeling and documenting the events that affect each entity and the sequence in which these events occur (4).
Here we look at two of the graphical development tools supported by SSADM. The Event List outlines the interactions between different events in a system and their relationships with one another. Edward Yourdon and Tom DeMarco are proponents of the use of several graphical tools to define clear event lists to direct the development of systems. The Entity Relationship diagram addresses the relationships between the different actors within a system. “Information Engineering” was a book published by Finkelstein and Martin that also considered data modeling and graphical tools of utmost importance when creating a system (7). They considered them critical to achieving the goals of SSADM. Finklestein’s and Martin’s approaches to graphical representations are widely in use in the United States. Finklestein defines entities in the designer’s sense of representing "data to be stored for later reference" (8) while Martin refers to entities “as something (real or abstract) about which we store data." (9).
Simple Yourdon/DeMarco Event Lists
Finkelstein’s Entity Relationship Diagram
1980s UK Government’s Commissioning of SSADM
In the 1980s the Central Computer Technology Agency CCTA (UK) was the first agency to explore and evaluate analysis and design methods. At the time, Yourdon’s approaches were widely in use and represented the standard for structured analysis. In spite of the use of a preferred standard, there was a widespread perception of failure on the part of several information technology projects. The large scale technology projects that various government agencies were involved in had suffered from this perception. Cost overruns were common and gaps between the requirements and functionality had exposed the need for a standard. To reduce the costly waste which was occurring at the time, the CCTA sought out a more representative methodology.
The CCTA which oversees various UK government projects, commissioned a proposal from the Learmonth and Burchett Management Systems group (LBMS) as a basis for the design of SSADM. LBMS won out over four other management firms and began to flesh out a wholesome design methodology based on their prior work. The final product was released in 1981 as the first version of SSADM. The CCTA commission had required specific adherences for their model (Appendix A) which LBMS had appropriately taken into consideration. In 1983 SSADM was made mandatory for all government projects in the UK.
Structuring Of SSADM
SSADM has some common phases that facilitate the movement from concept to prototype to finished product. The feasibility study is a high level overview of the project and its benefits. What the project hopes to accomplish and the problems it proposes to resolve. Cost benefit analysis of the project usually takes place at this stage. Once the project has been agreed upon and the requirements analysis phase begins where an investigation of the technological and business options is undertaken. The purpose of the requirements phase is to examine the objectives of the project and propose long term and cost effective solutions. At this time, the systems developers familiarize themselves with the technical jargon of the business areas while reviewing the data requirements and system’s needs. Users are heavily involved in this phase of the development process. There is often a clear reliance on the comparison of the functionality of the current system to the new system being proposed. Specifications and requirements write up is the next stage in the creation of the new system. At this point, detailed graphical documents that explore and document the relationships between the players and the system are created. The choice is made for which development option best meets the needs of the users. The logical system specification design begins and involves a cost benefit analysis of the hardware options. The logical design of the new system also begins to take place. The databases, update and delete functions and the methods of handling system inquiries are all placed into model. Finally the physical design stage is reached where both the data and the processing options are converted into a design that will run on the targeted system. (9).
1990s – SSADM vs DSDM and other 4th Generation Tools
The 1990s saw rapid emergence of new software development methods that questioned the necessity of the “slow and thorough” approaches of the eighties . SSADM is considered a thorough method of creating a system from the ground up but some of the newer development methods are bypassing several steps for the sake of expediency (11). Agile and RAD (Rapid Application Development) make use of some of the facets of SSADM but transition much faster and more directly into the development phase. Keith Richards of KRS consultants cites the DSDM (Dynamic Software Development Methods) as being the alternative to SSADM techniques. SSADM is considered a methodology borne out of waterfall while DSDM is a rapid development technique. Pat Phelan seems to agree with this and he argues that
“SSADM (Structured Systems Analysis and Design Methodology) is based on the traditional Structured Programming techniques. It uses a formal design process that is a direct descendant of the "waterfall" methodologies. This process tends to be relatively slow, but because the process tends to be exhaustive in both finding and debating every reasonable need, the results tend to be large and cumbersome, but thorough.” Pat also does acknowledge a major shortcoming of rapid application design which is that the product often does not hold up well over time. (12).
“SSADM.” Webopedia. internet.com. 2011. Octoberr 5, 2011 http://www.webopedia.com/TERM/S/SSADM.html
2. Goodland, Mike and Riha, Carol. “SSADM – An Introduction”. 1/20/1999 http://www.dcs.bbk.ac.uk/~steve/1/
Kimble, Chris. System Design Methodologies (SDM) Semi Formal Methodologies: The First Generation Methodologies. chris-kimble.com. November 5, 2011. http://www.chris-kimble.com/Courses/sdm/Session_5.html
4. Watkins, Glynn. Lecture 8 - The Stages Of SSADM. Bristol University Of West England. October 5, 2011.
5. DeMarco,Tom. Structured Analysis and System Specification. New York: YOURDON Press, 1978
6. Edward Yourdon and Larry L. Constantine. Structured Design: Fundamentals of a Discipline of Computer Program and System Design , 1979.
7. Martin, James and Clive Finkelstein. Nov 1981. "Information Engineering", Technical Report. Lancs, UK : Savant Institute, Carnforth.
8. Clive Finkelstein. Nov 1992. Strategic Systems Development. Sydney: Addison-Wesley
9. Martin, James, and Carma McClure. 1985. Diagramming techniques for Analysts and Programmers. Englewood Cliffs, NJ: Prentice Hall.
10. Winter, 1998. "Making Data Models Readable". Information Systems Management. 15, Boca Raton, FL: CRC Press.
11. Brown, Robert G.. 1993. "Data Modeling Methodologies – Contrasts in Style". Handbook of Data Management. Boston: Auerbach.
12. University Of Aberdeen. Structured Systems Analysis and Design Methods. CS5540. Scotland. October 15, 2011. www.csd.abdn.ac.uk/~jmasthof/teaching/CS5540/.../lecture9.ppt
13. Richards, Keith. DSDM and XP On Reflection: KRC Consultants. 2011 http://www.keithrichardsconsulting.co.uk/site/about/latest/dsdm_and_xp_article.html
14. Phelan, Pat. Search Oracle. Using SSADM and DSDM for rapid application development. November
The use of SSADM (Structured Systems Analysis and Design Methodology) as a standard methodology on Information Systems Projects. GRIN. http://www.grin.com/en/e-book/106034/the-use-of-ssadm-structured-systems-analysis-and-design-methodology-as