The Software Development Life Cycle

SOFTWARE TESTING LIFE CYCLE

No matter which software development methodology you use, Pay4Bugs can be an essential part of your testing processes. Once your product, website, or application is nearing the beta phase, and it’s time to get hands-on feedback from real users at a low price, Pay4Bugs is the way to go.

Software Development Life Cycle – CODE AND FIX

This methodology is probably used more often than any other. It is unique in that the application’s feature set is designed at the same time the application logic is written.

Development starts immediately, with little (or, often, no) planning involved. Problems are dealt with, and defects are fixed, as they occur.

Although this process allows development to proceed quickly, the project will encounter serious delays if major architectural problems are found. Major architectural problems, especially those discovered late in the process, will require a rewrite of much of your code.

The Code And Fix methodology is characerized by Wikipedia as “not so much a deliberate strategy as an artifact of naiveté and schedule pressure on software developers.”

Code and Fix is popular in small companies, but its use should be discouraged. Some things that can be done to discourage its use:

• Create teams with a mix of developers, marketing people and management, and empower them to make decisions about your application’s features.
• Include management in the software development process; many delays are created due to management not consulting with the product development team, and, therefore, setting launch dates that are not attainable.
• After the product launches, arrange a meeting of the product team to discuss what went right, and what went wrong.

Software Development Life Cycle – WATERFALL

The waterfall model is a sequential design process comprised of several steps, each of which must be completed before the next starts.

1. System/Information Engineering and Modeling
   Requirements are established for each component in the system, and the team decides which requirements will be fullfilled by the software. This is necessary when the application must interact with other resources. Once the ideal system is designed according to the requirements, work proceeds to the next step.
2. Software Requirement Analysis
   Software Requirement Analysis is also known as a feasibility study. The development team analyzes the customers’ requirements, looking at the need for possible software automation.Then, the development team creates a document that holds specific recommendations for the customer’s system. This document includes details like personnel assignments, costs of the system, project schedule and target dates.
3. System Analysis and Design
   Here, the process and the application’s structure are defined. If client/server technology is to be used, this step will specify elements like number of tiers required for the package architecture, and the database design. Then, the development team will create a software development model. This is a crucial step; any fault in the design phase could be very expensive to fix later.
4. Code Generation
   In this phase, the actual application code is created. using high level programming languages like C, C++, Pascal and Java. The programming language is chosen according to the type of application, as well as the application requirements.
5. Testing
   Several different testing methods are available to reveal errors and defects that were created during the previous phases.
6. Maintenance
   Maintenance is performed after the application is delivered to the customer. Changes can occur due to changing customer requirements or new, unexpected input into the system. The application should be designed to accommodate changes that could be happen after development is complete.

It is very important to gather all requirements during the first phase of the Waterfall Model, in order to ensure proper system design. If the customer adds requirements later, the development process will be impacted in a very negative way.

Software Development Life Cycle – MODIFIED WATERFALL

Many engineers recommend modified versions of the waterfall model. In the traditional waterfall model, the different stages of development are not allowed to overlap. One common type of modification allows some of the stages to overlap, which results in reduced documentation requirements and a reduced cost of returning to earlier stages to make changes. Another common modification is to incorporate prototyping into the requirements phases.

Overlapping stages, such as the requirements stage and the design stage, allow the development team to integrate feedback from the design phase into the requirements; but overlapping stages can make it difficult to know when you are finished with a given stage, as the line between stages becomes blurred. This makes progress harder track. Without distinct stages, problems can cause you to defer important decisions until later in the process when they are more expensive to correct.

Software Development Life Cycle – PROTOTYPING

One of the main problems with the waterfall model is that the requirements often are not completely understood in the early development stages. When you reach the future stages, you may discover that you need to adjust the requirements.

Prototyping can be useful in determining how a design meets a set of requirements. You can build a prototype, adjust the requirements, and revise the prototype several times, gaining an understanding of the project’s overall goals. In addition to clarifying the requirements, a prototype also defines many areas of the design at the same time.

The pure waterfall model allows for prototyping in later stages, but not in the early requirements stages.

Some drawbacks of prototyping:

• Because it appears that you have a working system, customers might expect a complete system sooner than is possible. In most cases, a prototype is built on compromises that allow it to come together quickly; those compromises may prevent prototypes from becoming effective building blocks for future development. You need to decide early if you want to use the prototype as a basis for future development, and everyone needs to agree with this decision before development begins.
• Prototyping can easily turn into a Code and Fix development cycle. Before you begin prototyping, gather clear requirements and create a design plan. Limit the amount of time you spend prototyping before you begin. Time limits help to avoid overdoing the prototyping phase. As you incorporate changes, update the requirements and the current design. After you finish prototyping, consider returning to one of the other development models. For example, consider prototyping as part of the requirements or design phases of the waterfall model.

Types of prototyping include:

Patch Up Prototype: This type of Prototype Model has each developer working on a specific part of the program.. After everyone has done their part, the pieces program will be integrated with each other. This type of prototype encourages cooperation between members of the development team.

Non-Operational Prototype: Used when only a certain part of the program should be updated. The main application is not affected, because the code being tested is tested as part of dummy program is applied with the application. This prototype is usually used to solve problems in a specific part of the program.

First of a Series Prototype: This type of prototype is also known as a beta version. The software is fully functional; the goal of a beta is to elicit feedback and suggestions; to determine usability; and to resolve defects that may pop up as a result of real-world usage.

Selected Features Prototype: This is another form beta, but the beta testers have access only to selected features and tools. This type of prototype is used with applications that are part of a larger suite of programs. This is usually done to test the independent features of the application in question.

Software Development Life Cycle – SPIRAL

The spiral model is an iterative model that attempts to combine advantages of the top-down and bottom-up models of software design. The goal is to reduce, as much as possible, an application’s time-to-market; in the traditional waterfall model, since each step must be completed before the next one starts, the time-to-market can be much longer.

The system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.

• A preliminary design is created for the new system. This phase is the most important part of the Spiral Model.

• A first prototype of the new system is constructed from the preliminary design.

• A second prototype is evolved by a fourfold procedure:

1. evaluating the first prototype in terms of its strengths, weaknesses, and risks;
2. defining the requirements of the second prototype;
3. planning and designing the second prototype;
4. constructing and testing the second prototype.

The spiral model is designed to minimize risks and allow you to find major problems earlier in the development cycle. A project is broen up the into a set of risks that you need to deal with. You then begin a series of iterations in which you analyze the most important risk, evaluate options for resolving the risk, deal with the risk, assess the results, and plan for the next iteration.

For each risk, you must consider

• Probability: how likely it is that the risk will occur
• Loss: the severity of the effect of the risk on the project

You can use a scale of 1 to 10 for each of these items, where 1 represents the lowest probability or loss and 10 represents the highest. Risk exposure is the product of these two rankings.

The risks that have the highest risk exposure should be resolved first.

PAY4BUGS

Pay4Bugs can be an essential part of your testing processes, no matter which methodology you use.