Software Quality Construction: Empirical Study on the Role of Requirements,

Stakeholders and Resources

Seth, Frank P.

APSEC 2012 Conference, Hong Kong 4-7th December

2

OVERVIEW

1. Introduction

2. Research Process

3. Results

4. Discussion and conclusions

1. Objective of the Study

3

• The objective of this qualitative case study was to observe and describe how software quality is constructed in software development organizations

4

2. RESEARCH PROCESS

Method: Qualitative case study using Grounded Theory

•The grounded theory research method outlined by Glaser and Strauss and later extended by Strauss and Corbin was used. The questions of interview are available at http://www2.it.lut.fi/projects/STX/.

5

3. Results

Some of the quality characteristics of software products are not important to some types of software products. •Purpose of the software eg. Embedded software and web application•Users of software: Age, knowledge•In-house software vs public software•Standalone application vs network applications

6

Results

Business requirements dictate the type of user requirements to be prioritized in the software product.

7

Results

The quality construction of software products is constrained by budget and time (resources). •Fixed budget project is a problem - In quality-focused software development, software requirements tend to change along the process of development •Chasing deadlines jeopardies quality•Involving customers in the production process helps both to increase the quality and bargaining for emerging costs including change of product delivery schedule

8

4. DISCUSSION AND CONCLUSIONS

• The development of software products is non-linear in the sense that the process is iterative. To achieve intended software product quality there is a need for requirements discovery to be continuous throughout the development process.

• Interpreting identified software requirements into the software product is the challenge that companies need to overcome. Users will simply interpret unidentified or wrongly interpreted requirements as “poor quality”.

9

DISCUSSION AND CONCLUSIONS

• Prioritization of requirements

different organizations had different approaches to prioritizing identified requirements. For example, some organizations used a team of managers to prioritize the requirements while in others the work was left to designers and programmers.

• Use of International standards

Generally, we observed that a majority of the organizations did not fully adopt international standards (for example ISO, IEEE) throughout the software development process.

The developers or testers stated, however, that they use guidelines based on existing international standards

10

DISCUSSION AND CONCLUSIONS

• Quality framework or modelIn this study, we discovered that none of the studied software development organizations adopted any quality framework or model in the quality construction process.

11

DISCUSSION AND CONCLUSIONS

For successful quality construction it may be important to observe the following:•Customer involvement in all stages of product development from planning to delivery of a finished product•Flexibility of the budget (to cover for extra features or expertise)•Flexibility of project time•Requirements management (elicitation, interpretation, prioritization and tradeoffs)

Kiitos