Analysis and Design for Systems
To manage the development process, you must understand how the development phases relate to one another and to the overall process.
Understanding the relationship between the work products facilitates the enhancement and refinement of the models. Just as in analysis, the models must be reconciled to test completeness and correctness.
The testing aspect of the process will continue throughout design.
Understanding how these same work products evolve from one phase to the next facilitates the management of the overall process. Each phase brings the work products to a level that allows them to be the resources for the next phase.
This module explains how to use the resources obtained from the first two phases of the project to create the architecture and object level designs
for the software.
Module Learning Objectives
After completing this module, you will be able to:
- Describe how the two design phases fit into the project life cycle
- Transition from analysis to design
- Explain how the work products of analysis provide the basis for design
- Identify two steps of design: architectural analysis and object design
- Evaluate the impact of architectural analysis on object design and clarify how the two phases are related.
Systems Analysis and Design
Why is systems analysis and design important in the development of information systems? To answer that question, let us consider an analogous situation: the art and science of creating a beautiful building. In this scenario, there is the buyer who has the vision, the builder who will construct the building, and the architect who serves as the bridge between the buyer and the builder. The architect helps the buyer develop the vision but must also communicate the building’s specifications to the builder. In doing so, the architect uses various tools to first capture the vision from the buyer and then provide the
builder with instructions, including such tools as line drawings, blueprints, toscale models, detail specifications, and even on-site inspections.
Just as a builder does not start construction without plans, programmers don’t just sit down and start writing program code.
They need someone to function like an architect, planning, capturing the vision, understanding details, specifying needs,
before writing the code and verifying that it satisfies the vision.
The software architect has to be able to understand and capture the vision of the persons funding the project.
Usually, we call this person a systems analyst. In situations where you are the programmer as well as the analyst,
it might be easy to keep track of the details without writing them down.
However, in today’s world, with some system development teams distributed worldwide, you may only be responsible for part of the programming, with the
rest handled by team members around the world. In a distributed team situation, it is much more important to have written documents to assist in understanding, capturing, explaining, and specifying the software application.