:: QC Boss :: Testing, Independent Software Testing, Manual Testing, Website Testing, Functionality Testing, Usability Testing, QC, QA, UAT

Life Cycle Models

A variety of life cycle models have been proposed, most of which focus exclusively on the development processes.

Code and Fix

A simple and widely used software life cycle model: Repeat the following steps until the solution is good enough.

1. Code
2. Compile and execute
3. Detect errors
4. Fix

Waterfall Model

The waterfall model prescribes a sequential execution of a set of development and management processes, with no return to an earlier activity once it is completed. Some variants of the waterfall model allow revisiting the immediately preceding activity (”feedback loops”) if inconsistencies or new problems are encountered during the current activity.

V-Model

Another variant of the waterfall model — the V-model — associates each development activity with a test or validation at the same level of abstraction. Each development activity builds a more detailed model of the system than the one before it, and each validation tests a higher abstraction than its predecessor.

Spiral Model

Barry Boehm devised the spiral model to address the weaknesses of the waterfall model, especially its lack of resilience in the face of change. The spiral model focuses on addressing risks incrementally by repeating the waterfall model in a series of cycles or rounds:

• Concept of Operation
• Software Requirements
• Software Product Design
• Detailed Design
• Code
• Unit Test
• Integration and Test
• Acceptance Test
• Implementation

Each round consists of four phases (as illustrated in this figure):

1. Determine objectives: product definition, determination of business objects, specification of constraints, generation of alternatives
2. Evaluate alternatives: risk analysis, prototyping
3. Develop product: detailed design, code, unit test, integration
4. Plan next cycle: customer evaluation, design planning, implementation, customer delivery

The spiral model is an improvement on the waterfall model, as it provides for multiple builds and provides several opportunities for customer involvement. However, it is elaborate, difficult to manage, and does not keep all workers occupied during all phases.

Boehm subsequently proposed a modified version of the spiral model — the WinWin spiral model — which adds activities to the start of each cycle to identify the key stakeholders and their “win” conditions.

Prototyping — the Sawtooth and Shark Tooth Models

As a software product is being developed, the developers’ view of the system diverges from the client’s view, since the developer’s focus on design and implementation while the client remains focused on requirements.

The sawtooth model provides checkpoints during the development process in order to check that development is proceeding in a direction that will eventually meet the client’s requirements. Typically, the checkpoints involve demonstrating a prototype to the client. For example, two prototypes may be developed:

1. a revolutionary prototype is an illustrative model of the system, representing only a small fraction of the required functionality
2. an evolutionary prototype, shown late in the development process, is based on a completed design and implements some of the required functionality

The shark tooth model adds management reviews and demonstrations to the sawtooth model. Since these may be seen to be at an intermediate level of abstraction, a diagram of the model includes large “teeth” and small “teeth”.

Rapid Application Development and the Time Box Model

Rapid application development (RAD) is an approach rather than a model. Its proponents view formal life cycle models as inherently inefficient, due to the large amount of documentation and the number of reviews required. The formality of such models is seen as interfering with customer communication.

Instead, RAD focuses on developing a sequence of evolutionary prototypes which are reviewed with the customer, both to ensure that the system is developing toward the user’s requirements and to discover further requirements.

The process is controlled by restricting the development of each integration to a well-defined period of time, called a time box. Each time box includes analysis, design, and implementation of a prototype.

One problem with RAD is reaching closure — the customer always has feedback, and the developers and the customer may never agree that the project is done.

Synch-and-Stabilize

Synch-and-stabilize is Microsoft’s attempt to scale-up a loosely structured small-team (”hacker”) style of product development.

• many small teams (3 – 8 developers per team) work in parallel
• changes are synchronize frequently so components will work together
  • developers check-in their code by a particular time so a new build (complete recompile) is done by the end of the day or the next morning
  • a defect that “breaks” the build must be fixed immediately
• features are evolved incrementally, with occasional innovations
  • start with a “vision statement”
  • select features and establish priority of features with user input
  • developers are free to innovate or adapt to unforseen competitive opportunities or threats
  • continual testing during development
• the product is stabilized at 3 or 4 milestone junctures in the project lifetime
  • thorough internal and external testing (beta sites)
  • fix almost all errors detected
  • “zero-bug” release at the last milestone

The process is also called a “milestone”, “daily build”, “nightly build”, and “zero-defect” process.

The overall strategy is to quickly introduce products that are “good enough” to capture a mass market, then improve the product, selling multiple product versions and upgrades.

Iterative and Incremental Development

The Unified Process is an example of an iterative software development process. Its designers — Ivar Jacobson, Grady Booch, and James Rumbaugh — characterize the process [1] as:

• use-case driven — The use case model describes the complete functionality of the system. It replaces the traditional functional specification of the system, extending the question “What is the system supposed to do?” with the words “for each user?”

The use cases drive the development process: developers create design and implementation models to realize the use cases, and testers test the implementation to ensure that the use cases are correctly implemented.

• architecture-centric — The software architecture represents the most significant static and dynamic aspects of the system — the platform on which the software is to run, reusable components and frameworks available, deployment considerations, legacy systems, and nonfunctional requirements.

The architect selects the use cases which represent the key functions of the system (5% to 10% of all the use cases), specifies them in detail, and realizes them in terms of subsystems, classes, and components.

• iterative and incremental — The software development project is divided into mini-projects, each of which is an iteration that results in an increment. Each iteration deals with the most important risks and realizes a group of use cases that together extend the usability of the product as developed so far. In the early phases, a superficial design might be replaced by a more detailed or sophisticated one; in later phases, increments are typically additive.
  

Entity-Based Models

Issue-Based Life Cycle Model

Bruegge and Dutoit present (textbook, pp. 483–485) an issue-based life cycle model, in which the project is driven by a set of issues such as “How do we set up the initial teams?” and “What software architecture shall we use?” Issues are classified as open or closed, but closed issues can be reopened as changes occur in the application or solution domain. Issues are maintained in an issue base accessible to all project participants.

Issues do not directly correspond to risks, as some issues are design problems, not risks.

The management problem in issue-based development is to keep the number of open issues small and manageable. By organizing the project around issues, all life cycle activities may proceed concurrently, using dependencies between issues to determine which activities can be performed concurrently and what the impact of reopening an issue will be.

Workbook-Centered Development

IBM’s Object-Oriented Technology Center uses an iterative and incremental process, but organizes it around work products — documents, models, and software — and uses a structured workbook to ensure that the work products are available and organized for access by the entire project. Work products are seen as the primary means of project communication.

Capability Maturity Model

The Software Engineering Institute (SEI) has defined five levels to characterize the maturity of a software development organization:

1. Initial — ad hoc activities; dependence on the heroic efforts and skills of key individuals.
2. Repeatable — each project has a well-defined software life cycle, but different models are used for different projects; success is predictable for similar projects.
3. Defined — uses a documented model for all activities; model is customized at the beginning of each project.
4. Managed — metrics are defined for activities and deliverables; data is collected during the project to quantify progress
5. Optimized — measurement data are used to improve the model.

System Development Life Cycle Model

This is also known as Classic Life Cycle Model (or) Linear Sequential Model (or) Waterfall Method. This has the following activities.

1. System/Information Engineering and Modeling

2. Software Requirements Analysis

3. Systems Analysis and Design

4. Code Generation

5. Testing

6. Maintenance

System/Information Engineering and Modeling

As software is always 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. This system view is essential when software must interface with other elements such as hardware, people and other resources. System is the basic and very critical requirement for the existence of software in any entity. So if the system is not in place, the system should be engineered and put in place. In some cases to extract the maximum output, system should be re-engineered and spiced up. Once the ideal system is engineered or tuned up, the development team studies the software requirement for the system.

Software Requirements Analysis

This is also known as feasibility study. In this phase, the development team visits the customer and studies their system. They investigate the need for possible software automation in the given system. By the end of the feasibility study, the team furnishes a document that holds the different specific recommendations for the candidate system. It also includes the personnel assignments, costs, project schedule, and target dates. The requirements gathering process is intensified and focussed specially on software. To understand the nature of the program(s) to be built, the system engineer (”analyst”) must understand the information domain for the software, as well as required function, behavior, performance and interfacing. The essential purpose of this phase is to find the need and to define the problem that needs to be solved .

System Analysis and Design

In this phase, the software’s overall structure and its nuances are defined. In terms of the client/server technology, the number of tiers needed for the package architecture, the database design, the data structure design etc are all defined in this phase. Analysis and Design are very crucial in the whole development cycle. Any glitch in the design phase could be very expensive to solve in the later stage of the software development. Much care is taken during this phase. The logical system of the product is developed in this phase.

Code Generation

The design must be translated into a machine-readable form. The code generation step performs this task. If design is performed in a detailed manner, code generation can be accomplished with out much complication. Programming tools like Compilers, Interpreters, Debuggers are used to generate the code. Different high level programming languages like C, C++, Pascal, Java are used for coding. With respect to the type of application, the right programming language is chosen.

Testing

Once the code is generated, the program testing begins. Different testing methodologies are available to unravel the bugs that were committed during the previous phases. Different testing tools and methodologies are already available. Some companies build there own testing tools that are tailor made for there own development operations.

Maintenance

Software will definitely undergo change once it is delivered to the customer. There are many reasons for the change. Change could happen because of some unexpected input values into the system. In addition, the changes in the system could directly affect the software operations. The software should be developed to accommodate changes that could happen during the post implementation period.

Prototyping Model

This is a cyclic version of the linear model. In this model, once the requirement analysis is done and the design for a prototype is made, the development process gets started. Once the prototype is created, it is given to the customer for evaluation. The customer tests the package and gives his/her feed back to the developer who refines the product according to the customer’s exact expectation. After a finite number of iterations, the final software package is given to the customer. In this methodology, the software is evolved as a result of periodic shuttling of information between the customer and developer. This is the most popular development model in the contemporary IT industry. Most of the successful software products have been developed using this model – as it is very difficult (even for a whiz kid!) to comprehend all the requirements of a customer in one shot. There are many variations of this model skewed with respect to the project management styles of the companies. New versions of software product evolve as a result of prototyping.

Rapid Application Development (RAD) Model

The RAD is a linear sequential software development process that 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 a component-based construction approach. Used primarily for information systems applications, the RAD approach encompasses the following phases:

Business modeling

The information flow among business functions is modeled in a way that answers the following questions:
What information drives the business process?
What information is generated?
Who generates it?
Where does the information go?
Who processes it?

Data modeling

The information flow defined as part of the business modeling phase is refined into a set of data objects that are needed to support the business. The characteristic (called attributes) of each object share identified and the relationships between these objects are 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. Processing the descriptions are created for adding, modifying, deleting, or retrieving a data object.

Application generation

RAD assumes the use of the RAD tools like VB, VC++, Delphi etc rather than creating software using conventional third generation programming languages. The RAD works to reuse existing program components (when possible) or create reusable components (when necessary). In all cases, automated tools are used to facilitate construction of the software.

Testing and turnover

Since the RAD process emphasizes reuse, many of the program components have already been tested. This minimizes the testing and development time.

Component Assembly Model

Object technologies provide the technical framework for a component-based process model for software engineering. The object oriented paradigm emphasizes the creation of classes that encapsulate both data and the algorithm that are used to manipulate the data. If properly designed and implemented, object oriented classes are reusable across different applications and computer based system architectures. Component Assembly Model leads to software reusability. The integration/assembly of the already existing software components accelerate the development process. Nowadays many component libraries are available on the Internet. If the right components are chosen, the integration aspect is made much simpler.