page_title: Cap Gemini SDM
section_title: Main difference between SDM and SDM2
hierarchical_section_title: Cap Gemini SDM / History / Main difference between SDM and SDM2
caption_attribution_description: English: Plan-Do-Check-Act Deming circle, also known as the Shewart cycle, since Deming claimed he took the idea from him. Later Deming changed it to be Plan-Do-Study-Act, but the first version seems more popular and has become the defacto standard.
context_page_description: Cap Gemini SDM, or SDM2 is a software development method developed by the software company Pandata in the Netherlands in 1970. The method is a waterfall model divided in seven phases that have a clear start and end. Each phase delivers subproducts, called milestones. It was used extensively in the Netherlands for ICT projects in the 1980s and 1990s. Pandata was purchased by the Capgemini group in the 1980s, and the last version of SDM to be published in English was SDM2 in 1991 by Cap Gemini Publishing BV. The method was regularly taught and distributed among Capgemini consultants and customers, until the waterfall method slowly went out of fashion in the wake of more iterative extreme programming methods such as Rapid application development, Rational Unified Process and Agile software development.
context_section_description: SDM2 was a revised version of SDM that attempted to solve a basic problem that occurred often in SDM projects; the delivered system failed to meet the customer requirements. Though any number of specific reasons for this could arise, the basic waterfall method used in SDM was a recipe for this problem due to the relatively large amount of time spent by development teams between the Definition Study and the Implementation phases. It was during the design phases that the project often became out of sync with customer requirements.
  During the SDM functional design phase called BD (Basic Design), design aspects were documented (out of phase) in detail for the later technical design DD (Detailed Design). This caused a gray zone of responsibility to occur between the two phases; the functional crew responsible for the data flows and process flows in the BD were making decisions that the technical crew later needed to code, although their technical knowledge was not detailed enough to make those decisions. This obviously led to problems in collaboration between project teams during both the BD and DD phases. Because of the waterfall method of Go/No Go decisions at the end of each phase, the technical crew would have to make a formal Change request in order to make corrections in the detailed sections of the Basic Design. Such changes were often confusing for the customer, because these originated from the project team rather than directly from the customer requirements, even after a change freeze was put in place. Usually the customer was only allowed to produce requirements up to and including the functional design in the BD phase. After that, the customer had to wait patiently until acceptance testing in the Implementation phase.
  In SDM2, the term "Basic Design" was replaced by the term "Global Design" to indicate that this document was continuously updated and subject to change during both the BD and DD phases. Thus the "Basic design" is both global and detailed at the end of the project. In the global design, the principles of functionality and construction, as well as their relations, are documented. This is how the idea of iterative development got started; a functional design is by nature influenced by the technology platform chosen for implementation, and some basic design decisions will need to be revisited when early assumptions prove later to be wrong or costly to implement. This became the forerunner of the Rapid Application Development method, which caused these two phases to become cyclical and work in tandem.
  SDM2 only partially solved the problem of meeting customer requirements; modern software development methods go several steps further by insisting for example on incremental deliveries, or that the customer appoint key users of the delivered system to play a role in the project from start to finish.
caption: The Deming circle, which since the 1980s forms the basis of any software project management process.
exif: {}