SSADM was commissioned by the UK government to supply formal methods for software design on government projects. Structured Systems Design Methodology was developed by Learmonth and Burchett Management Systems through the 1980s and is now an open standard published as British Standard BS7738. LBMS later developed its own version of the methodology as a basis of an early CASE system. Computer-aided Software Engineering applications benefit from the establishment of a sequential template like SSADM.
The government specification of SSADM as a requirement for project planning on government IT contracts helped the methodology take root in the computing industry. This gave British computing an advantage in that UK universities included the methodology into their IT courses, further promoting a national and industry standard for software design. Thus SSADM established a pool of IT professionals who were conversant with an endorsed methodology. This created flexibility in the supply of Systems Analysts and put the UK’s software industry ahead of European rivals. SSADM subsequently evolved into a “Euromethod” which spread the standard across the EU. However, UK Systems Analysts were already experienced with the methodology, which put them ahead of their European counterparts.
As its name implies, SSADM is both “structured” and “methodical.” The designated sequence of steps laid down in the methodology forces analysts to cycle through a sequence of steps. This removes the temptation to cut corners. The existence of a set path also enables analysts to resist management pressure to speed up, or shortcut the software requirements definition process.
Unlike other formal methods for software design, SSADM cannot be truncated into parallel tasks. The results of each phase of analysis feed into the next phase. This is a weakness of the system because some implementations may not necessarily require each step to be rigorously applied. However, if it is not, the subsequent step cannot begin.
The inability to speed up the SSADM methodology means it can be a drag on resources and produce analysis of system requirements that quickly become outdated. New bespoke software is more likely to be required by new business that lack established working procedures and existing applications. Such nascent enterprises tend to evolve quickly and so the requirements definitions produced by SSADM sometimes need to be revised before the whole methodology life cycle has completed. This situation is dubbed “analysis paralysis.” The development project gets bogged down in revisions and adjustments in the design phase, which postpones the development phase of software production and leaves the client operating on stop-gap software.