You are on page 1of 18


function. algorithmic details. user documentation.Waterfall Model • Requirements – defines needed information. behavior. testing. software architecture. . • Design – data structures. interface representations. performance and interfaces. • Implementation – source code. database.

easy to use Provides structure to inexperienced staff Milestones are well understood Sets requirements stability Good for management control (plan. staff.Waterfall Strengths • • • • • • Easy to understand. track) Works well when quality is more important than cost or schedule .

Waterfall Deficiencies • All requirements must be known upfront • Deliverables created for each phase are considered frozen – inhibits flexibility • Can give a false impression of progress • Does not reflect problem-solving nature of software development – iterations of phases • Integration is one big bang at the end • Little opportunity for customer to preview the system (until it may be too late) .

• Testing of the product is planned in parallel with a corresponding phase of development .V-Shaped SDLC Model • A variant of the Waterfall that emphasizes the verification and validation of the product.

operation and maintenance – provide for enhancement and corrections System and acceptance testing – check the entire software system in its environment • • • • Integration and Testing – check that modules interconnect correctly Unit testing – check that each module acts as expected Coding – transform algorithms into software • .V-Shaped Steps • Project and Requirements Planning – allocate resources • • • Product Requirements and Specification Analysis – complete specification of the software system Architecture or High-Level Design – defines how software functions fulfill the design Detailed Design – develop algorithms for each architectural component Production.

PROTOTYPE • • • • • • • Building an experimental system Template to create a final system Working version of information system Iterative process is conducted Accurately reflecting user version Users give corrective feedback User is satisfied. the prototype is brought up to the standards needed for a final product. .

Steps • • • • Identify the user’s basic requirements Develop an initial prototype Use the prototype Revise and enhance the prototype .

until all designed functionality has been implemented. . • Each subsequent release of the system adds function to the previous release.Incremental SDLC Model • Construct a partial implementation of a total system • Then slowly add increased functionality • The incremental model prioritizes requirements of the system and then implements them in groups.

Spiral SDLC Model • Adds risk analysis. and 4gl RAD prototyping to the waterfall model • Each cycle involves the same sequence of steps as the waterfall process model .


hardware/software interface. etc. • Study alternatives relative to objectives and constraints • Identify risks (lack of experience. schedule. buy. reuse. alternatives and constraints • Objectives: functionality.Spiral Quadrant Determine objectives. • Resolve risks (evaluate if money could be lost by continuing system development . interface. new technology. etc. critical success factors. performance. poor process. etc. etc. • Alternatives: build. • Constraints: cost. sub-contract. tight schedules.

.DATA FLOW DIAGRAM • A data-flow diagram (DFD) is a graphical representation of the "flow" of data through an information system. • Data Flow Diagramming is a means of representing a system at any level of detail with a graphic network of symbols showing data flows. data processes. and data sources/destinations. data stores.

Symbols in DFD .

• Arrows representing the data flows.• Squares representing external entities. • Open-ended rectangles representing data stores. do something to it. which can either be electronic data or physical items. • Rounded rectangles representing processes. which are sources or destinations of data. and output it. including electronic stores such as databases or XML files and physical stores such as or filing cabinets or stacks of paper. . which take data as input.

• All processes should modify the incoming data.Rules • All processes must have at least one data flow in and one data flow out. • Each external entity must be involved with at least one data flow. producing new forms of outgoing data. • A data flow must be attached to at least one process. • Each data store must be involved with at least one data flow. .

showing systems at any level of detail. rather than physical models showing HOW it does it. • Hierarchical. • Logical representations. eliminating thousands of words. . modeling WHAT a system does. allowing user understanding and reviewing.Objective • Graphical. and • jargon(language) less.