Printer Friendly

Lifting the lid on system analysis: Part 1: IDMi's Deputy Editor John Baker, takes a somewhat sideways look at system analysis and design and lets you see that it is not as scary as you might think.

What's in an 'Acronymname'

Back in the day, when computing centres were run by bearded COBOL gurus sporting unkempt beards, (and possibly sandals and tee-shirts bearing obscure/obscene references to Star Trek/Stargate/Star Wars,) they would huddle, tank-top-and-flare-clad, around their desks and talk of UNIX, Fortran, Pascal, near pointers, far pointers, arrays, variables, and a host of other terms, mostly unintelligible to the rest of us.

These days the computing industry is (a little) more sophisticated and ordered, and (normally) a bit less 'ivory tower'. The beards are more likely to be trimmed and groomed in the manner of George II rather than Wild Man from Borneo, but the glazed look in a computer expert's eyes when you mention the term 'System Analysis & Design Methodology' (SAADM) is still there. It's the selfsame glazed look you get when you mention SSADM to members of the management team, or to end-user community. But why is this?

In this series of articles, I hope to unravel the mysteries of SSADM and other 'ologies'. I also hope to dispel the misconception that ANY form of SSADM leads to Paralysis by Analysis.

What is SSADM?

'Largely redundant' some would say. 'Replaced by other ADMs' others might say. But at the end of it all, it is just an acronym to describe one method of analysis which includes functional decomposition. No, don't switch off and flick the page, this is NOT a series of technical articles, and although I will introduce you to some technical terms, I will also provide either an explanation of the term, an analogous situation you can better relate to, or both. I want you to be entertained by the prospect of system analysis not mortified by it. In the case of functional decomposition, it does exactly as it suggests in the title--it is a process whereby you can break down the functions of a system, or process, into smaller manageable chunks. This allows better analysis, more in-depth assessment, and possibly/probably offers up the opportunity to better design the same thing.

Again, back in the day, because back in the day is when I cut my analysis teeth, the governments around the world were getting to grips with the 20th century. Waiting until the 1970's and 1980's was a little late in my view, but nonetheless, the powers that be were beginning to realise the advantages of computing, the benefits that really good systems could bring to the table, and all of the process improvements likely to be gained. SSADM just happens to be a British 'invention', (1980, for the Computer and Communications Agency,) and no doubt other countries had their own flavour of SSADM. begged, borrowed, [Or in some cases--stolen. Ed.] they all had the same aim--Controlling a beast. Today you will hear talk of Lean Six Sigma. Prince I and II, (no not the dead one,) and others. They are all of the same breed, some better suited for certain aspects of analysis of particular systems such as banking transactions, and others for good old process management.

A computer system, regardless of shape, size, brand, or cost--is a beast. Like an untrained dog, you will find an untrained computer leaves an awful mess behind, and it is costly, time consuming, and a terribly messy job to clean up. Much better to educate, corral, guide, cajole, mould, and otherwise beat the c**p out of the blighter from day one. (Not that I am suggesting for one minute that you hit your dog.)

To achieve order in the computing world, you need due process. The computer is useless without software, but the split-nanosecond you begin installing the first bit of non-OS, (Operating System--i.e. Windows,) software, you exponentially expose the beast [metaphorically] to a host of unknowns. The software can be as simple as a Random Insult Generator, (PayPal me a donation of 2.99 [pounds sterling] if you want one,) or it can be as complex as 'shared processor use working with NASA'. The middle-ground however, where any form of analysis comes into its own, (and there is a lot of middle ground,) is software and systems which work together to provide coherent, easy to use, expertly (?) analysed tools to do a specific job--and do it well. Throughout this series of articles. I will take a look specifically at Document Management systems as analysis examples, but the analysis side and other elements can equally be applied to almost any other kind of system.

John Baker has been involved in system analysis, design, build, and implementation, since the mid-eighties. He has experienced all sizes of systems, ranging from several users in one room, to thousands of users distributed around the world. He will field questions by email: johnbaker@intelligen.co.uk
COPYRIGHT 2017 IDMi
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2017 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Baker, John
Publication:IDMi (Information & Document Management International)
Date:Apr 1, 2017
Words:792
Previous Article:Save our sounds: 15 years to save the nation's sound collections.
Next Article:IDMi A4/A3 scanner guide.

Terms of use | Privacy policy | Copyright © 2021 Farlex, Inc. | Feedback | For webmasters |