CMMI - Software 'Capability Maturity Model Integration' and Overlapping Waterfall

Status
Not open for further replies.
Elsmar Forum Sponsor

Marc

Hunkered Down for the Duration
Staff member
Admin
#2
Overlapping Waterfall Method

See Capability Maturity Model and this brief thread Overlapping Waterfall

This is a graphic of the Overlapping Waterfall method.
The waterfall model is a popular version of the systems development life cycle model for software engineering. Often considered the classic approach to the systems development life cycle, the waterfall model describes a development method that is linear and sequential. Waterfall development has distinct goals for each phase of development. Imagine a waterfall on the cliff of a steep mountain. Once the water has flowed over the edge of the cliff and has begun its journey down the side of the mountain, it cannot turn back. It is the same with waterfall development. Once a phase of development is completed, the development proceeds to the next phase and there is no turning back.

The advantage of waterfall development is that it allows for departmentalization and managerial control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process like a car in a carwash, and theoretically, be delivered on time. Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order, without any overlapping or iterative steps.

The disadvantage of waterfall development is that it does not allow for much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage. Alternatives to the waterfall model include joint application development (JAD), rapid application development (RAD), synch and stabilize, build and fix, and the spiral model.
From NASA
The Standard Waterfall Model for Systems Development

The standard waterfall model for systems development is an approach that goes through the following steps:

1. Document System Concept
2. Identify System Requirements and Analyze Them
3. Break the System into Pieces (Architectural Design)
4. Design Each Piece (Detailed Design)
5. Code the System Components and Test Them Individually (Coding, Debugging, and Unit Testing)
6. Integrate the Pieces and Test the System (System Testing)
7. Deploy the System and Operate It

This model is widely used on large government systems, particularly by the Department of Defense (DOD).

As part of this standard approach, the party responsible for contracting out the system development (ESDIS for the ECS Contract) can call on a number of tools to help plan and document the system. ECS followed this planning approach, which means that early in the system development, ESDIS set up a standard set of documents for the contractor to supply, as well as a contractual schedule for the major pieces. The development process provided a number of design reviews, notably

* Conceptual Design Review
* Requirements Review
* Preliminary Design Review (PDR)
* Critical Design Review (CDR)

Until these reviews were completed, there would be little code developed. After the CDR, the contractor would code to the design.

The standard reference for estimating the cost of the system is the COnstructive COst MOdel (COCOMO) developed by Dr. Barry Boehm while he was at TRW [Boehm, B., 1981: Software Engineering Economics, Prentice-Hall]. This model relates the development time and workforce [man-months] to the "Source Lines of Code" (SLOC). Roughly, for an ECS type of system ECS, the workforce (and therefore cost) scales as the cube of the development time. There are simple versions of the model and much more complex ones. Generally, all of the relationships used to predict these relationships are statistical in nature: Dr. Boehm and other workers in software project cost estimation build a database of project schedules and costs and then regress those against SLOC estimates. The most recent version of Dr. Boehm's work is provided in [Boehm, B., et al., 2000: Software Cost Estimation with COCOMO II, Prentice-Hall.].

There have been a number of criticisms of the standard waterfall model, including

* Problems are not discovered until system testing.
* Requirements must be fixed before the system is designed - requirements evolution makes the development method unstable.
* Design and code work often turn up requirements inconsistencies, missing system components, and unexpected development needs.
* System performance cannot be tested until the system is almost coded; undercapacity may be difficult to correct.

The standard waterfall model is associated with the failure or cancellation of a number of large systems. It can also be very expensive. As a result, the software development community has experimented with a number of alternative approaches, including

* Spiral Design (Go through waterfalls, starting with a very rough notion of the system and becoming more detailed over time)
* Modified Waterfalls (Waterfalls with Overlapping Phases; Waterfall with Subprojects)
* Evolutionary Prototyping (Start with initial concept, design and implement an initial prototype, iterate as needed through prototype refinement until acceptable, complete and release the acceptable prototype)
* Staged Delivery (Go through Concept, Requirements Analysis, and Architectural Design - then implement the pieces, showing them to the customer as the components are completed - and go back to the previous steps if needed)
* Evolutionary Delivery (a cross between Evolutionary Prototyping and Staged Delivery)

These are discussed in considerable detail in [McConnell, S., 1996: Rapid Development, Taming Wild Software Schedules, Microsoft Press]. Commercial software projects often reduce the formality of the full waterfall model. In the last few years, a paradigm known as eXtreme Programming has emerged that emphasizes reducing the cost of software changes, developing test cases before coding, developing code using pairs of programmers, and putting most of the documentation into the code [Beck, K., 2000: Extreme Programming Explained, Embrace Change, Addison-Wesley].
 
Status
Not open for further replies.
Thread starter Similar threads Forum Replies Date
M CMMI (capability maturity model) vs. SQA (software quality assurance) vs. ISO 9001 Software Quality Assurance 2
A Detail info on CMMI - Capability Maturity Model Integration for Software Software Quality Assurance 15
Marc CMMI in Software - Capability Maturity Model Integration Software Quality Assurance 20
A Software FMEA with CMMI FMEA and Control Plans 6
S Software Company wants CMMI Software Quality Assurance 4
P Only Software companies eligible to take CMMI? Misc. Quality Assurance and Business Systems Related Topics 11
A CMMI 3 - Software - Where we have to save all these documents Software Quality Assurance 4
H ISO 9001 / CMMI (SEI's Capablity Maturity Model) mapping - Software development Software Quality Assurance 2
D IATF 16949 Requirement for CMMI in a Global Company Elsmar Cove Forum Suggestions, Complaints, Problems and Bug Reports 0
P How to Scientifically Prove the Importance of a Process - CMMI Process Areas Software Quality Assurance 7
E CMMI (Capability Maturity Model Integration) - questions Software Quality Assurance 5
A Where to define Process Tailoring Form used in CMMI in the ISO 9001 Quality Manual? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5
K CMMI Roadmap - The process of implementing CMMI Level 3 Software Quality Assurance 5
B Basics of the CMMI Standard Software Quality Assurance 3
2 Expectations of CMMI High Maturity seem to have become less Ambiguous Software Quality Assurance 1
P What Documentation is required for CMMI? Examples wanted Software Quality Assurance 3
P Can anyone give samples of goals set of an organization for CMMI 5 Level Quality Tools, Improvement and Analysis 1
P An IMS organization can integrate CMMI with IMS ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
G SEI CMMI Dev v1.3 - Defined (ML2) and Managed (ML3) Process Areas Software Quality Assurance 1
R CMMI (Capability Maturity Model Integration) - Ever heard CMMI? Software Quality Assurance 5
S Mapping CMMI to FDA Requirements IEC 62304 - Medical Device Software Life Cycle Processes 5
Qwatcher2 CMMI Level 2 Procedure for Design & Development Program Software Quality Assurance 1
V CMMI - When you release audit and configuration audit, who will do audit? Software Quality Assurance 4
V CMMI - When do you do the Configuration Audit and Who will do that audit? Software Quality Assurance 5
2 ISO 9001 should be implemented before CMMI for maximum effectiveness? Quality Manager and Management Related Issues 2
C Which PA's in the CMMi model are required? Software Quality Assurance 6
D Tools for CMMI Rating the SCAMPI approach Software Quality Assurance 1
I CMMI Overview please Quality Manager and Management Related Issues 2
L ISO 9001:2000 and CMMI v1.2 Integration and Org Deployment ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 8
A Alternative Selection Excel .xls Template - ISO 9001 and CMMI (DAR Process Area) Excel .xls Spreadsheet Templates and Tools 1
S Is there any sample/Draft procedures, manuals checklist for CMMI Software Quality Assurance 2
F How to conduct CMMI appraisal Class C Software Quality Assurance 4
S How do I learn CMMI (Capability Maturity Model Integration)? Software Quality Assurance 4
V Getting CMMI level 4 & 5 is not a cake walk now! Software Quality Assurance 2
V CMMI V1.2 -Dev + IPPD appraisals Software Quality Assurance 1
L Document Hierarchy Structure for Documents Compliant in ISO 9001 and CMMI Document Control Systems, Procedures, Forms and Templates 23
R How does DRBFM fit into CMMI framework? Software Quality Assurance 8
A CMMI Mapping - The abbrivations under the CMM PA Software Quality Assurance 4
R CMMI Details - Seeking Details or Conversation Software Quality Assurance 2
K Software Updates in the Field and ISO scope ISO 13485:2016 - Medical Device Quality Management Systems 0
M Recurrent event analysis software (python) General Auditing Discussions 2
Y UL 1998 Standard: software classes Software Quality Assurance 0
P Need a programmer for QVI's VMS software for optical inspection machine Inspection, Prints (Drawings), Testing, Sampling and Related Topics 0
S IEC 62304 software costs and time Medical Device and FDA Regulations and Standards News 2
S IEC 62304 - Software verification cost IEC 62304 - Medical Device Software Life Cycle Processes 3
Sravan Manchikanti Software Risk Management & probability of occurrence as per IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 8
I Form templates for software (iso9001) Document Control Systems, Procedures, Forms and Templates 0
H Software Interface Translation IVD Regulation EU Medical Device Regulations 0
C 8.5.1.1 Control of Equipment, Tools, and Software Programs - Questions about the extent of control of NC programs AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 5
M IEC 62304 Software changes - Minor labeling changes on the GUI IEC 62304 - Medical Device Software Life Cycle Processes 3

Similar threads

Top Bottom