priority based software development and testing technique

PRIORITY-BASED SOFTWARE DEVELOPMENT AND TESTING TECHNIQUE

(PBSDT)

By

Boniface C. Nwugwo http://www.btctechnologies.com

2

OBJECTIVES

• Show how to implement PBSDT Who, Where and When to do PBSDT

• Discuss some of the benefits of PBSDT

http://www.btctechnologies.com BTC Technologies

3

THE BAD NEWS

PROBLEMS WITH SOFTWARE DEVELOPMENT:

Software Development Projects are frequently undertaken with only a vague indication of Customer requirements

Communication between Customer and Software Developer is often poor

Customer dissatisfaction with the “COMPLETED” system is encountered too frequently

BTC Technologieshttp://www.btctechnologies.com

4

THE GOOD NEWS

Each of the problems described before can be corrected

The key is an engineering approach to the development of software, coupled with continuing improvement of techniques and tools

Role Playing (this involves actual role plays)


Software Engineering Commentary , by Technology Reporter B.C. Nwugwo Roger Pressman and S.R. Herron, in their book, “Software Shock”, Dorset House, 1991 (pp. 159 - 161) once wrote: [Before a manufacturing engineer can worry about the design and creation of a single machine, he or she must understand the overall function and flow of the entire factory. The engineer should learn how each of the machines interacts with the others and define the modes of coordination that will allow raw materials to become an end product. Then, after the big picture is understood, the engineer can begin to focus on the discrete parts (the machines). You don’t need an engineering degree to recognize that this approach has merit - it’s simply common sense. The construction of any complex system (the factory is a system) begins with the big-picture view and proceeds through a series of iterations toward the nuts and bolts. Some software builders, deeply entrenched in the hacker’s culture, begin by focusing all of their attention and energies on a single “machine.” That is, rather than expending the effort to understand the specific requirements of a problem and laying out a complete design for the entire system, these programmers feel more comfortable writing the programming language source code that will enable them to create a program component. Often, they do a reasonably good job of building the program components, but problems surface when components must be combined to form a system, when the system is tested, and when changes to the system are required. No one spent any time considering the big picture. Software engineering suggests that a computer-based system should be built from the top down. That is, before worrying about all the components, a software engineer should understand overall requirements and establish an architecture for the system. The role of each individual component is then defined in terms of both the requirements and the architecture. Once this is done, design for each of the components can be accomplished with some certainty that each will integrate properly with others. This approach represents good software engineering practice (supported by centuries of practical application in other disciplines) and, more importantly, good common sense.] Myth: A general statement of objectives is sufficient to begin writing programs. We can fill in the details later. Reality: Poor up-front definition is the major cause of failed software efforts. A formal and detailed description of information domain, function, performance, interfaces, design constraints, and validation criteria is essential. These characteristics can be determined only after thorough communication between customer and developer.

5

PBSDT PROCESS: Who, When and How (1 of 5)

• PBSDT process is a very simple concept

• Consists of 5 principal activit ies During Customer Needs gathering

During SW Requirement Specifications

During SW Development

During SW Test Plan Development

During SW Integration & System Testing

• Each feature of the product is priorit ized based on its relative importance


PBSDT process is a very simple concept Each feature of the product is prioritized based on its relative importance Relative importance of the product features is defined based on degree of necessity Degree of necessity is the level of importance of a requirement from the customer's viewpoint

6

PBSDT PROCESS: Who, When and How (2 of 5)

• Relative importance of the product feature is defined based on degree of necessity

• Degree of necessity is the level of importance of a requirement from the customer’s viewpoint


7

PBSDT PROCESS: Definition of Degree of Necessity (3 of 5)

DEGREE OFNECESSI TY MEANI NG

Mandatory Implies that the software will not be acceptable unless theserequirements are provided in an agreed manner

Desirable Implies that these are requirements that would enhance thesoftware product, but would not make it unacceptable if theywere absent.

Optional Implies a set of requirements that may or may not beworthwhile, which gives the designers the opportunity topropose something, which exceeds the SRS.


8

PBSDT PROCESS: Definition of Priorities (4 of 5)

PRI ORI TY MEANI NG

High Implies that the software will not be acceptable unless theserequirements are provided

Medium Implies that these are requirements that would enhance thesoftware product, but would not make it unacceptable if theyare absent in alpha and beta releases, but must be in the finalrelease to the customer

Low Implies a set of requirements that may or may not beworthwhile, which gives the designers the opportunity topropose something which exceeds the SRS


9

PBSDT PROCESS DIAGRAM (5 of 5)

.

Figure 1. The PBSDT Process

Concept Implementation Team often times has little or no controlPhase over this

Voice of the Customer

RequirementsDefinition Phase

- Implementation Team has control over this.- We clarify our requirements and interpretation of Customer

perceived need for each program feature

Implementation ParallelPhase Development

Of Code andTest Cases

Test Phase

Customer Needs Requirements

Each customer requirement isClassified as either:

• Mandatory• Desirable or• Optional

Software Development

• Code• Inspect code and re-work• Unit Test

Note: High features are developed first,followed by Medium, then Low ones

Test Plan Development

• Test Case Design• Test Procedures

Note: Test Cases and Test Procedures aredeveloped for all program features withoutregard to priority

Integration and System Testing

• Priority-based testing beginning withHigh, then Medium and Lowrequirements are tested in that order

Software Requirements Specification

Each customer need is mapped into a softwarerequirement specification. Mandatory "High" Desirable "Medium"

Optional "Low"


10

BENEFITS (1 of 10)

• By setting priorit ies with respect to a deadline, the client understands which features are most likely to be implemented in time for the deadline. I f the client disagrees with the priority, he/she has plenty of t ime to change it. Since the developers have not coded much yet at that point, the impact of a change in priority is minimal.


11

BENEFITS (2 of 10)

• Priorit ies act as a focus, helping the developers decide which functions to implement first. I f the software developers think there isn't enough time to implement all the requirements, they now have the option of using the priorit ies as a guide to what to implement first.


12

BENEFITS (3 of 10)

• Maximize your "bang for the buck". As it happens so often, coding and integration take longer than expected. By the time System/Acceptance Testing starts, there isn't enough time left to thoroughly test the software. This is when priority-based testing makes the most of the time left. ”HIGH" tests are performed first, followed by ”MEDIUM", and “LOW” test cases. This approach means you'll lose some efficiency in setting up individual tests, but you gain the most value from the time you do spend in testing.


13

BENEFITS (4 of 10)

• The Pareto Principle applies to testing, as well as other software areas. An often quoted example is that "20% of the code is executed 80% of the time," and vice-versa. In testing, it 's not uncommon to find that 20% of the tests are ”High". Another 20% have ”Medium" priority. That means that 60% of the tests don't really have to be tested until the next release. That is handy to know when you don't have enough time to do thorough testing. Just concentrate on the 40% of the tests that really matter.


14

BENEFITS (5 of 10)

• Since SQA tests by priority, when a test fails, the software developers have the longest possible time to investigate and correct errors with the greatest impact.


15

BENEFITS (6 of 10)

• Testing by priority automatically does partial regression testing.

Trunk

Main Branches

Secondary Branches

Leaves LOW

HI GH


16

BENEFITS (7 of 10)

• At the end of each testing cycle, SQA produces a one-page test summary for the project manager as shown in Figure 2. Based on the results and the pre-agreed criteria for shipment, SQA can easily make shipment recommendations based on quantitative data. As the example shows, the tests that are yet to be tested are the functions for which the client is already willing to wait t ill the next release. Therefore, the project manager could ship the software with a fairly high confidence that the customer would readily accept the software.


17

BENEFITS (8 of 10)

PRI ORI TY PASSED FAI LED UNTESTED TOTAL

1 - High 31 0 0 31

2 - Medium 46 3 13 62

3 - Low 58 12 29 99

TOTALS: 135 15 42 192

Figure 2. Sample summary of test results


18

BENEFITS (9 of 10)

Test Summary Chart

0

10

20

30

40

50

60

PA

SS

ED

FAIL

ED

UN

TE

ST

ED

HighMediumLow


19

BENEFITS (10 of 10)

• The project manager gets a clear, quantitative one-page summary of test results. With the criteria for shipment already pre-agreed to, there is no need for last-minute uncertainties about whether the software is "good enough" to ship.

BTC Technollogieshttp://www.btctechnologies.com

20

CONCLUSION

• Priority-based software development & testing technique delivers more reliable systems on time compared to development and testing by poking around.

• I t is a rational alternative to managing software development and testing by “seat of the pants”.

• Perhaps most important, it is driven by real-world user perspective.


21

REFERENCES

Robert Binder, "Scenario-Based Testing for Client/Server Systems", Software Development, August 1995.

Vicki Tom, "Testing by Priority", The Tool-Box: Kodak's Software Tools Newsletter, Volume IV, No.4, Nov. 1989


priority based software development and testing technique

Documents

development of software

software developer

software builders

software shock

entire system

software development

completed system

complex system