The premise behind the Reuse Model is that systems should be built using existing components, as opposed to custom-building new components. The Reuse Model is clearly suited to Object-Oriented computing environments, which have become one of the premiere technologies in today’s system development industry.
Within the Reuse Model, libraries of software modules are maintained that can be copied for use in any system. These components are of two types: procedural modules and database modules.
When building a new system, the developer will “borrow” a copy of a module from the system library and then plug it into a function or procedure. If the needed module is not available, the developer will build it, and store a copy in the system library for future usage. If the modules are well-engineered, the developer, with minimal changes, can implement them.
The Reuse Model steps
The Reuse Model consists of the following steps:
– Definition of Requirements Initial system requirements are collected. These requirements are usually a subset of the complete system requirements.
– Definition of Objects The objects, which can support the necessary system components, are identified.
– Collection of Objects The system libraries are scanned to determine whether or not the needed objects are available. Copies of the needed objects are downloaded from the system.
– Creation of Customized Objects Objects that have been identified as needed, but that are not available in the library are created.
– Prototype Assembly A prototype version of the system is created and/or modified using the necessary objects.
– Prototype Evaluation The prototype is evaluated to determine if it adequately addresses customer needs and requirements.
– Requirements Refinement Requirements are further refined as a more detailed version of the prototype is created.
– Objects Refinement Objects are refined to reflect the changes in the requirements.
Problems/Challenges Associated with the Reuse Model
A general criticism of the Reuse Model is that it is limited for use in object-oriented development environments. Although this environment is rapidly growing in popularity, it is currently used in only a minority of system development applications.
The incremental method is in many ways a superset of the Waterfall Model. Projects following the Incremental approach subdivide the requirements specifications into smaller buildable projects (or modules).
Within each of those smaller requirements subsets, a development life cycle exists which includes the phases described in the Waterfall approach. The goal is to produce a working portion of the application demonstrating real functionality early in the broader SDLC. Each subsequent “increment” adds additional functionality to the application. Successive rounds continue until the final product is produced. Several of the
development models are variants of the Incremental model including Spiral and RAD.
The V-Model is considered an extension of the Waterfall Model. The purpose of the “V” shape is to demonstrate the relationships between each phase of specification development and its associated dynamic testing phase. This model clearly shows the inverse relationship between how products move from high level concepts to detailed program code; then, dynamic testing begins at the detailed code phase and progresses to the high level user acceptance test phase.
On the left side of the “V,” often referred to as the specifications side, verification test techniques are employed (to be described later in this skill category). These verification tests test the interim deliverables and detect defects as close to point of origin as possible. On the right hand side of the “V,” often referred to as the testing side, validation test techniques are used (described later in this skill category). Each of the validation phases test the counter opposed specification phase to validate that the specification at that level has been rendered into quality executable code
The V-Model enables teams to significantly increase the number of defects identified and removed during the development life cycle by integrating verification tests into all stages of development. Test planning activities are started early in the project, and test plans are detailed in parallel with requirements. Various verification techniques are also utilized throughout the project to:
– Verify evolving work products
Software Testing Principles and Concepts
– Test evolving applications by walking through scenarios using early prototypes
– Removing defects in the stage of origin (phase containment) results in:
– Shorter time to market
– Lower error correction costs
– Fewer defects in the production system
– Early test planning yields better test plans that can be used to validate the application against requirements
– Regardless of the development methodology used, understanding the V-model helps the tester recognize the dependence of related phases within the life cycle.
The Waterfall Model is the earliest method of structured system development. Although it has come under attack in recent years for being too rigid and unrealistic when it comes to quickly meeting customer’s needs, the Waterfall Model is still widely used. It is attributed with providing the theoretical basis for other SDLC models because it most closely resembles a “generic” model for software development
The Waterfall Model consists of the following steps:
1) System Conceptualization – Refers to the consideration of all aspects of the targeted business function or process, with the goals of determining how each of those aspects relates with one another, and which aspects will be incorporated into the system.
2) Systems Analysis – Refers to the gathering of system requirements, with the goal of determining how these requirements will be accommodated in the system. Extensive communication between the customer and the developer is essential.
3) System Design – Once the requirements have been collected and analyzed, it is necessary to identify in detail how the system will be constructed to perform necessary tasks. More specifically, the System Design phase is focused on the data requirements (what information will be processed in the system?), the software construction (how will the application be constructed?), and the interface construction (what will the system look like? What standards will be followed?).
4) Coding – Also known as programming, this step involves the creation of the system software. Requirements and systems specifications from the System Design step are translated into machine readable computer code.
5) Testing – As the software is created and added to the developing system, testing is performed to ensure that it is working correctly and efficiently. Testing is generally focused on two areas: internal efficiency and external effectiveness. The goal of external effectiveness testing is to verify that the software is functioning according to system design, and that it is performing all necessary functions or sub-functions. The goal of internal testing is to make sure that the computer code is efficient, standardized, and well documented. Testing can be a labor-intensive process, due to its iterative nature.
There are a variety of potential deliverables from each life cycle phase. The primary deliverables for each Waterfall phase are shown in Table along with “What is tested” and “Who performs the testing.”
|Development Phase||Deliverable||What is Tested||Who Perform Testing|
|System Conceptualization||Statement of need||Feasibility of System||Business Analysts, Product Owner, Testers|
|Systems Analysis||Statement of user requirements||Completeness and accuracy of requirements in describing user need||Business Analysts, Product Owner, Testers|
|System Design||System design specification||Completeness and accuracy of translation of requirements into design||Design Analysts, DBA, Developers, Testers|
|Coding||Application software||Design specifications translated into code at module level||Developers|
|Dynamic Testing||Tested system, error reports, final test report||Requirements, design specifications, applications software||Developers, Testers, Users|
|Maintenance||System changes||Requirements, design specifications, application software||Developers, Testers, Users|
Problems/Challenges associated with the Waterfall Model
Although the Waterfall Model has been used extensively over the years in the production of many quality systems, it is not without its problems. Criticisms fall into the following categories:
– Real projects rarely follow the sequential flow that the model proposes.
– At the beginning of most projects there is often a great deal of uncertainty about requirements and goals, and it is therefore difficult for customers to identify these criteria on a detailed level. The model does not accommodate this natural uncertainty very well.
Developing a system using the Waterfall Model can be a long, painstaking process that does not yield a working version of the system until late in the process.
Early systems development often took place in a rather chaotic and haphazard manner, relying entirely on the skills and experience of the individual team members performing the work. Today, many organizations still practice Ad-hoc Development either entirely or for a certain subset of their development (e.g. small projects).
The Software Engineering Institute (SEI) at Carnegie Mellon University points out that with Ad-hoc Process Models, “process capability is unpredictable because the software process is constantly changed or modified as the work progresses. Schedules, budgets, functionality, and product quality are generally (inconsistent). Performance depends on the capabilities of individuals and varies with their innate skills, knowledge, and motivations. There are few stable software processes in evidence, and performance can be predicted only by individual rather than organizational capability.”
“Even in undisciplined organizations, however, some individual software projects produce excellent results. When such projects succeed, it is generally through the heroic efforts of a dedicated team, rather than through repeating the proven methods of an organization with a mature software process. In the absence of an organization-wide software process, repeating results depends entirely on having the same individuals available for the next project. Success that rests solely on the availability of specific individuals provides no basis for long-term productivity and quality improvement throughout an organization.”
Continue to Read about Waterfall Model
Software Development Life Cycle models describe how the software development phases combine together to form a complete project. The SDLC describes a process used to create a software product from its initial conception to its release.
Each model has its advantages and disadvantages, so certain models may be employed depending on the goal of the application project. Testers will work on many different projects using different development models. A common misconception is that projects must follow only one methodology; for instance, if a project uses a Waterfall approach, it is only Waterfall. This is wrong.
The complexities of projects and the variety of interconnected modules will often be developed using best practices found in a variety of models. The tester will need to tailor the best testing approach to fit the model or models being used for the current project. There are many software development models. These models are:
1) The Ad-Hoc Ad-Hoc
2) The Waterfall Model
3) The V-Model
4) The Incremental Model
5) The Iterative Development Model
6) Prototype/RAD Model
7) The Spiral Model
8) The Reuse Model
Continue to read about the Ad-Hoc Model