Structured Systems Analysis and Design Method (SSADM)

The SSADM is a formal open methodology used by the government, private sector, and educational institutions, primarily for IT development projects. This methodology does not address areas beyond analysis and design; therefore, no deployment or implementation is catered for. Launched in 1981, SSADM has been updated and is still in use today. It is an excellent way for developing projects and is not considered a de facto standard.

SSADM is used highly in the IT community and takes a top-down approach to systems development. In this way, a high-level system design is achieved by simply refining the initial system requirements. The aim is to ensure that the design is as accurate as possible and that all requirements have been addressed. SSADM has only a limited take-up by large projects for major IT initiatives. This process is rigorous at times and is bound and controlled by the SSADM structural framework. Figure 4.14 shows how a project proceeds using this methodology. SSADM forces formulation and documentation of the necessary strategy for the project. Additionally, it covers substantial areas such as feasibility study and finalization of the design.

Strain* plowing

hrifjltdnitjl iLdCivl

Мап1 гдлсп

Figure 4.14: SSASDM methodology.

This structured methodology can bring cost savings to a project over its complete life cycle, because so much time is spent on performing a thorough design and analyses. The emphasis is providing the best upstream analysis and feasibility to reduce problems downstream.

The SSADM approach gradually transforms the clients requirements into a well-specified requirements document. The requirements are less ambiguous and are relevant to the business needs because the SSADM approach uses a set of tried and tested techniques, whereas many developments are launched without proper thought.

SSADM Viewpoints and Techniques

The SSADM approach requires three interdependent views of a system being developed:

Functionality/processing. This assesses the way information and data flows around the system and the processes that will be transformed by it, thereby laying out the functions for the users of the system. The technique used here to depict the processing is data flow modeling (a technique for analysis processing).

Data. The information systems of any organization act as a data store and then act on the data. The data view forms the backbone to SSADM. The technique used here to depict the processing is logical data modeling (provides the foundation of the new system).

Effects of time and events on the data held in the system. The function and data views are simply snapshots ; the event view is truly dynamic, as it is specifically designed to model the system behavior over time. The technique used here to depict the processing is entity behavior modeling.

The SSADM approach starts with a drawing of a top-level or top-down breakdown of the system into its lower level. It takes three interdependent views of a system that is going to be developed. SSADM is a product-driven methodology because it is largely concerned with completion of the product, along with the quality, rather than the application techniques.

An SSADM project goes from investigation to construction under the influence of the client organizational structure along with their internal policy and procedures. During this development cycle, decisions are made through the decision structure layer. Figure 4.14 illustrates this point.

The Pramis Methodology

The aim of this methodology is to reduce rework and promote earlier problem detection. At the same time, an improvement in the quality of the products produces important savings in the maintenance phase of a project, which means important savings for clients and an improved commercial image of the developer. Customer satisfaction should lead to increased sales. This methodology should be oriented toward the planning and control processes of systems and software development projects. Results would be the enhancement of the quality of the development processes of a particular company and, consequently, enhancement of its guarantee of conformance with the customers requirements. This methodology also takes into account the ISO 9001 standard.

Over the years, this methodology has been used to deliver projects on time, on budget, and in a way that keeps clients satisfied. This methodology is very flexible, and although not all components of the methodology apply to all clients, as a framework for success, it is unrivaled. A typical process applied to a typical development project follows:

Phase 1: The discovery phase. Initial assessment of projects should be given as much consideration as any other stage of the project. While the client usually has a good idea of what he or she wants, it can take the consulting team a great deal of work to understand the internal project language and all the unsaid design goals. Corporate culture can be the enemy of a successful project because all those things you take for granted as the way things are may be unknown to your consultants, or subtly different from your end users beliefs and experience. This model requests that the client agree to a small, fixed cost for discovery tasks. This phase culminates in a detailed requirements specification and more complete cost estimate. There are two distinct deliverables; first is the requirements and implementation plan. This makes no mention of cost and has value as a road map to the completed project. The second deliverable is a quote for the implementation of that plan; it includes the information the client needs to understand the cost and time involved in implementing the project. This is usually done on a short duration, fixed-cost basis, allowing the client and consultant to build a mutual understanding of the tasks and the capabilities of both teams.

Phase 2: The development phase. The development phase is typically where the bulk of the project time is spent. This phase implements the project plan developed in the discovery phase, up to the point that the application is feature-complete according to the initial specification, plus any mutually agreed-on changes that have been accepted by both the client and the consultant. This phase can be billed on a fixed-price or time-and-materials (T&M) basis. Billing method depends largely on how well-scoped and definitive the development effort can be.

Phase 3: Beta test and functional acceptance. This is the clients first real exposure to the application and will very likely produce change orders. Any misconceptions or omissions from the discovery phase will be most apparent here. Bugs will be found and must be handled. In this phase, projects that get into trouble really begin to show the signs of stress. To reduce the risk associated with this phase, you should agree that work done in this phase be handled on a T&M basis, but at a greatly reduced rate. The low rate produces a general feeling of goodwill, because the customer still recognizes a cost associated with the work, and the consulting organization is disincented from pushing work from Phase 2 to Phase 3.