What is Analysis & Design?
A software company that is building information systems and providing software solutions for its clients usually needs a systems analyst for a medium-size to large-size information systems. Smaller software companies with smaller projects may skip the systems analysis part and jump directly to development. This method will not work when building larger systems.
In the past, systems analysts came from a strong software development background. They had to have strong programming skills and then they were promoted to systems analysts. This has been changing now, more and more is a business background becoming important for a systems analyst worldwide, but we're still catching up on this here in Egypt where most, if not all, of the systems analysts come from a software development (aka programming) background.
A systems analyst might have some of his duties programming and the rest analysis and design. A Programmer/Analyst position would have most of his work in programming with only some of it being analysis/design. An Analyst/Programmer would have less programming duties and more analysis work. An Systems Analyst would have most of his work (if not all) analysis and design while only minimal, if any, programming.
Structured systems analysis and design had been the norm for long. It is even what they still teach till now at most computer departments in Egyptian universities. Things such as DFDs (data flow diagrams) are part of the structured analysis and design. Many companies still use structured analysis and design.
The new direction, however, is Object Oriented Analysis & Design (which I had so much enjoyed teaching for fresh university grads at IBM Authorized Training Centers). UML is the diagramming language used for OO Analysis & Design.
The specific tasks a Systems Analyst will be doing will vary from one company to the other depending on the size of their projects, the type of their clients, the size of their development team and the system they use for work. A systems analyst may be responsible for gathering "requirements" from the clients. He may meet with clients and try to know exactly what their requirements are. Even in this early stage, UML can be used to gather those requirements using diagrams that are easy to sketch and understand (use cases). Those simple stick diagrams and use cases are so simple that they can be easily understood even by the clients themselves.
After that gathering the requirements, the systems analyst would go through an analysis phase, where he produces more diagrams for the analysis of the system. Then a phase of design follows, which has more UML diagrams and provides more details for the programmers/developers. The design diagrams are what is given to the programmers/developers in order to build the system. This is what they get to see. If the requirements, analysis and design phases have been carried out carefully and well, the developers will be able to start working from the design diagrams in a straightforward way. Everything will be so clear for developers, and development, which is called the implementation phase, will go on very smoothly with minimal headache.
Implementation is followed by the final stage which is testing. In medium size to large size projects, dedicated testers work as part of the team. They are sometimes referred to as QA (quality assurance). (They also have tasks, and a job description, but this can be the subject of another article if you would like to know.)
In the past, systems analysts used to draw their diagrams with pencil and paper. Now CASE (computer aided systems engineering) tools help analysts draw their diagrams. Rational Rose, a large company which IBM bought a couple of years ago, is one of the large companies that makes software for analysts (go to the IBM site and search for their products). Similarly, Together Soft, also bought by Borland, has excellent products for systems analysis & design. Borland has kind of integrated those products with its developer products now. They work together so nicely, in fact they dance!
You can draw a UML diagram for the design of a system and those tools by Borland can convert the diagrams automatically to code (Java or C++). This is just amazing. Not only that, if you modify the code, the UML diagrams will be automatically updated! I strongly suggest that you try their software or at least see the demo.
I have a lot more to say about this very interesting field. I remember over 9 years ago when I first bought a book about Systems Analysis & Design I knew nothing about it and thought it was nothing but flow charts, silly me. After reading like 600 pages in that yellow-bound book, I discovered it was something totally different and stopped wondering why the word IT is the popular word and why information technology was and still is the most important thing in the computer world. It was not until years later that that I discovered that book was only talking about structured analysis and design, and then I got to learn about UML and object oriented analysis and design which is way more fascinating. I'll be glad to answer any questions related to this topic.
Using Analysis & Design
Structured analysis & design suited the programming world at an early stage and was based on functional programming while object oriented programming was still novel and not in widespread use by companies doing real word projects.
but structured A&D was much more complicated than OO A&D, to use it today for building large scale systems will be a headache and it will also not interact smoothly if you're going to build your systems using object oriented programming languages (C++, Java).
OO A&D which uses UML is way more flexible and much simpler. it also has the added advantage that it can be easily translated into code in OO languages (Java, C++).
To create a system, you need two things:
- A method for notation.
- A methodology.
UML is the notation used for OO A&D. (UML has other uses not related to systems analysis and design as well. UML is composed of a set of diagrams, which can be used in anything, even in things completely unrelated to the field of software development).
The most well-known methodology for OO A&D used to be RUP (Rational unified process). A methodology tells you how to use the diagrams (the notational language, in our case UML) to create the system. it tells you in which steps to proceed, what to do first, what to do next, and how to use each of the UML diagrams to create the system.
Many other methodologies have evolved now. The RUP still exists, but is too complex for medium size projects. Other agile methodologies such as Extreme Programming (abbreviated XP) have become popular. They too tell you how to use UML diagrams to create the system, but they use much simpler approaches for creating the system.
I'd love to answer your questions about this topic if you only ask, as I'm full of info about it that I want to get out, but I will say more only if asked, for there is no reason for giving details about something, unless another person wants to know about it.
if you need details about any part of what was mentioned above, I'd be glad to answer. I love instructing, it's my profession and my love.