SindhUniv. Res. Jour. (Sci. Ser.) Vol.

47(2):313-320 (2015)

SINDH UNIVERSITY RESEARCH JOURNAL (SCIENCE SERIES)

Factors Affecting Software Quality in Legacy Software Life Cycle Models for Emerging Professionals
N. MAHOTO++, A. SHAIKH, F. KHUHAWAR* A. AFTAB
Department of Software Engineering, Mehran UET Jamshoro, Sindh, Pakistan
Received 4thMarch 2015 and Revised 16thMay 2015

Abstract: The next generation computer technology facilitates humans to work efficiently through computer machines. These machines
need Quality software to perform required tasks appropriately. The Quality of software exhibits the characteristics of the software product,
which can be achieved through various processes performed during software development lifecycle. When software is designed and built
not following standard processes, eventually results in more chances of its failure. Sometimes, the chance of software failure increases
because of having not well enough testing. To avoid failure of software, it is very much necessary to design and build the software using
effective, standardized approaches and suitable software development models. This paper finds and identifies the key factors that may cause
degradation of software quality and make software quality a challenging issue during the legacy software development lifecycle. The work
is done with a survey conducted from development teams involved in the development of software in local cities of Pakistan. The survey
results reveal the key factors and areas that affect software Quality in development lifecycle for emerging professionals in Pakistan.

Keywords: Software Engineering, Software Quality Assurance, Software Development, and Software Design.

1. INTRODUCTION The Quality of software exhibits the characteristics

The next generation computer technology has of the software that can be achieved through various
changed life style; it has enhanced human efficiency processes performed in the development of software
exploiting computer machines, which require software application. Although improvements are made to scale
as key element to accomplish predefined tasks. The quality but when things go wrong, software fails to
computer machines make things better for humans if the satisfy the needs (Pressman, 2001). Software, designed
software running on the machine performs all tasks and built with non-standard processes, has more chances
smoothly. The success of software depends upon the of failure. Sometimes, improper testing increases its
requirements, which are supposed to be fulfilled. Thus failure chances. To avoid failures, designing and
the efficiency and success of the computer machine building of software using effective, standardized
relies on software, which in return complies with user approaches and suitable software development models
requirements or tasks. are needed.
Software Engineering discipline is concerned with In recent years much effort has been done to
designing, developing, testing and maintaining the produce Quality Software to achieve better results in
software, and aims to produce Quality Software terms of productivity and efficiency of the organizations
(Sommerville, 2000). The term Quality Software can be equipped with Information Technology (IT) solutions.
describe as software that is designed and built on time, Software, whilst works like backbone for such
within budget and satisfy the needs of its users. The organizations. These organizations enjoy better
development of Software involves many activities to productivity and scalable growth. In-fact Quality
produce Quality Software such as Analysis, Planning, Software enhances efficiency of functional operations
and Design etc. (Fig.1) represents Software within organization, reduces time and cost, and
Development Lifecycle amongst various software increases customer trust. If the quality of software is
process models. poor or does not fully meet the intended requirements
• Waterfall Model (Royce, 1987) causes failure of entire effort performed in the
• Boehm’s Spiral Model (Boehm, 1988) development. The processes and activities performed in
• Rational Unified Process (RUP) (Jacobson, Booch the development of software are interconnected to each
and Rumbaugh, 1998) other therefore defect of one activity may leave impact
• RAD (Rapid Application Development) Model on other activities. Hence software must possess quality
(Whitten, Bentley and Dittman, 2003) attributes such as: Reliability, Correctness, Integrity,
• Agile (Beck et al., 2001) Efficiency, and Maintainability. Moreover, many

++
Corresponding Author Email: naeemmahoto@gmail.com; Tel.: +92-333-7538991
* Institute of Advanced Research Studies in Chemical Sciences, University of Sindh, Jamshoro, Sindh, Pakistan
N. MAHOTO et al., 314

organizations rely on Quality Software to increase The survey conducted in Ciolkowski et al.
productivity and scalability (Pressman, 2001), (Ciolkowski, Laitenberger and Biffl, 2003) analyzed
(Sommerville, 2000). state of practice; the major focus remained on the
applications of walkthroughs, reviews and inspections.
Analysis The authors highlighted the concerns regarding time
consumptions and thus declared these techniques as
inapplicable in practical usage. Jedlitschka et al.
Requirement specification (Jedlitschka et al., 2007) analyzed practically adoption
of inspections in decision making for the German
software industries; their observation focused on
technological impact on software Quality, cost, and
Design
development time.
Hauge (Hauge, 2007) investigated Open Source
Implementation phenomenon and conducted a web-based survey, he
observed 50% companies adopted open source coding
in their software products. Torchiano et al. (Torchiano
Testing and Integration et al., 2008) reported 66% Italian companies experience
migration tasks in his survey about analyzing state of
practice of software migration. Scanniello et al.
(Scanniello et al., 2011) conducted survey in Italian
Maintenance
industries for the understanding the state of practice
software Quality assessment and software defect
Fig.1 : Software Development Lifecycle
identifications; they highlighted the software testing as
This paper addresses the factors that may degrade popular technique and growing interest aims towards
the software Quality during its development lifecycle. distributed inspection methods and deducted main
The research is carried out by conducting a survey from problem as the lack of proper skilled employees. The
development teams of major cities of Pakistan to aim of survey in Torchiano et al. (Torchiano et al.,
analyze the factors that impact software Quality. The 2008) was to identify the major problems encountered
survey results report the major areas and factors that for software Quality assessment and defect
cause the poor Quality of software while it is in identification. However, they didn’t highlight the factors
development phase. degrading the software Quality during development
lifecycle.
The rest of the paper is organized as Section 2
describes related work, Section 3 discusses proposed The intent of this paper is to identify the key
approach; the survey results and factors affecting factors and areas in the software development phases
software quality are reported in Section 4 and 5. Finally that affect software Quality. In particular, identification
conclusions are driven in Section 6. of the major factors causing degradation of software
quality and making software quality a challenging issue
2. RELATED WORK during the software development lifecycle. Our work is
Surveys are greatly taken attention in the field of carried out by conducting an online survey from
Software Engineering for the analysis of processes, development teams involved in the software
methods and maintenance of software products (Hauge, development lifecycle in order to get insight into
2007), (Li et al., 2008). The investigation of software processes that are performed in the development
products by means of surveys, comprising questionnaire lifecycle especially in local cities of Pakistan.
and its purpose, can be carried out by number of ways
such as online survey forms, face-to-face interviews,
3. METHODOLOGY
mails, emails and web blogs; the surveys are considered
The research mainly has been carried out
as very fast way to gather information. Research has
performing the following steps: Research assumptions,
been done for assessment of software Quality,
Designing Questionnaire, Conducting Survey and
identification of defects, reviews etc. in terms of state of
Identifying Factors
art (Chandola, Banerjee and Kumar, 2009), (Czaja and
Blair, 2005). The surveys, which focused practical The Research assumptions are made in the
consideration of the processes are conducted in beginning of the survey in accordance with expected
(Ciolkowski, Laitenberger and Biffl, 2003), (Jedlitschka and well-known factors in literature and are described as
et al., 2007), (Scanniello et al., 2011). follows:
Factors Affecting Software Quality in Legacy Software… 315

• R-1: Non-standard procedures often result poor rest 91% (43 respondents) were male. The respondent’s
Quality age ranged from 20-29 years accounted to about 85%
and the remaining 15% were in the age-group ranging in
• R-2: Poorly gathered requirements and poor design, between 30-40 years.
usually leads to compromise at Software Quality
Regarding work experience, 19% of respondents
• R-3: Unavailability of Quality Matrix agreements were having more than 6 years of work experience,
at the beginning of projects leads towards poor where as 9% of respondents had work experience
Quality ranging from 4-6 years. Rest 28% of respondents had 2-
• R-4: Satisfied employees produce High Quality 4 years of work experience and 45% had less than 2
Software Applications years of work experience.

• R-5: Higher than 50% of total development in

Knowledge
Testing phase yields Good Quality Software Hypothesis Standards
Domain
Products
The Questionnaire is carefully designed to satisfy
our purpose of research covering the entire phases of
Software Development and it also ensures the ethical
requirements. In particular, Questions are included to Questionnaire
figure out the major factors impacting Quality of Design
Software at industrial level in Pakistan. The
Questionnaire has been divided into sections as per
various phases of development lifecycle such
requirements, design, development and testing phases.
A survey has been conducted from Software Survey
Industries of big cities of Pakistan including Karachi
and Lahore, which often contribute large in Software
Market. In particular, Development teams (convenient
contacts with authors) involved in Software
Development are focused. We clarified the respondents
about the research purposes and ensured them the data Analysis
would be used solely for the research. A total of 47
responses (samples) were collected in a period of two
months.
The identification of factors has been analyzed in
the evaluation block in (Fig.2) based on domain
knowledge, standards, and survey results. The survey Evaluation
results are also statistically verified with Research
assumptions made earlier for finding factors. The Bird
view block diagram of the methodology is illustrated in
(Fig.2). The findings of the work and survey results are
described in the following sections in detail.
Factors
4. SURVEY RESULTS
Among the 47 respondents (samples), who
participated in the survey, the city-wise distribution
observed is as following: 38% respondents were from Fig.1 : Block diagram of Identification of Factors
Islamabad, 26% from Lahore, 21% from Karachi, 13%
from Hyderabad and rest 2% worked from home at The organizations having number of employees
various locations. below 20 are considered as small, number of employees
Regarding Qualification of respondents, only one in between 20 and 99 are considered medium and over
(2%) had Higher Secondary Schooling, while 57% were 100 are regarded as large organizations. We collected
with Bachelor’s Degree, 40% with Master’s Degree and samples from organizations categorized as small,
None (0%) was found having PhD degree. Furthermore, medium and large organizations by 21%, 40% and 38%
only 9% (only 4) were found with female gender, the respectively.
N. MAHOTO et al., 316

Regarding work environment and administrative describing the requirement phase being applied within
behavior towards its employees, only 2-4% of the organizations.
respondents reported poor environment and/or poor
The survey tells 38% of developers are provided
behavior, whereas rest of them answered as Fair, Good
requirements in written as well as diagrammatic format,
and Excellent. Since, environment and administrative
where as 43% with written but only narrative format
behavior maintain a key role in business domain, the
and 17% with verbal. These results explain the poor
survey results represent a higher number that is, 97% of
designing phase.
respondents were happy with their organizations
environment and administrative behavior. Moreover, Moreover, the results describe 19% of respondents
60% of the employees who took part in the survey, don’t follow requirement phase and 9% don’t know
reported their colleagues as very much co-operative and about it. Among these respondents who don’t gather
36% mentioned the conditional co-operation based on requirements properly, deliver 46% software products
availability of leisure time. with more than 40% bugs. Likewise, the results show
the poor design produces 50% of their software products
The already made Research assumptions are
having bugs more than 40%. Hence, the survey results
analyzed in the light of survey results.
are consistent with Research assumption R-2. The poor
• R-1: Non-standard procedures often result poor requirement gathering and poor design leads towards
Quality poor Software Quality.
To verify the Research assumption R-1, we asked
the respondents whether they follow organizational Re qui re m e nt G at he r i ng
policies, standards, and procedures for the requirement phas e
gathering and design phase. The (Table 1) reports the
survey responses for both Requirement and Design Organization Percentage (%)

72%
Phase.
Table 1 : Requirement, Design standards and procedures

Phase Name Yes No Don’t Know Total

Requirement 24 17 6 47
Design 22 18 7 47 19%
The Quality of Software deliverables is measured

9%
according to the number of bugs reported by clients,
once deliverables are handed over to the clients. Based
on this measure, we computed the percentile of Good
YES NO DON'T KNOW
Quality and Poor Quality for the data described in
(Table 1). To validate the statistical significance of the
Quality measure, we used t-test (Dietterich, 1998) at 5% Fig.2 : Requirement Gathering Phase
significance level. The t-test produced p value 0.0002
that validates the quality measure statistically • R-3: Unavailability of Quality Matrix agreements
significant. Therefore, Research assumption R-1 stands at the beginning of projects leads towards poor
true regarding Quality of Software. Quality

• R-2: Poorly gathered requirements and poor design, 47% of respondents reported their organizations make
usually lead to compromise at Software Quality agreements on Quality Matrix, while 38% responded in
negation of it and 15% said they are not aware about it.
The data collected in the requirement elicitation
without standard procedures is regarded as poorly The 82% from 47% who made agreements say that
gathered, while the design of the requirements also less than 40% bugs are reported after delivery of
needs a proper documentation to implement them. The software products. Unlike the other respondents who
design failing to clearly define requirement and not didn’t make any agreements told that 66% projects are
following any design standards is termed as poor found having bugs with more than 40% once projects
design. are delivered to clients. These figures of survey strongly
verify the Research assumption R-3.
The requirements gathering phase is not followed
by all the organizations considered in the survey. The • R-4: Satisfied employees produce High Quality
(Fig.3) represents the percentage of responses Software Applications
Factors Affecting Software Quality in Legacy Software… 317

The (Table 2) describes the responses of organizations performing less than 40% of total
satisfaction of employees with respect to their salary development on testing are found having 52% projects
package and working timing. with bugs. Similarly those organizations, which perform
more than 40% of total development on testing, are
We computed the responses of satisfied and
producing Good Quality products since 50% of their
unsatisfied respondents regarding their salary and work
projects are having below 20% bugs after release and
timing, to identify the impact on Quality of software
50% projects with less than 40% bugs; thus testing
products. The 43% of employees satisfied with work
properly make projects successful and bug free. The
timing stated producing Good Quality (i.e. blew 20%
survey results comply with Research assumption R-5.
bugs have been reported after its initial release) and
34% of satisfied employees regarding their salary Referring to (Fig.5), only 4 out of 47 (~9%)
package asserted Good Quality. On the other hand, respondents told that their organizations perform testing
below 20% of unsatisfied with respect to both salary in range 61% - 80% of their total development work;
and work timing told that the organizations where they similarly, 5 (~11%) perform in between 41% - 60%.
work, produce good Quality products. We performed
statistical testing (t-test) to validate the computed Total Testing performed in
responses. The t-test resulted statistically significant the
Research assumption R-4.
development
Table 2 : Employees satisfaction 18 16
16 15

Phase Name Yes No Don’t Know Total 14

12
Salary 19 20 8 47 10
8 6
Work Timing 26 13 8 47
6 4
• R-5: Higher than 50% of total development in 4
Testing Phase yields Good Quality Software 2
Products 0
Among 47 samples, 37 (i.e. 79%) said they possess 61%-80% 41%-60% 20%-40% below 20%
Quality Assurance Department within their
organizations and only 10 (i.e. 12%) reported its Number of organizations
absence. The (Fig.4) indicates the percentile of each city
having QA department and also they declared the Good Fig.4 : Total Testing performed
Quality products being developed since all these
respondents reported projects having below 20% bugs 5. FACTORS
after release. In this section, we summarize the findings that
cause software quality degradation according to survey
results as well as domain knowledge. The Research
Quality Assurance Department assumptions are verified among larger portion of
Availability participants. Therefore, factors highlighted in the
80% Research assumptions are strongly affecting the
60% software Quality. We discuss the key factors in detail in
60% 48% the following.
42%
40% 31%
5.1 Requirement Gathering and Design
20% Requirement gathering is one of the complex and
0%
difficult tasks in the software development; since,
clients are more likely to change their demands.
Islamabad Karachi Lahore Hyderabad Moreover, if the requirements aren’t properly defined to
development team, it may cause delays and waste of
Organizations in percentage time and effort. We found gathered requirement, being
designed properly helps to produce good Quality
Fig.3 : QA department availability products, and otherwise Quality is degraded.

While answering the Question about how much 5.2 Quality Matrix
work is done on testing out of total development; the The survey results indicated the role of Quality
obtained responses are illustrated in the (Fig.5). The Matrix at the stage of requirement gathering helps
N. MAHOTO et al., 318

organizations to meet the desired specifications. 5.6 Employees Satisfaction

Therefore, we recommend Quality Matrix as one of the Interest in the work makes it worthy; it has been
key factor that affects software Quality. observed in the survey, employee satisfaction regarding
their salary as well as work timing and environment
5.3 SQA Plan makes them comfortable to produce better results.
Indeed, Testing strengthens software Quality. Instead unhappy employees are more likely to perform
The organizations, which apply QA Plan for the testing in poor manner. Our hypothesis R-4 verifies our claim
of software deliverables, often succeed. 98% about employee satisfactions. In other words, employee
respondents stated their QA team majorly performs satisfactions affect the software Quality.
testing. However, only 33% answered as applying
Process Improvement. Survey showed the organizations 5.7 Communication Medium
having QA department, which following approved QA We also found that communication between
Plan from their QA team, produce better Quality development teams affects the overall development
software products in comparison with those phases. 79% of the respondents replied e-mailing as the
organizations that don’t have QA department. communication medium between teams. We
recommend the physical meetings between team
5.4 Level of Standards Applied members in order to clearly understand the requirement
Not only standard processes and procedures specifications. The misunderstanding about the
impact on overall Quality of software, but also the level specifications, which are provided in emails, may cause
of adoption of those processes within each phase of waste of efforts and time. In our findings,
development. The results described 43% of the communication medium between development teams
respondents said their organizations apply standard plays an essential role develop better Quality products.
procedures at medium level (i.e. ignore some levels) and 6. CONCLUSION
21% said they apply always standards at each level. The survey reported in this paper aims at studying
While 26% stated only a few levels standard processes and identifying the major factors affecting software
are applied. We recommend the standard processes and Quality during its development phases. The target
procedures at each level of development lifecycle in populations participated in the survey includes
order to get better software Quality. development teams of major cities of software
Moreover, among the standards ISO industries situated in Pakistan. The findings of the work,
(International organization for standardizations) being the limitation of the research, indicate the quality
standards were found being applied the most in the indicative parameters for the Pakistani Software
survey up to 38%, next IEEE (Institute of Electrical and Industrial Market.
Electronics Engineers) and CMMI (Capability Maturity Larger portion of participants verifies the Research
Model Integration) having 23% responses both. assumptions made in the study. The major findings, in
our work, describe requirement gathering, designing of
5.5 Project Delays the requirements, agreements of Quality Matrix at the
The 85% of the responses asserted the change of time of project contracts as one of the key issues, which
requirements during development phase that eventually are significantly important for the better Quality
causes delay in the projects. There are some other issues software deliverables. Furthermore, during development
regarding delay in the project delivery including standard processes and procedures, proper planning and
improper management, lack of planning for release testing, adoption of standards in development life cycle,
schedule and overload of non-productive work load (i.e. and communication between team members are also
unnecessary documentations). The faster development major concerns for the good Quality achievements. The
to release product deliverables on time, cause improper work also deducted satisfaction of employees as one of
checking of functionalities and testing; since main goal the key factor for the better results.
is to release in time; hence such hurry in development
compromise the Quality. We call project delays as a The findings are interesting and can potentially
factor degrading the software quality. support the software industries to manage the areas
discussed in our investigation.
The survey results indicated the role of Quality 7. ACKNOWLEDGMENT
Matrix at the stage of requirement gathering helps The authors are grateful to all participants who took
organizations to meet the desired specifications. part in the survey, and especially to Engr. Babar Tareen
Therefore, we recommend Quality Matrix as one of the for his fruitful suggestions in Questionnaire Designing.
key factor that affects software Quality. Boehm,
Factors Affecting Software Quality in Legacy Software… 319

REFERENCES:
Beck, K., M. Beedle, A. van Bennekum, A. Cockburn,
Jedlitschka, A., M. Ciolkowski, C. Denger, B. Freimut,
W. Cunningham, M. Fowler, J. Grenning, J. Highsmith,
and A. Schlichting, (2007) 'Relevant Information
A. Hunt, R. Jeffries, J. Kern, B. Marick, R.C. Martin,
Sources for Successful Technology Transfer: A Survey
S. Mellor, K. Schwaber, J. Sutherland, and D. Thomas,
Using Inspections As an Example', Proceedings of the
(2001) Manifesto for Agile Software Development,
First International Symposium on Empirical Software
Available: http://agilemanifesto.org/ [Accessed: 2015-
Engineering and Measurement, Washington, DC, USA,
04-12].
31-40.
B.W. (1988) 'A Spiral Model of Software Development Li, J., O.P.N. Slyngstad, M. Torchiano, M. Morisio, and
and Enhancement', Computer, vol. 21, no. 5,. 61-72, C. Bunse, (2008) 'A State-of-the-Practice Survey of
Available: http://dx.doi.org/10.1109/2.59. Risk Management in Development with Off-the-Shelf
Software Components', IEEE Transactions on Software
Chandola, V., A. Banerjee, and V. Kumar, (2009) Engineering, vol. 34, no. 2, March, 271-286, Available:
'Anomaly Detection: A Survey', ACM Computing ISSN: 0098-5589 DOI: 10.1109/TSE.2008.14.
Survey, vol. 41, no. 3, July, pp. 15:1-15:58,
Pressman, R. S. (2001) Software Engineering: A
Available: http://doi.acm.org/10.1145/1541880.1541882
Practitioner's Approach, 5th edition, McGraw Hill.
.
Royce, W. W. (1987) 'Managing the Development of
Ciolkowski, M., O. Laitenberger, and S. Biffl, (2003) Large Software Systems: Concepts and Techniques',
'Software Reviews: The State of the Practice', IEEE Proceedings of the 9th International Conference on
Software, vol. 20, no. 6, November, pp. 46-51, Software Engineering, Los Alamitos, CA, USA,
Available: http://dx.doi.org/10.1109/MS.2003.1241366. 328-338.
Scanniello, G., F. Fasano, A. D. Lucia, and G. Tortora,
Czaja, R. and J. Blair, (2005) Designing Surveys: A (2011) 'Software Quality Assessment and Error/Defect
Guide to Decisions and Procedures, 2nd edition, Identification in the Italian Industry: Preliminary
London: SAGE Publications.
Results from a State of the Practice Survey', ICSEA
2011 : The Sixth International Conference on Software
Dietterich, T.G. (1998) 'Approximate Statistical Tests
for Comparing Supervised Classification Learning Engineering Advances, 589-594.
Algorithms', Neural computation, vol. 10, 7, pp. 1895- Sommerville, I. (2000) Software Engineering, 6th
1923, Available: DOI: 10.1162/089976698300017197. edition, Pearson Education Asia.

Hauge, Q (2007) Open Source Software in Software Torchiano, M., M. Di Penta, F. Ricca, De A. Lucia, and
Intensive Industry - A Survey, NTNU Innovation and F. Lanubile, (2008) 'Software Migration Projects in
Italian industry: Preliminary results from a state of the
Creativity,Available:
http://www.idi.ntnu.no/grupper/su/su-diploma- practice survey', 23rd IEEE/ACM International
Conference on Automated Software Engineering - ASE
2007/dipl07-hauge.pdf [Accessed: 30-6-2015].
Workshops 2008., 35-42.
Jacobson, I., G. Booch, and J. Rumbaugh, (1998) The
Unified Software Development Process, 1st edition, Whitten, J. L., L.D. Bentley, and K. C. Dittman, (2003)
Systems Analysis and Design Methods, 6th edition,
Addison-Wesley.
Mcgraw-Hill.