Software Quality Assurance By Methodologies Information Technology Essay

Quality according to ISO 9000 is defined as “the totality of characteristics of an entity that bear on its ability to satisfy stated or implied needs”. NASA Software Quality Assurance Center describes SQA as “Software Quality Assurance is defined as a planned and systematic approach to the evaluation of the quality of and adherence to software product standards, processes and procedures” [1]. As agile approaches help us to handle unstable requirements throughout the development lifecycle and also deliver products in shorter timeframes and under budget constraint, therefore it is also necessary to ensure that the delivered software is of good quality. Software quality assurance (SQA) consists of a means of monitoring the agile processes and methods used to ensure quality.

This research is divided into three sections. In the first section we would describe the agile software development methodology and compare agile methods with the traditional development approaches. In the second section, we would describe the Software Quality Assurance and how agile methodologies help in improving the quality of the software. The last section will cover the problems identified in agile methods and accordingly a model has been proposed to overcome the identified problems.

Section I

Software development is the development of a software product in a planned and structured process. “A discipline whose aim is the production of quality software, software that is delivered on time, within budget, that satisfies its requirements and is maintainable is called software engineering” [2]. This software could be produced for a variety of purposes. The most common purposes are to meet specific needs of a specific client/business, to meet a perceived need of some set of potential users, or for personal use. In the IEEE standard glossary of software engineering terminology, the software life cycle is the period of time that starts when a software product is conceived and ends when the product is no longer available for use [3]. A variety of software development models have been proposed. The most familiar model is the Waterfall model [4].

Figure 1.A. Waterfall Model [4]

Various phases of the model are as follows:

Requirements definition: The goal of this phase is to understand the exact requirements of the customer and to document them properly. The resultant document is SRS.

Design phase: The goal of this phase is to transform the requirements specification into a structure that is suitable for implementation in some programming language.

Implementation and Unit Testing: On receiving system design documents, the work is divided in modules/units and actual coding is started. The system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality; this is referred to as Unit Testing. Unit testing mainly verifies if the modules/units meet their specifications.

Integration & System Testing: As specified above, the system is first divided in units which are developed and tested for their functionalities. These units are integrated into a complete system during Integration phase and tested to check if all modules/units coordinate between each other and the system as a whole behaves as per the specifications. After successfully testing the software, it is delivered to the customer.

Operations & Maintenance: This phase of “The Waterfall Model” is virtually never ending phase. Generally, problems with the system developed (which are not found during the development life cycle) come up after its practical use starts, so the issues related to the system are solved after deployment of the system. Not all the problems come in picture directly but they arise time to time and needs to be solved; hence this process is referred as Maintenance.

A. Overview of Agile Methodologies

The term Agile can be defined as “characterized by quickness, lightness and ease of movement: nimble” [5]. The agile software development methodologies group was given the name “Agile” when a group of software development practitioners met and formed the Agile Alliance in February 2001. The agile methodologies have shifted the values of the software development process from the mechanistic (i.e. driven by process and rules of science) to the organic (i.e. driven by softer issues of people and their interactions.). A group of 17 methodologists formed the Agile Alliance to address the challenges inherent to traditional development methods. The agile alliance developed an agile manifesto.

The manifesto reads as follows [6]:

“We are uncovering better ways of developing software by doing it and helping others does it. Through this work we have come to value

Individuals and interactions over Processes and tool

Working software over Comprehensive documentation

Customer collaboration over Contract negotiation

Responding to change over Following a plan

That is, while there is value in the items on the right, we value the items on the left more”.

Lindvall et al. (2002) summarized the working definition of agile methodologies as a group of software development processes that are iterative, incremental, self-organizing and emergent. Figure 1.B shows the nature of agile methodologies [8]:

Figure 1.B Nature of Agile Methodologies [8]

Meaning of each term [9]:

1. Iterative: An attempt to solve a software problem by finding successive approximations to the solution starting from an initial minimal set of requirements. This means that the architect or analyst designs a full system at the very beginning and then changes the functionality of each subsystem with each new release as the requirements are updated for each attempt.

2. Incremental: The approach is to partition the specified system into small subsystems by functionality and add a new functionality with each new release. Each release is a fully tested usable subsystem with limited functionality based on the implemented specifications. As the development progresses, the usable functionalities increase until a full system is realized.

3. Self- organizing: In the agile development setup, the “self-organizing” concept gives the team autonomy to organize itself to best complete the work items. This means that the implementation of issues such as interactions within the team, team dynamics, working hours, progress meetings, progress reports etc. are left to the team to decide how best they can be done.

4. Emergent: The emergent nature of agile methodologies means that agile software development is in fact a learning experience for each project and will remain a learning experience because each project is treated differently by applying the iterative, incremental, self-organizing, and emergent techniques.

The following diagram compares the different development phases of the traditional software development method and agile software development method:

Figure 1.C Waterfall Model vs. Agile methods Life cycle [10]

SECTION II

A. Software Quality

Quality is defined as Measure of excellence or state of being free from defects, deficiencies, and significant variations. ISO 8402-1986 standard defines quality as “the totality of features and characteristics of a product or service that bears its ability to satisfy stated or implied needs.”The IEEE Glossary (IEEE 1990) defines software quality as [11]:

1) The degree of which a system, component, or process meets specified requirements

2) The degree to which a system, component or process meets customer or user needs or expectations.

The International Standards Organization ISO 9000 defines quality as the totality of characteristics of an entity that bear on its ability to satisfy stated or implied needs. Where ‘stated needs’ means those needs that are specified as requirements by the customer in a contract, and ‘implied needs’ are those needs that are identified and defined by the company providing the product.

The Cambridge Advanced learner’s Dictionary (Quality 2009) defines quality as

1) How good or bad something is

2) A high standard

Some software engineers have defined quality in the following ways:

Meyer [12] defines software quality according to an adapted number of quality factors as defined by McCall, which are; correctness, robustness, extendibility, reusability, compatibility, efficiency, portability, integrity, verifiability, and ease of use etc.

Pressman agrees with Crosby and defines quality as “conformance to explicitly stated functional requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software” [13].

Sommerville [14] defines software quality as a management process concerned with ensuring that software has a low number of defects and that it reaches the required standards of maintainability, reliability, portability and so on.

B. SOFTWARE QUALITY ASSURANCE

Software quality assurance (SQA) consists of a means of monitoring the software engineering processes and methods used to ensure quality. The methods by which this is accomplished are many and varied, and may include ensuring conformance to one or more standards, such as ISO 9000 or a model such as CMMI.

The IEEE Glossary (IEEE 1990) definition of SQA is [10]:

1. A planned systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established functional technical requirements

2. A set of activities designed to evaluate the process by which products are developed or manufactured.

Software Quality assurance activities focus on the quality of the product and process as well. The quality models such as McCall’s Quality model presented in 1977 and Boehm’s Quality Model presented in 1978 described various quality attributes and factors which are supposed to be targeted during software development. Some quality attributes are as follows:

Software Quality Factor

Description

Correctness

The extent to which a program fulfils its specifications

Reliability

The extent to which a system perform its intended function without failure

Efficiency

The computing resources required by a system to perform a function

Integrity

The extend to which data and software are consistent and accurate across systems

Usability

The ease of use of the software

Maintainability

The effort required to locate and fix a fault in the program within its operation environment

Flexibility

The effort required to modify a system

Testability

The ease of testing the program, to ensure that it is error-free and meets its specification

Portability

The effort required to transfer a program from one hardware configuration and/or software environment to another or to extend the user base

Reusability

The ease of reusing software in different context

Interoperability

The effort required to couple the system to another system

Table 2.A McCall’s criteria of quality [15]

C. SOFTWARE QUALITY ASSURANCE BY AGILE METHODOLOGIES

From an agile perspective quality has been defined by some practitioners as follows:

McBreen [16] defines agile quality assurance as the development of software that can respond to change as the customer requires it to change. This implies that the frequent delivery of tested, working, and customer-approved software at the end of each iteration is an important aspect of agile quality assurance.

Ambler [17] considers agile quality to be a result of practices such as effective collaborative work, incremental development, and iterative development as implemented through techniques such as refactoring, test-driven development, modeling, and effective communication techniques.

Various techniques that agile development methodologies incorporate for software quality assurance are as follows:

1. Refactoring [18]: It is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. It is an integral practice of agile methodologies. It retains the behavioral semantics of the code- developers neither add nor remove anything when they refactor, they merely improve its quality.

2.Test-Driven Development: It focuses on writing tests before coding and frequently integrating the new code. Test-driven development requires developers to create automated unit tests that define code requirements (immediately) before writing the code itself. The tests contain assertions that are either true or false. Passing the tests confirms correct behavior as developers evolve and refactor the code. There are several advantages of TDD for agile software development. TDD forces developers to think about what new functional code should do before they write it. It also ensures that agile developers have testing code available to validate their work, ensuring that they test as often and early as possible.

3. Pair programming: Pair Programming (PP) means, “All production code is written by two people” [10]. PP is one of the core activities of agile. Purpose of adopting PP is to monitor and learn from each other continuously, while writing the code. Monitoring of software development and process is the responsibility of QA staff but PP imposes this responsibility on developers by sticking them to work together.. Laurie Williams of the University of Utah in Salt Lake City has shown that paired programmers are only 15% slower than two independent individual programmers, but produce 15% fewer bugs. Since testing and debugging are often many times more costly than initial programming, this is an impressive result.” [20].

4. On-site Customer: On-site customer is a general practice in most agile methods [22]. Customers help developers refine and correct requirements. The customer should support the development team throughout the whole development process. In the waterfall model, customers are typically involved in requirements definition and possibly system and software design but are not involved as much and do not contribute as much as they are expected to in an agile development. Consequently customer involvement in agile methods is much heavier than in waterfall development. 

5. Acceptance Testing: Acceptance testing is carried out after all unit test cases have passed. This activity is a dynamic QA technique [10]. Traditional approach also includes acceptance testing but the difference between agile acceptance testing and traditional acceptance testing is that acceptance testing occurs much earlier and more frequently in an agile development; it is not only done once. Early Customer feedback is one of the most valuable characteristics of agile methods. The short release and moving quickly to a development phase enables a team to get customer feedback as early as possible, which provides very valuable information for the development team.

6. Continuous Integration [10]: Traditionally, different modules are developed by different teams/developers and these are integrated at late state of project. Programmers can work separately for hours, days, or even weeks on the same source without realizing how many conflicts and bugs they are generating. Continuous Integration takes a different approach. Continuous integration describes the software engineering practice of immediately committing every change, no matter how small, to a revision control system. Continuous Integration is basically a software development practice where members of a team integrate their work frequently; usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. .

7. Frequent Customer Feedback: Unlike traditional system development methods, contact with the customer occurs more frequently in iterations. The customer has clear insight into the system that is being developed. He or she can give feedback and steer the development as needed. Each time there is a release the customer gives feedback on the system and the result is to improve the system and to be more relevant to the needs of the customer.

8. Type Of Communication: There can be various ways of communication but the most preferred way of exchanging information is face to face communication. This can be implemented in the form of daily meetings of small durations. It will bring accountability to the work in progress which is vital for quality assurance.

So far we have analyzed the various software quality assurance activities in agile methodologies. Now we would show with the help of the diagram that in which phase these techniques are used:

Requirement

Definition- System

Design

Integration and

System testing

Refactoring

Acceptance testing

Customer feedback

TDD

Pair programming

Customer feedback

Continuous integration

On-site customer

Face-to-face communication

System in use

Implementation and

unit testing

Figure 3.B Agile Development Cycle with Quality Assurance Activities

SECTION III

A. Problems Identified In Agile Software Quality Assurance

Agile methods produces product with better quality. Agile development method integrates QA practices in development activities, rather than practicing them independently and separately. Merging QA activities in software development, agile methodologies cut short the organizational role of QA. After the complete analysis some problems have been identified in the agile methods. The identified problems are as follows:

As per the agile manifesto the main focus is to develop working software with only comprehensive documentation. But sometimes due to managerial or organizational issues, customer or project requires some standards to be followed. And for standard conformance generation of documentation is essential. As proper documentation is not there, hence at times proper quality is not ensured.

In agile methods, the customer is involved in all the phases. The continuous interaction with the customer is a positive value to product quality. The developer is the one who continuously interacts with the customer. As the developer got the technical background, hence at times the customer may not able to understand the developer’s point of view which can further lead to misunderstandings and wastage of time.

If the responsibility of requirement analysis and testing is shifted on developer, it may overload the work of the developer causing lack of quality in process and product. Testing is the soul of the quality. If the developer is testing his own code then at times he may not be able to identify the errors. Developers may be aware of designing but might be less aware of quality standards.

Agile methods are based on the concept of incremental, adaptive to change and self- organization i.e. the development team can organize themselves and can take decisions independently. But in some situation, leadership is required because self organization can lead to conflicts when the requirements get complex or the system gets complex.

Hence the proposed solution is to redefine developers’ role and activities in the agile development process to ensure the overall good quality of the product.

B. Proposed Solution for Identified Problems

Various techniques like refactoring, on-site customer etc helps in improving the quality of the product. But there is still a need for Quality Analyst in the agile methodologies. The proposed solution is to introduce the role of Quality Analyst in agile methods and to redefine the roles and activities of the developer.

We propose that the development team should be divided into groups and then there should be one quality analyst for each group. For example, we have six development teams. We would then divide them into three groups and each team must be allotted one quality analyst expert to work as the member of each development team.

This quality analyst will not play the role of developer but as the monitoring authority of teams over all the work. It should be the responsibility of the Quality analyst to interact with the customer and during this continuous interaction he should gather all the requirement information and then must explain these requirements to the developer. Instead of educating the customer it is better to utilize expertise of those people who have abilities to interpret customer need to be implemented technically. In situation where the customer does not possess technical knowledge, the presence of quality analyst can be of great help.

Documentation has been the critical issue among the conventional and agile methodologies. Agile development is not against documentation but it encourages comprehensive documentation in order to save time and resources. But in some situations when customers demand or software is complex, documentation needs to be extensive. Hence in our proposed approach the quality analyst is supposed to perform this task only within their development teams. This may avoid the extra work load on developer.

Interaction between the quality analysts of different development teams is also an important factor. Development teams must interact with each other through the quality analyst via daily meetings of short durations. These quality analysts must maintain their mutual interaction in order to measure the progress, discuss critical issues, and share knowledge and their resources within the project. The conflicts arising in the development team can be solved by the management. The development teams are allowed to make their own decisions but major decisions relating to the project will be taken by the management.

C. The Proposed Model

The proposed model for strengthening the software quality assurance in agile developments:

Top Management

-Hierarchy

-Unity of command

-Span of control

-Delegation of Authority

Coordination

Effective

Communication

Customer Quality Analyst Developers

D. Explanation Of The Proposed Model

The proposed model consists of the customer, quality analyst, developers and the top management. There should be an effective communication between the customer and the quality analyst. The quality analyst should transform the requirement information into technical details and then he should send them to the developers. Main characteristics of effective communication are as follows:

1. Clarity: communication should be clearly and precisely stated.

2. Consistency: communication should be consistent.

3. Adequacy: information in the communication should be sufficient, neither over-burdening nor too little.

4. Acceptability: communication should stimulate acceptance and positive response between the customer and the quality analyst.

5. Free from semantic barriers: these barriers are concerned with the language difficulties. These occur due to the differences in the individual interpretations of the words.

There should be good coordination between the quality analyst and the developing team. Coordination is basically synchronization of the efforts. It is the orderly arrangement of group effort to provide unity of action in the pursuit of a common purpose. The quality analyst will help in the documentation, testing and maintaining other quality standards.

The proposed model also suggests a hierarchical system i.e. management at the top and developers and the quality analyst at the bottom. Basically the management will take major decisions about the project. Management is also responsible for removing the conflicts arising in the development team. Another important advantage of hierarchy is that it acts as an instrument of integration and coherence in the organization. Unity of command means that an employee should receive orders from one superior only. It means that the management team, as a whole would come to one single decision and then that decision is passed to the developers. Depending on the type of project, span of control is decided. Span of control means the number of sub-ordinates or the units of work that a manager can personally direct, control and supervise. If the project is routine types then the span of control is large else small.

In hierarchical systems, delegation of power also takes place. Delegation means conferring of specified authority by a higher to a lower authority. Here the developing teams have delegated power of taking their own decisions within their teams. Delegation can be permanent or temporary. The main advantage of using this is to increase the sense of responsibility and interests in the developers.

CONCLUSION

Through this research work we conclude that there are number of factors that directly or indirectly influence the quality assurance in agile development methodologies. Refactoring, pair programming, on-site customer, frequent feedback are some of the key techniques that helps in achieving good quality product. By redefining the role and the activities of the developer in the proposed model, has helped in assigning the responsibilities of the quality analyst. The proposed model suggests that there should be effective communication between the customer and the quality analyst. It also suggests that the documentation work is performed by the quality analyst. Techniques like coordination, delegation of power, unity of command and span of control further strengthens the software quality assurance activities in the agile development methodologies.

FUTURE SCOPE OF WORK

Agile methodologies are certainly moving towards higher levels of maturity. Generally Quality is an inherent aspect of agile software development methodologies. We would cover more quality factors in our future research which would help in the overall improvement of the software by agile development methodologies. The quality factors would include both process and product improvement factors.