Jump to content

System Development Methodology

Add links
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Afbcasejr (talk | contribs) at 20:47, 26 May 2007 (This original article hijacked the term "System Development Methodology" to create a virtual commercial for ONE single methodlogy. At least now, the intro discussed the history and evolution of SDMs.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

System Development Methodology is a general term applied to a variety of structured, organized processes for developing information technology and embedded software systems.

Over the years there have been many system development methodologies including SDM and SDM2, developed by PANDATA, now part of Cap Gemini, PRIDE: Profitable Informatoin by DEsign, the first commercially available SDM, SSADM Structured Analysis and Design Method, SDM70 by Atlantic Management Systems, Spectrum Structured by Spectrum Systems, and many more.

Early SDMs were focused on project management - and defining the phases, tasks and worksteps, or hierarchical work breakdown stucture or Waterfall Model of a typical information technology project, and were analysis and design technique agnostic. Many of these project management based methodologies were, in fact, based on either critical path method (CPM) or the Navy's Program Evaluation and Review Technique (PERT).


The Cap Gemini SDM Methodology

In the early- to mid-1970s, the various generic worksteps of system development methodologies were replaced with worksteps based on various structured analysis or structured design techniques. SDM, SDM2, SDM/70 and Spectrum, notably, evolved into system development methodologies that were based on the works of Steven Ward, Tom Demarco, Larry Constantine, Ken Orr, Ed Yourdon, Michael Jackson and others as well as data modeling techniques developed by Thomas Bachmann and Peter Chen SDM is a top-down model. Starting from the system as a whole, its description becomes more detailed as the design progresses.

History

SDM was developed in 1970 by a company known as PANDATA, now part of Cap Gemini, by order of three Dutch companies: AKZO, Nationale Nederlanden and PTT. It was revised in 1987. This version is commonly known as SDM2.

Differences between SDM and SDM2

During the SDM functional, design phase problems were documented. They were necessary for the making of the functional design. This documentation in front was replaced in the new phase design. This phase design is global and detailed design. In the global design the principles of functionality and construction as well as their relations are documented.

The method

As stated before, SDM is a method based on phases. Before every phase, an agreement needs to be reached detailing the activities for that phase. These documents are known as milestone documents. Several uses for these documents exist:

  • Traceability — Through applying deadlines to milestone documents, clients can keep track on whether a project is on schedule
  • Consolidation — By approving a milestone document, it gains a certain status. The client can not change any of the specifications later during development.
  • If necessary, the project can be aborted. This mostly happens during the start of development.

Phases

The method uses 7 phases which successively are being executed. The phases are:

  1. Problem definition
  2. Definition study
  3. Design
  4. Building system
  5. Testing
  6. Implementation
  7. Operation and Support

Upon completion of a phase, it is decided whether to go on to the next phase or not; the terms 'Go' and 'NO-GO' are used for this. The next phase will not start until a 'Go' is given, while if there is a 'NO-GO', the project either stays in the current phase to be improved or is cancelled completely.

Problem definition

In this phase, the problems that have to be solved by the project are defined. The current and desired situations are analysed, and goals for the project are decided upon. In this phase, it is important to consider the needs of all parties, such as future users and their management. Often, their expectations clash, causing problems later during development or during use of the system.

Definition study

In this phase, a more in-depth study of the project is made. The organization is analysed to determine their needs and determine the impact of the system on the organization. The requirements for the system are discussed and decided upon. The feasibility of the project is determined. Aspects that can be considered to determine feasibility are:

  • Advisable — Are the resources (both time and knowledge) available to complete the project.
  • Significance — Does the current system need to be replaced?
  • Technique — Can the available equipment handle the requirements the system places on it?
  • Economics — Are the costs of developing the system lower than the profit made from using it?
  • Organization — Will the organization be able to use the new system?
  • Legal — Does the new system conflict with existing laws?

Design

In this phase, the design for the product is made. After the definition study has determined what the system needs to do, the design determines how this will be done. This often results in two documents: The functional design, explaining what each part of the system does, and the technical design, explaining how each part of the system is going to work.

SDM2 split this step in two parts.

  • Global design — This phase combines a functional and technical design and only gives a broad design for the system. Often, the architecture of the system is described here.
  • Detailed design — This phase continues the global design by creating more detailed designs to the point where they can be used to build the system itself. This is split to create separate parts of the system to be created.

Building the system

In this phase, the design is converted to a working system. The actual way this is done will depend on the system used. Where in older systems programmers often had to write all of the code, newer systems allow the programmers to convert the design into code directly, leaving less work to be done and a smaller chance for errors. At the same type, the system becomes more reliant on the design—if the design has been properly tested, the proper code will be generated, but if the design is not fully correct, the code will be incorrect without a programmer to look for such problems.

Testing

The testing consists of two steps: A system test and an acceptance test.

During the system test the development team—or a separate testing team—tests the system. Most of this will be focused on the technical aspects: does the system work as it should, or are there bugs still present? Bugs that are found in this phase will be fixed. At the ending of this phase, the program should work properly.

During the acceptance test, the end-users will test the system. They will test to see if the program does what they want it to do. They will not test every possible scenario, but they will test to see if the program does what they want and expect it to do and that it works in an easy way. Bugs that are found in this phase will be reported to the development team so that they can fix these bugs.

Implementation

During this phase, the final version of the system is implemented by the organization: the hardware is set up, the software is installed, end user documentation is created and, end users trained to use the program, existing data is entered into the system.

Operation and Support

Once the system has been implemented, it is used within the organization. During its lifetime, it needs to be kept running and possibly enhanced.

Retrieved from "https://en.wikipedia.org/w/index.php?title=System_Development_Methodology&oldid=133711216"