4. The Prototyping Model Listen to customer Build/revise mock-up Customer test-drives mock-up
5. The RAD Model Team #1 Team #2 Team #3 Business modeling Data modeling Process modeling Application modeling Test and turnover Business modeling Data modeling Process modeling Application modeling Test and turnover Business modeling Data modeling Process modeling Application modeling Test and turnover
7. V- Model SRS Unit test Tested modules Integration Test Integrated software System Integration Test Tested software System Test, AcceptanceTest Requirements Specification System Design Detailed Design Coding System Design SRS Module designs Code User Manual
Waterfall Model: Sometime called the linear sequential or classic life cycle model, the waterfall model suggest symmetric, sequential approach to software development the begins at the system level and progress through analysis, design, coding, testing, and support. Figure 1 illustrates the waterfall model for software engineering. The waterfall model encompasses the following activates: System/information engineering and modeling. Because software is always part of a large system (or business), work begins by establishing requirements for all system elements and then allocating some subset of these requirements to software. System engineering and analysis encompass requirements gathering at the system level with a small amount of top level design and analysis. Information engineering encompass requirements gathering at the strategic level and at the business area level. Software requirements analysis. The requirement gathering process is intensified and focused specifically on software. To understand the nature of the program(s) to be built, the software engineering (analyst) must understand the information domain for the software, as well as required function, behavior, performance and interface. Design. Software design is actually a multistep process that focuses on four distinct attributes of a program: data structure, software architecture, interface representation, and procedural (algorithmic) details. The design process translates requirements into a representation of the software the can be assessed for quality before coding begins. Code generation. The design must be translated in to a machine-readable form. The code generation step performs this task. If design is performed in a detailed manner, code generation can be accomplished mechanically. Testing. Once code has been generated, program testing begins. The testing process focuses on the logic internals of the software, ensuring that all statement have been tested, and on the functional externals; that is, conducting test to uncover errors and ensure that defined input will produced actual results that agree with required results. Support. Software will undoubtedly undergo change after it is delivered to the customer (a person exception is embedded software). Change will occur because errors have been encountered, because the software must be adapted to accommodate changes in external environment (changes in Operating system, peripheral devices etc), or because customer requirement, functional or performance enhancement.
The prototype paradigm begins with requirement gathering. Developing and customer meet and define the overall objective for the software, identify whatever requirement are known, and outline areas where further definition is mandatory. A “quick design” then occurs. The quick design focuses on a representation of those aspects of the software that will be visible to the customer/user (e.g. input approaches and output format). The quick design leads to the construction of a prototype. The prototype is evaluated by the customer/user and used to refine requirement for the software to be developed. Iteration occurs as the prototype is tuned to satisfy the needs of the customer, while at the same time enabling the development to better understand what needs to be done.
Rapid application development (RAD) is an incremental software development process model the emphasizes an extremely short development cycle. The RAD model is a “high-speed” adaptation of the linear sequential model in which rapid development is achieved by using component-based-construction. If requirement are well understood and project scope is constrained, the RAD process enables a development team to create a “fully functional system” within very short time periods. Used primarily for information system application, the RAD approach encompasses the following phases: Business Modeling. The information flow among business function is modeled in a way that following question. What information drives the business process? What information is generated? Who generated it? Where does the information go? Who process it? Data Modeling. The flow defined as a part of the business-modeling phase is refined into a set of data object that are need to support the business. The characteristics of each object are identified and the relationship between these objects defined. Process Modeling. The data objects defined in the data-modeling phase are transformed to achieve the information flow necessary to implement a business function. Process descriptions are created for adding modifying, deleting, or retrieving a data object. Application generation. RAD assumes the use of fourth generation techniques. Rather that creating software using conventional third generation programming languages the RAD process works to reuse existing program components or create reusable components. Testing and turnover. Since the RAD process emphasizes reuse, many of the program components have already been tested. This reduces overall testing time.
The analogy for this is inspecting a car without running it.
Boris Beizer gives the following explanation of the different objective that independent testing has over developer testing: "The purpose of independent testing is to provide a different perspective and, therefore, different tests; furthermore to conduct those tests in a richer [...] environment than is possible for the developer." [ BEI95 ]
The four areas the structural or white box testing encompasses are: Directly testing low-level functions, Procedure, Subroutines, or libraries. In MS Windows these are called APIs Testing the software at the top level, as a completed program, but adjusting your test cases based on what you know about the software’s operation. Gaining access to read variables and state information form the software to help you determine whether your tests are doing what you thought. And being able to force the software to do things that would be difficult if you tested it normally. Measuring how much of the code and specifically what code you hit when you run your tests and then adjusting your tests to remove the redundant test cases and add missing ones.
![Software Development Lifecycle ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)