25

CHAPTER2

Chapter – 2. Literature Survey

S. No. Name of the Sub-Title Page No.

2.1 Data Extraction and Selection Criteria .................................................................29

2.2 Contribution of Seminal Authors and their Clusters for Waterfall and Agile......30
2.3 Contribution of Seminal Authors and their Clusters for Agile Lean Software
Development ........................................................................................................30
2.4 Selection of Inclusion and Exclusion Criteria ......................................................35
2.5 Agile Success Survey ...........................................................................................41
2.6 Waterfall People ...................................................................................................42
2.7 Research Method ..................................................................................................47
2.7.1 Results and Discussion ..............................................................................51
2.7.2 Discussion on the Study of Waterfall, Agile and Lean Paradigms ............54
2.8 Poka-Yoke Practices.............................................................................................55
2.8.1 Introduction ................................................................................................55
2.8.2 Poka-Yoke Principles.................................................................................59
2.8.3 Poka-Yoke in Software Development .......................................................60
2.8.4 Software Performance Engineering using PY approach: An Example .....64
2.9 Research Gap ........................................................................................................64
2.10 Objectives and Research Questions (RQs) ...........................................................65
 26

2. Literature Survey

A literature search identified 2000+ among which filtered to a 1341 conference and
258 journal articles, a total of both 1599 articles from 2001 to 2014. Figure 2.1 shows the
number of conference papers from standard symposiums, workshops, tutorials like
International Conference on Software Engineering (ICSE), Agile and Agile Software
Development (XP), Symposium on Empirical SE and Measurement (ESEM), LESS (lean
enterprise software systems), Product-Focused SPI (Profes), EuroSPI and EuroMicro
conference on SE and Advanced Applications (SEAA), and some other papers from
different reputed forums. Table 2.1 shows different search key terms by ORed and ANDed.
It seems that waterfall to agile transition, adoption and transformation is drastically
increasing and shows good attention in research communities both from academia and
industry.
However, an outline of journal publications which is shown in figure 2.2reveals that
IEEE Software has a greater number, followed by IST, JSS and IEEE Transaction on SE.
Among non-software publication articles leading a journal is an IBM Journal of Research
and Development, Computing in Science and Engineering. Thus, waterfall and agile seems
to be not just in SE but in other interdisciplinary too.

Table 2.1 Search Key Terms

Waterfall and Agile Methodologies
Agile Software Development
Agile Artifacts
Agile Methods “ORed”

Agile and Lean Principles and

“ANDed”
Defect Detection using waterfall /agile methods
Poka-Yoke Principles in Software development
Performance Measurement in Process Models
Product Monitoring in Software Development

Figure 2.3 shows drastically increased research on waterfall and agile in both
journal articles and conference papers from 2001 to 2014. Similar fashion, done literature
 27

search for agile and lean software development, which shows a high-quality vigorous
research is going on the combination of agile-lean principles, agile-lean practices, agile-
lean adoption, etc. and a good number of articles and papers released into the education
market (figure 2.4).

Fig: 2.1 Total number of conference publications from 2001-2014

Fig: 2.2 Total number of Journal publications in scientific Journals from 2001-2014
 28

Table 1 in chapter-1 describes with six aspects of each model: model name, year,
author, pros, cons and applications. In this survey, mainly focus on waterfall, agile and lean
software development. Broadly speaking on these models endeavored to address issues
such as in waterfall model: defects all too often are detected too late in the software
development process, not supporting in terms of business value, clear costs and limitations
and difficult to maintain and upgrade due to lack of integration between software
components. In an Agile model, trusts that each project should be taken care of
contrastingly and the current methods should be customized to the best suit the task
necessities.

Fig: 2.3 Publications on Waterfall and agile from 2001 to 2014, total number, conference and journal
papers (top, middle and bottom)

Agile manifesto principles like customer collaboration, individuals and interaction,

responding to change, working software, and it addresses the issues on: knowledge and
experiment management, in education, teaching, academics and provides motivation
towards agile teams, transition, communities. Also, some article’s talks on artifacts,
analytics, process management, model driven development, and other interdisciplinary too.
 29

Some of the issues address by lean principles are unclear requirements, delay in a process,
a system of government, inevitable process repetition etc.

Fig: 2.4 Number of Publications with a combination of Agile and Lean Software
Development
2.1 Data Extraction
Table 2.2 shows the quality assessment and data extraction template.
Table 2.2 Quality Assessment and Data Extraction template

Extracted Fields Assessment Factors

Author Research Scholar / Experience
Title Relevant / Not Relevant
Year NA (Not Applicable)
Keywords Match / Not Match
Objective(s)/Issue(s) Clear / Not Clear
Research Question(s) (optional) Yes/No
Framework/Model/Method/Technique/Approach Yes/No/Other
Pros & Cons Detailed / Not defined
Case study/Empirical study/Survey Theoretical / Experimental/None
Future Scope Mentioned / Not Mentioned
Category and Sub-category Belongs to / Not Belongs to any
Published in a relevant journal/conference Yes / No
Cited by other authors Yes/No
 30

2.2 Contribution of Seminal Authors and their Clusters for Waterfall and
Agile
For better understand a field and their relationships, experts elaborated the use Co-
citation analysis, and also, it depends on authors, papers or co-citation, rests has they share
some theoretical similarity. This study is based on author documents similarity of work
done. The first and foremost step did is extracted the data from all 1341 conference and
258 journal articles, a total of both 1599 articles.
Table 2.3 and 2.4 shows the different categories and sub-categories of articles used in
waterfall and agile. Based on the cited references, relevance of two to three units of authors
work, a final cluster analysis is prepared in which included forty-nine authors. A 49 X 49
matrix of raw similarity was then computed in which 49 authors involving and mapping
between a pair of authors based on the data extracted. Instead of author co-citation analysis,
here used the Wards method by considering 5 level of conceptual similarity between two
or three authors. Figure 2.5 shows Cluster analysis of seminal authors for waterfall and
agile methodologies using the Wards method. For example, from figure 6 author’s
conceptual similarity can be expressed as, veeresh and susan[36] both of whom written
about comparison of agile and waterfall – implies that their works are closely and highly
related.
2.3 Contribution of Seminal Authors and their Clusters for Agile and
Lean Software Development
Similar fashion of waterfall and agile methodologies, A 39 X 39 matrix of raw
similarity was then computed in which 39 authors involving and mapping between a pair
of authors based on the data extracted. Table 2.5 shows different categories of articles on
agile software development and figure 2.6 shows Cluster analysis of seminal authors for
agile and lean software development using Wards method in which similarity concepts such
as lean in education, lean software development, agile-lean practices and principles, agile-
lean transformation, agile-lean adoption, agile-lean combination, defects detection,
elimination of waste, LSD in six sigma, etc.Jan Bosch (2013) [37] suggested and layouts a
set of lean development principles rather than agile practices.
 31

Table 2.3 Different categories of articles used in waterfall and agile

Category Number of Article(s) Author & Year

Hanssen and Dingsøyr (2002)
Maurer and Holz (2002)
Shan and Sena (2002)
Zhaohao Sun(2004)
Doran (2004)
Knowledge and 12 Fang et al. (2004)
Experience Management Bellini et al. (2005)
Crawford et al. (2006)
Salazar-Torres et al. (2008)
Thong and Chan (2009)
Dorairaj, Siva et al.(2012)
Education, Teaching, 2 Macek et al. (2011)
Academics, Motivation Ciancarini, P et al. (2013)
Holz and Maurer (2002)
Ying-Hong Liang et al. (2005)
Sfetsos et al. (2006)
McAvoy and Butler (2007)
Communication, Collaboration, Learning 13 Choi et al. (2008)
Layman et al. (2008)
Sfetsos et al. (2009)
Acuna et al. (2009)
Hannay et al. (2010)
Viktoria (2011)
Plonka, L (2012)
Deepti Mishra et al. (2012)
Parikshit Joshi et al. (2013)
Process Models 1 Yu Gao (2010)
Brown, J.M et al. (2011)
Agile Artifacts 2
Kuhrmann, M. et al. (2013)
FengJi et al. (2011)
Transition 3 Brian Katumba, (2014)
Sander Bannink (2014)
Requirements Rami Hasan Al-Ta’ani (2013)
2
Kassab, M. (2014)
UlrikEklund et al. (2012)
N. Cardoso (2012)
Agile Interdisciplinary John Langford et al. (2012)
6 Freiberger, M. et al. (2013)
MattiKaisti et al. (2014)
Ard, J. (2014)
Agile Analytics 1 Earley, S. (2014)
Agile Process Management (APM) 1 Aljaž Stare (2014)
Agile Empowerment 1 BjørnarTessem (2014)

Agile Communities 1 Maria Paasivaara et al. (2014)

Agile MDD 2 Yuefeng Zhang, et al. (2011)
José MatíasRivero et al. (2014)
 32

Wards method

Scale Factor

Fig: 2.5 Cluster analysis of seminal authors for waterfall and agile methodologies using Wards method
 33

Table 2.4 Different categories with their sub-categories of articles used in waterfall and agile

Category Sub Category Number of Author & Year

Article(s)
Comparison Waterfall vs Agile 2 M. Mahalakshmi et al. (2013)
Estler, H.-C et al. (2014)
Incremental vs Agile- 2 RizwanJameelQureshi, M. (2012)
XP AycaTarhan et al.(2014)
Methods Re-Prioritize 1 Trond Johansen et al. (2005)
Code Inspection vs 1 Wilkerson, J.W et al. (2012)
Test Driven
Development Staron, M. et al. (2013)
3 Schwanke, R., et al. (2013)
Risk PrawitSimmatun et al. (2014)
Case Study Agile Product Line 1 Jessica Díaz et al. (2014)
Architecting (APLA)
Agile Deployment 2 Olsson, H.H, et al. (2012)
M. Pikkarainen et al. (2012)
Agile Maintenance 1 Xiaoying Kong, (2011)
Risk Management 2 SuprikaVasudeva and Shrivastava et al (2013)
Sundararajan, S et al. (2014)
Christensen, et al. (2011)
Agile Methods 2 IvoneiFreitas da Silva et al. (2014)
Theoretical Theory 9 Zimmer (2003), Hazzan and Dubinsky (2005), Northover et
Perspective al. (2006), Pikkarainen et al. (2008), Mafakheri et al. (2008),
Trinidad et al. (2008), Browning and Levardy (2009), Cao et
al. (2009), Falessi et al. (2010)

Siva Dorairaj et al. (2012)

Grounded Theory 5 Dorairaj, S. et. al (2013)
Michael Watermanq (2013)
Guus van (2013)
Mawarny Md. et al. (2014)

Teamwork, 3 Moe et al. (2010),

Theoretical & Shared Diane E. Strode et al.(2012),
Mental Model Xiaodan Yu et al. (2014)

Johannessen and Ellingsen (2009)

2 Sharp and Robinson (2008)
Socio technical &
Distributed cognition
RupaMahanti et al. (2012)
Empirical Success Factors of 3 DraganStankovic et al. (2013)
Study Agile Meghann L. Drury-Grogan et al. (2014)
Survey Diff. Agile 1 KaushalPathak et al. (2013)
Methodologies
Agile Methodologies 1 GiulioBarabino et al. (2014)
in Programming
Agile Adoption 1 EfiPapatheocharous et al. (2013)

Agile 1 Sun-Wen Chuang et al. (2014)

Agile Methods 1 Stavros Stavru et al. (2014)

Metrics in Agile 1 Giuseppe Destefanis et al. (2014)
 34

Wards method

Scale factor

Fig: 2.6 Cluster analysis of seminal authors for agile and lean software development using Wards method
 35

Table 2.5 Different Categories of Articles used in Agile Software Development

Category Number of Article(s) Author & Year

Programming 4 Keznikl, et al. (2011)
Plonka, L (2012)
Lemos, O.A.L, et al. (2012)
Harleen K. Flora et al. (2014)

Agile Tools 3 Solis, C et al. (2011)

Azizyan, G et al. (2011)
Litoriya et al. (2012)

Agile-UX Integration 7 Salah, D (2011)

Silva da Silva, T et al. (2011)
Jean-Luc Agathos et al. (2011)
Isomursu, M. et al. (2012)
Ferreira, J (2012)
Ramos, A.L (2012)
Laura Plonka et al. (2014)

Agile System Engineering 2 Andrea Leitner (2011)

Stelzmann et al. (2012)

Agile Software Engineering 1 Ashley Aitken (2014)

Agile Team-Decision Making 11 Drury, M. et al. (2011)

Christoph J. Stettina (2011)
Mats AngermoRingstad (2011)
Stray, V.G., et al. (2012)
Meghann Drury et al. (2012)
Nils Brede Moe et al. (2012)
Stettina, C.J et al. (2013)
Stray, V.G (2013)
Nils Brede Moe (2013)
TorgeirDingsøyr et al. (2013)
DennizDönmez et al. (2013)

Agile Testing 5 Thopate, H et al. (2012)

Collins, E. et al. (2012)
Little, T. et al. (2012)
GuHongying (2014)
Guerra, E (2014)

2.4 Selection of inclusion and exclusion criteria

Each study that was retrieved from the manual search or an automated search is
formulated as in section 2.3 and was evaluated by thesis author and his both supervisors (a
total of three conductors).Divergences in the selection were work out by accordamong the
 36

three conductors in the wake of examining the whole paper.The following studies were
considered that met atleast one for the inclusion criteria:
 Studies presenting the process models that are used for monitoring the work.
 Studies reporting lean principles integrating with software development.
 Studies related to Poka-Yoke principles in a software development life cycle.
 Studies related to Fuzzy logic performance improvement in software development.
The following studies were excluded that met at least one for the exclusion criteria were:
 Papers that are not focused on the process models.
 Papers presenting only ideation without any practical orientation.
 Papers presenting only quality attributes like reliability, security and their related
metrics.
 Papers presenting only accessibility studies.
 Papers presenting fuzzy logic in other disciplines.
 Papers presenting techniques on how to improve performance and usability without
measures.
 Papers which are not justifying with industrial projects / another category of case
study(s).
 Preliminary papers for workshops, books, and special issues.
 Different sources published the same study i.e. Duplicate reports.
 Papers which are not written in English language.
The references of the selected studies (just those which had been observed to be most
significant in each digital library)were followed with a specific end goal to check whether
other applicable studies could be incorporated into the inquiry. This procedure allowed
validating the starting date of proposed systematic mapping study.
The following table 2.6 shows inclusion criteria and critical study for which few data
extracted fields shown to claim the research gap. The fields are title, author and year, details
of the paper, objective, methodology and paper future directions/limitations.
 37

Table 2.6 Inclusion Criteria

Title of the Paper Author Details of the Paper

A quantitative approach to monitoring Barbara A. et al. Software Engineering Journal January
software development [18] 1989, pp. 2-13
A Monitoring Framework for Software Ho-Leung Tsoi et al. IEEE Digital Library, 1999, pp. 1079-
Project Development [19] 1085
Controlling and Monitoring Agile Tjan-Hien Cheng et ICSE’09 Workshop, SDG’09, May 17,
Software Development in Three Dutch al. 2009, Vancouver, Canada, IEEE Digital
Product Software Companies [20] Library, pp. 29-35
Monitoring Bottlenecks in Agile and MiroslawStaron et al. PROFES 2011, Springer-LNCS 6759, pp.
Lean Software Development Projects – 3-16
A Method and its Industrial Use [21]
An Approach for Monitoring Software SunartWanapaisan et Proceedings of the International Multi
Development Using Timesheet and al. Conference of Engineers and Computer
Project Plan [22] Scientists 2013, Volume I,
IMECS 2013, March 13 - 15, 2013, Hong
Kong, pp. 1-5
Project Management Success I-C-E António Marques et ProjMAN 2013 - International
model – a work in progress [23] al. Conference on Project MANagement,
Science Direct Procedia Technology,
9(2013), pp. 910-914
Towards Artifact Models as Process M. Kuhrmann, D.M. Eighth IEEE International Conference on
Interfaces in Distributed Software Fernandez, M.Grober Global Software Engineering
Projects [24] (ICGSE),Bari, Italy, IEEE, 2013, pp. 11-
20.
“Leagile” software development: An Xiaofeng Wang et al. The Journal of Systems and Software 85
experience report analysis of the (2012) 1287– 1299
application of lean approaches in agile
software development [25]
A decade of agile methodologies: TorgeirDingsøyr et The Journal of Systems and Software
Towards explaining agile software al. 85(2012) 1213– 1221
development [26]
The Development of Zero Defect G. Gordon Submitted for the Shingo Prize for
Computer Software [31] Schulmeyer Excellence in Manufacturing, Research
Prepared for PYXIS Systems
International Incorporated, December 1,
1991, pp. 1–8
Using Poka-Yoke Techniques for Early Robinson, H in Proc. International Conference on
Defect Detection [32] Software Testing Analysis and Review
(STAR 1997), 1997, pp. 1–12
The Poka-Yoke Method as an Improving Dudek-Burlikowska Journal of Achievements in Material and
Quality Tool of Operations in the et al. Manufacturing. 36 (2009) 95–102
Process [33]
Performance Testing and Improvements Mukesh Jain In: Paper Excerpt from the Conference
Using Six Sigma – Five steps For Faster Proceedings of 28th Annual Software
Pages on Web and Mobile [34] Quality. October 18-19 (2010) 1-13
Poka-Yoke Student Organizations: Aaron Sprunger et al. in Proc. 2014 Industrial and Systems
Using Lean Principles to Increase Engineering Research Conference, 2014,
Effective Leadership and Success in pp. 1-10
Student Organizations [35]
 38

Barbara A. et al. [18] provides a procedure for monitoring software development to

improve the quality using metrics and this process of monitoring is based on a four stage
model of the interpretation of metrics. The four stage model identifies abnormal metrics
values, possible causes of exception, including distinguishes between causes. Also,
suggested some general principles to monitor throughout the development of software from
a requirement to integration testing phases. But this approach is done manually and it needs
in an automated interpretation.
Ho-Leung Tsoi et al. [19] given a monitoring framework to understand and check
all activities are running on schedule and address change problems during the development
of software. The stages of the framework is classified into acquisition and operation phase
in which acquisition phase involves development effort estimation, effort management
policy, and a historical effort database establishment as well as identified critical factors
related to development. Operation phase includes monitoring the reviews, development
effort and evaluated the collected information using metrics. Figure 2.7 illustrates the
activities in two phases.
Tjan-Hien Cheng et al. [20] addressed an issue related to software development
managers who are unaware of the complete progress and control on the product using a list
of key process indicators and interventions. Aspects considered for key process indicators
and interventions are a team, person, task and quality and suggested further detailed model
can be combine key process indicator as well as intervention to adopt other agile methods.
Figure 2.8 shows the control and measurement mechanisms in agile environments.
MiroslawStaron and Wilhelm Meding[21] shared their experiences on how a
mature software development organizations works according to agile and lean principles.
Authors considered existing projects, list out the indicators with respect to bottlenecks and
suggested good practices which help other organizations to monitor the bottlenecks in an
effective way. The concepts used to monitor the bottlenecks is throughput and queue and
measure for throughput and queue is identified for development and integration test only.
For other phases, it is not measured and this issue is suggested as future work.
 39

Fig: 2.7 Software monitoring framework (Courtesy: Ho-Leung Tsoi et al. [23])

To know the progress and success of the software projects during the operation of
development, SunartWanapaisan et al. [22] proposed a timesheet approach. This approach
monitored the progress by using staffs’ timesheet and compare with the work product that
have been completed by the staff and if any deviation in the project performance then alert
the project manager, so that improved the project plan too. As its’ future work authors
suggested developing a tool that can compare the staffs’ timesheet for different products
 40

and for analyze. This approach is quite different than the proposed approaches with respect
to methodology, collection of data, metrics.
M. Kuhrmann et al. [23] presented an idea in terms of a drafted model by integrating
three aspects: influencers, project characteristics and criteria to monitor work in progress
throughout the project management life cycle of all activities. But the model does not
support for different dimensions like completion of work, success factors, and prevention
mechanisms.

Fig: 2.8 Governance, Management andProcesses (Courtesy: Tjan-Hien Cheng et al. [24])

Marco Kuhrmann et al. [24] presented an artifact model for agile methods to monitor
projects and to track its progress on the basis of quality. From a given reference model, it
defines artifacts with its dependencies and this definitions serves as process interfaces to
 41

coordinate among different projects in a distributed environment. Still the artifact model
need to refine and generalized as a means to local software processes.
Xiaofeng Wang et al. [25] gave a superior comprehension of lean software
development approaches and how they are connected in agile software development using
30 experience reports published in past conferences of agile software.TorgeirDingsøyr et
al. [26] analyzed publications and citations to represent how the research on agile has
progressed in the 10 years taking after the articulation of the manifesto.
Authors also used wards method and categorical approach for easy mapping the
research undergone in agile concepts. One of the research directions gives that: at agile
conferences, a developing interest is evident on recognizing approaches to combine lean
principles with the development of software. It is one of the motivated lines to propose the
idea of this thesis and integrated lean manufacturing principle (Poka-Yoke) into the
software development life cycle. Other articles in table 2.6 (inclusion criteria) related to
Poka-Yoke principles are discussed in the next chapter 3.

2.5 Agile Success Survey

Agile Success Market Rates:
A project management consulting firm which is belongs to Standish Group working
since 1985, releases a yearly report entitled the CHAOS Manifesto. Their 2011 report
concentrated on agile project achievement rates versus waterfall. The general finding was
that agile projects succeed three times as frequently as waterfall activities. They evaluated
project data from 2002-2010 to bolster the discoveries in the report.The Standish Group
report characterized achievement regarding spending plan, timetable, and highlight
conveyance. See the accompanying outline (figure 2.7) from that report for the genuine
numbers.
Various distinctive studies have been led on the achievement and disappointment
rates connected with the agile and waterfall techniques over various areas, and the
outcomes are genuinely consistent. Ambysoft's 2013 Project Success Rates Survey
presumed that the agile technique has a 64% achievement rate, contrasted with only 49%
 42

for the waterfall model. Tested activities are characterized as tasks that were finished, yet
went over spending budget, time, or both.
The outcomes in figure 2.9 obviously demonstrate that the agile approaches convey more
fruitful activities than the waterfall model.
In the year 2010, 35% of the associations that utilized agile; just three years after
the fact, Actuation Consulting reports that, that figure has dramatically increased, to right
around 74%! That as well as this development is sponsored by genuine advantages:
Actuation Consulting study demonstrates that 86.9% of an agile client’s credit expanded
benefits to the adoption of agile. Agile is by a wide margin the most well-known strategy,
and in a larger part of cases, it is accepted to convey more esteem to organizations.

AGILE WATERFALL

8%
18%
Successful Successful
24% 49%
Challenged Challenged

Failed 33% Failed

64%

Fig: 2.9 Comparison of IT project success rates: 2013

There is developing an overview prove that agile works superior than traditional. The
review demonstrated that when individuals characterize accomplishment in their own
particular terms that agile tasks had a 72% achievement rate, contrasted and 63% for
conventional and 43% for off shoring. These figures are abridged and demonstrated that
individuals' involvement with agile software development was extremely positive.

2.6Waterfall People
A few sorts of organizations will dependably be more qualified to waterfall or different
methodologies, yet information lets us know that even those organizations are looking over
the wall. Actually, an Actuation Consulting survey demonstrates that 65.8% of waterfall
clients partner agile with expanded benefits; just 13.2% believe that an unadulterated
 43

waterfall methodology would prompt expanded benefits. The following figure 2.10 shows
how business needs meet the target using agility.

Fig: 2.10 Business needs meet the target using agility

Productivity
Somewhat High

Much Higher
4% 13%
1% Much Lower

22% Somewhat Lower

60%

No Change

Fig: 2.11 Comparison of productivity

Figures from 2.11 to 2.14 shows some results that are published in the last few
years regarding the effectiveness of agile software development compared with traditional
approaches.
 44

Quality
3% 6%

Much Lower
29% 14% Somewhat Lower
No Change
Somewhat Higher

48% Much Higher

Fig: 2.12 Comparison of quality

Client Satisfaction
3% 4%

Much Lower
31% 18% Somewhat Lower
No Change
Somewhat Higher
Much Higher
47%

Fig: 2.13 Comparison of client satisfaction

Cost of System Development

5% 5%

Much Higher
18% Somewhat Higher
32% No Change
Somewhat Lower
40% Much Lower

Fig: 2.14 Comparison of system development cost

 45

Figure 2.11 shows comparison with respect to productivity in which 60% is high,
comparison of quality shows in figure 2.12 in which 48% is high, from figure 2.13 shows
47%of client satisfaction is high and 32% of system development cost is lower which
shows in figure 2.14.
Following figure 2.15 indicates the challenges faced by organizations adopting
agile. The most difficult challenges are listed at the top.

Fig: 2.15 Difficulty levels in managing with agile

Figure 2.16 portrays current agileexperience with team size. Majority of agile teams
are small, with 20 or less individuals (this is valid with different standards as well). As
anyone might expect, it creates the impression that associations are discovering it less
demanding to succeed with littler teams than with bigger teams, additionally valid for
different paradigms.
Taking after figure 2.17 shows current agile experiences with geographic
distribution. At the end of the day discovered individuals reporting accomplishment at all
levels of geographic distribution.
 46

Additionally found that associations are likewise encountering disappointments at

all levels of geographic appropriation. Once again seeing better achievement rates less
dispersed teams are.

10 or Less

11 to 20

21 to 30

31 to 50
Failures
51 to 100 Success

101 to 200

201 to 500

501 Plus

0% 10% 20% 30% 40% 50% 60% 70% 80%

Fig: 2.16 Agile Experience with Team Size

Co-located

Under same roof

Within Proxmity Failure

Success
Work from Home

Distant Locations

0% 10% 20% 30% 40% 50% 60% 70%

Fig: 2.17 Agile Experience with Geographic Distribution

 47

2.7 Research Method

A survey has been carried out through a printed questionnaire and refer appendix A for
questionnaire survey details. Here, tried to know how ASD practices affect the performance
of software development projects, what are the important changes that are required and the
challenges involved in adopting these agile practices. This questionnaire was given to
software practitioners such as director, senior manager, manager, architect, team leader, a
developer, tester, who has experience practicing software development using both plan-
driven (traditional) and agile approaches and methodologies.
The information collected from the survey questions enabled us to enhance our
understanding of the critical changes required and the challenges/risks involved in
introducing ASD practices in organizations practicing plan-driven software development
methodologies (traditional). The likert statistical analysis points are depicted in Table 2.7.

The questionnaire was conducted and categorized on the basis of following agile factors:

a. Specification

b. Project Schedule

c. Team Work

d. Client Collaboration

e. Challenges/Risk Involved

A questionnaire was distributed to two teams working on software projects using

agile methodologies of a multinational Indian software company. The number of
respondents was 14 though the target was 25. The questionnaire results shed light on
the agile practices being followed. The team members were very much synchronized
and worked in unison. The questionnaire responses and the results reflected the same
with few different voices. Here, used a two level Likert scale and the responses were
collected from the respondents. As in [17] group wise questionnaire contents templates
are as follows.
 48

Figures from 2.18 to 2.22 show, questionnaire templates for the agile factor’s
specification, project schedule, team work, client collaboration and challenges/risks
involved.

Specifications of Project & Product

Sr. No. Questions
1. Is agile project management applicable in the context of product development?
2. Can certain agile practices be utilized for projects that are still carried out in traditional manner?
3. Does a project specification include an assessment of the functions of the product?
4. Are specifications prepared jointly by the client and the project team?
5. Should more emphasize be laid on face-to-face communication for conveying
information/specifications to and within the development team?
6. Are changing requirements welcome, even late during project/product development?
7. Are the team members always willing to continuously learn from one another and open for training
through mentoring and professionally guided discussions?

Fig: 2.18 Template for Specifications of a project and product

Project Schedule
Sr. No. Questions
1. Was the project divided into short (same length) cycles/iterations during which the team was focused on
individual functions (or set of functions) of the product
2. Do you try to make important project decisions rapidly within short timeframes?
3. Does your software development team rely on internalized, informal, undocumented plans (as against
formal documented plans)?
4. Do you believe in short, iterative, test-driven, and people-centric development?
5. Would you shift from lifecycle-based development to feature-driven evolutionary and iterative
development?
6. Do you measure and track progress based on working software?
7. Do you practice simple designs, processes, and approaches in your software development
methodologies?
8. Is agile project management applicable in the context of product development?
9. Can certain agile practices be utilized for projects that are still carried out in the traditional manner?

Fig: 2.19 Template for Project schedule

 49

Role of Team Work

Sr. No. Questions
1. The members in the team should be geographically co-located.
2. Work should be in small teams (no more than 4-5 members) in the projects.
3. Team members should regularly discuss their mistakes and learn from them
4. In most cases, communication and negotiation in the projects happen between people who are physically
close to one another.
5. In most cases, communication and negotiation in the projects happen between people who work in the
same (similar) time zone.
6. The business team and developers should work together daily (closely) throughout the project.
7. The development teams should be self-organizing to meet the changing requirements and the newly
arising challenges of the business.
8. At regular intervals, the team should reflect on how to become more effective.
9. The team generally should consists of technically competent and experienced people
10. The majority of members of the team should have similar social culture, even though they might be
belonging to different nationalities and provinces.
11. The team members should in general always be willing to continuously learn from one another.

Fig: 2.20 Template for Role of Team work

Client Collaboration
Sr. No. Questions
1. Should customers closely collaborate with the development team members?
2. In software development projects, customers are committed to the project, i.e., they are motivated, active,
and consider themselves to be responsible elements of the project.
3. In the projects, a very high priority is given to achieve customer satisfaction.
4. Customer/client should propose and evaluated (cost, value added) changes together with the team.
5. Customer/client user should participate in the development of test procedures.
6. Software development project team follows continuous attention to technical excellence and good design
for development.
7. Customer satisfaction has given a high priority through early and continuous delivery of valuable
software.

Fig: 2.21 Template for Client collaboration

 50

Challenges/ Risks Involved

Sr. No. Questions
1. Problems arise within development teams that are geographically distributed and not co-located in agile
development.
2. Differences in productivity between team members in agile software development.
3. Challenges of the agile teams in integrating the development processes and subsystems with teams within
the same organization practicing traditional development methodologies.
4. Adopting agile methodologies for use in legacy systems, which are more resistant to changes in internal
source code.
5. Problems with selecting the appropriate agile methodology and the supporting tools according to
organizational needs and characteristics.

Fig: 2.22 Template for Challenges/Risks involved

Table 2.7 LIKERT statistical analysis

Program Name Specifications of Projects & Products

Q1 Q2 Q3 Q4 Q5 Q6
Total Points Received 11 6 5 3 12 11
Total Points Possible 28 28 28 28 28 28
Mean 0.785 0.428 0.357 0.214 0.857 0.785
Standard Deviation 0.426 0.514 0.497 0.426 0.363 0.426
Response Rate 56% 56% 56% 56% 56% 56%
Program Name Projects Schedule
Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9
Total Points Received 14 13 7 12 10 10 11 10 11
Total Points Possible 28 28 28 28 28 28 28 28 28
Mean 1 0.928 0.5 0.857 0.714 0.714 0.785 0.714 0.785
Standard Deviation 0 0.265 0.855 0.363 0.469 0.469 0.426 0.469 0.426
Response Rate 56% 56% 56% 56% 56% 56% 56% 56% 56%
Program Name Role of Teamwork
Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Q11
Total Points Received 13 4 13 3 12 14 14 14 14 3 14
Total Points Possible 20 20 20 20 20 20 20 20 20 20 20
Mean 0.9285 0.285 0.928 0.214 0.857 1 1 1 1 0.214 1
Standard Deviation 0.267 0.469 0.267 0.426 0.363 0 0 0 0 0.426 0
Response Rate 56% 56% 56% 56% 56% 56% 56% 56% 56% 56% 56%
Program Name Client Collaboration
Q1 Q2 Q3 Q4 Q5 Q6 Q7
Total Points Received 14 13 14 12 13 14 14
Total Points Possible 20 20 20 20 20 20 20
Mean 1 0.928 1 0.857 0.928 1 1
Standard Deviation 0 0.267 0 0.363 0.267 0 0
Response Rate 56% 56% 56% 56% 56% 56% 56%
Program Name Challenges/Risks Involved
Q1 Q2 Q3 Q4 Q5
Total Points Received 2 13 13 13 14
Total Points Possible 28 28 28 28 28
Mean 0.142 0.928 0.928 0.928 1
Standard Deviation 0.363 0.267 0.267 0.267 0
Response Rate 56% 56% 56% 56% 56%
Number of Likert Scale Options 2
Questionnaire Participants 14
Total Possible Participants 25
 51

2.7.1 Results and Discussion

After examination of the factor: specifications of project and product resulted in
the responses as in figure 2.23. Applicability of agile practices for the current undergoing
project was found to be 79%, scope for migrating from traditional practices to agile
practices was found to be 43%, assessment of product functions was found to be 36%,
22% of the project specifications were jointly prepared by a client and the project team,
86% recommendation for face to face communication was given, changing requirements
are anticipated and welcomed by 79% of respondents to the questionnaire and 86% of the
respondents have shown the willingness to learn. After examination of the factor: project
schedule resulted in the responses as in figure 2.24.
100% respondents affirmed that the modules were divided into short cycles with a
focus on functions, rapid decision making was recommended by 93%, 54% rely on formal
document plans, iterative, self-drive, people centric development was recommended by
86%, migrating to iterative development was recommended by 71%, progress tracking on
working software is done by 71%, simplicity is followed by 78%, 71% say agile is
applicable in the context of product development and possibility of migration is suggested
by 79%.

Fig: 2.23 Specifications of Project and Product

 52

Fig: 2.24 Project Schedule

Fig: 2.25 Role of Teamwork

After examination of the factor: Role of Teamwork resulted in the responses as in

figure 2.25. 93% suggested geographical collocation of team members is needed, smaller
team size is recommended by 29%, 93% recommend periodic interaction among team
members, 21% suggest physical proximity leads to higher communication, 86% feel a
 53

similar time zone leads to better communication, 100% suggest business and developer
team should work together and as well self-organizing teams ready to take challenges.

Fig: 2.26 Client Collaboration

After examination of the factor: Client Collaboration resulted in the responses as in

figure 2.26.

Fig: 2.27 Challenges/Risks Involved

 54

Close collaboration, technical excellence, good design, customers satisfaction are

high priority with a rating of 100%, customer commitment and custom client equal
stakeholder ship in test procedures has a rating of 93% while in cost evaluation, it is 86%.
After examination of the factor: Challenges/Risks Involved resulted in the responses as in
figure 2.27. An appropriate tool selection problem got a 100% rating, differences,
challenges of integration; adoption got 93% rating.
In this section a critical review of agile practices being adopted in a software
company is done. Using questionnaire and likert scale, analyzed the impact of various agile
factors on team members. Project specifications, teamwork, risks, challenges and other
agile factors effect on the team was acquired using a questionnaire and using likert scale it
was quantified. Face to face communication, dividing the modules into small iterations,
client and developer collaboration, appropriate tool selection was few of the factors which
rank high among the team members using agile methodologies for software development.
2.7.2 Discussion on the Study of Waterfall, Agile and Lean Paradigms

The main aim of the study is how research in moving drastically in different
classifications of waterfall, agile and lean and issues which are not resolve up to the
satisfaction of the customers. Challenges: After the study of different articles, it seems that
for developing large or complex software application, the challenges are effort intensive,
schedule slippage, high cost, long development time, kept up-to date, changing needs for
users, high risk of failure, user acceptance, performance, poor maintainability, ad hoc
software development, efficiency, usability, etc. and some discussion is done in [26], [43].
To design, develop the needs of customer specifications efficiently, cost effectively
and to ensuring quality need an artifact. The artifact need to contain: injected by scientific
principles with well-defined approach like engineering approach (guidelines), plan and
schedule-work, involvement of a user in defining requirements, schedule reviews, define
milestones, identify stages in development, plan extensive testing, define deliverables. For
success in large software development it is important to follow an engineering approach,
consisting of a well-defined process.
 55

A process can be defined as set of activities or steps to be carried out in a particular

order and a software process deals with both management and technical issues. Different
types of processes: it can be for software development, for managing the project and for
change and configuration management. Process for managing the above types need to
follow well-defined steps with the help of techniques, tools, guidelines, skills and efforts.
A good characteristic of a process is predictable when it do the best in cost and
effort, reduce the number of defects, increase performance, but this can be predicted using
statistical control where it meets actual values nearly to expected values.
Based on the survey on waterfall and agile it seems that a good process persuasive
the progress by early detection and removal of defects. This can be done by facilitate
monitoring and improving based on feedback, using a new sort of tools, technologies,
measurements. On the survey of agile and lean, found that by integrating principles of
software engineering and lean manufacturing principles in the process of software
development bestows good improvements. Next, section talks about the one of the lean
manufacturing and lean IT mechanism called a Poka-Yoke (PY) principle which is used to
detect and prevent the mistake early in the development process of any online services,
websites, and software.

2.8 Poka-Yoke Practices

2.8.1 Introduction

Poka-Yoke (ポカヨケ) is a term of Japanese that means "mistake proofing" [27].

Poka-Yoke (PY) is a mistake proof technique used in lean manufacturing. The technique
is being explored for the entire software development life cycle. A PY in a lean
manufacturing process helps an equipment operator to avoid (which means yokeru)
mistakes (means Poka). By anticipating, adjusting and/or drawing consideration/alarm to
human errors as they happen eliminate product defects. Shigeo Shingo (figure
2.28)formalized the concept and adopted the term as part of the Toyota Production System
in the 1960s’. It was originally called as baka-yoke but which gives the meaning as "fool-
proofing" or also called as "idiot-proofing," so, the name was changed to Poka-Yoke and
 56

the process of zero defects is known as “Mistake Proofing” or also known as “Fail-Safe”.
To pursue more value added activities, PY can free workers’ time and mind by accepting
control tedious endeavors or exercises that depend upon watchfulness or memory. For more
information refer [27] [28] [29].
Background:

Fig: 2.28 Author Shigeo Shingo

Poka-Yoke tool can be used to

• Develop answers for anticipate failures before they happen or to distinguish
mistakes and make it unthinkable for them to be gone on to the next step of the
process.
• In the improvement of the new process or in a current process where rework to right
blunders is harming process adequacy and effectiveness.
Poka-Yoke Examples [30]:
Figures from 2.29 to 2.31 show different Poka-Yoke examples. Figure 2.29 shows
Poka-Yoke example on a word document in which if any incorrect word typed then it
highlights with red color and if any incorrect in sentence formulation then highlighted with
green color. These highlighted mistakes with different colors is Poka-Yoke.Similarly in
figure 2.30 and 2.31 highlights the mistakes with different colors in Google search and
checking the password strength in filling any social network applications.
 57

Fig: 2.29 Poka-Yoke examplefor Microsoft word

Fig: 2.30 Poka-Yoke example for Google search

Fig: 2.31 Poka-Yoke example for Password strength

Poka-Yoke Detection:

Figure 2.32 shows Poka-Yoke detection example in which if any nut is misplaced under
the welder then automatically buzzer sound raised.
 58

Fig: 2.32 Poka-Yoke Detection

Poka-Yoke Elimination:

Figure 2.33 shows Poka-Yoke elimination example in which if any one insert the chuck
into the machine in reverse order then it’s not works properly.

Fig: 2.33 Poka-Yoke Elimination

Advantages of using Poka-Yoke tool are:

• PY solutions are very simple, less in cost, reduce rework.
• Human errors are treated as mistakes that result from incorrect intentions or
performing correct intentions that effect in unintended outcomes.
 59

2.8.2 Poka-Yoke Principles

The following table 2.8 gives different types of principles as per the shigeo shingo a
standard book on Zero Quality Control [27].
Table 2.8 Principles of Poka-Yoke (Mistake-Proofing)

Principle Objective How & Preference

Prevention Eliminate the possibility of Error / Redesign / Modify the process or product so
Avoiding Mistakes that the task is no longer necessary (Best)
Replacement Substitute more reliable process Using Robotics or automation process
(Better)
Facilitation Making the work easier to perform Color-Coding, Integrating steps, Icons,
Shapes etc. (Better)
Detection Detect the errors before further Developing computer software which alerts
processing a developer when a wrong input is made
(Better)
Mitigation Minimizing the effect of error Utilize fuses for overloaded circuits (Good)

Table 2.8 tells different principles of mistake proofing and their objectives, when
any mistake happens then apply the procedure to avoid it. For example, when defining the
potential mistakes, list the errors which could be exchanged to the following stride in the
process and apply the tools such as brainstorming etc. When it needs to identify root causes,
investigate and analyze the root causes using 5 whys or Fishbone techniques. Detailed
procedure with guidance, risks occur and how to avoid it is shown in table 2.9.
Zero Quality Control (ZQC) is the concept of quality to manufacture / develop zero defects’
product by eliminating waste associated with defects.ZQC consists of four elementary
components: 100% Audit checks, Point of Origin, Poka-Yoke, and immediate feedback.
Shigeo defines “A method that uses sensor or other devices for catching errors that may
pass by operators or assemblers is said to be PY”.
PY effect two elements of ZDQ: PY and Point of Origin Inspections which is used to
identifying defects immediately (Proactive approach), other is PY and Informative
Inspection used for correcting the action with the help of quick feedback.
 60

Table 2.9 Procedure to use Poka-Yoke for avoiding mistakes

Procedure Guidance Risk and How to avoid them
Define the potential List potential mistakes / errors which Combine this with other tools
mistakes /errors could be transferred to the next step in (such as brainstorming)
the process
IdentifyRoot Causes Investigate and analyze root causes Use other techniques such as Fishbone
and 5 Whys for this step
Develop ways to Brainstorm potential solutions for Find ways to make it impossible to do
prevent errors preventing the error something incorrectly
Develop ways to Brainstorm ideas to detect the error / Make it obvious when something has
detect errors deviation or mistake early been done incorrectly. E.g. make a
system to identify product defects by
testing the product's shape, size, color,
or other physical attributes
Create & test Develop solution to prevent or detect Consider characteristics of Poka-Yoke
solution errors and test that it is effective solutions:
Simple and low cost.
Part of the process.
In place where the mistake can occur.
Does not let the mistake exit the process.
Implement solution Implement solution and control output is Measure the success of this Poka Yoke
effective (i.e. Errors are prevented process. Check if this technique has
and/or detected) really prevented or caught defects when
happening

2.8.3 Poka-Yoke in Software Development

Gordon Schulmeyer (1991) has discussed Shigeo Shingo manufacturing principles
applied to a computer software development arena with the help of tools by providing
automated mistake proofing [31]. Fagan (1976) define a process “is set of operations
happening in a clear arrangement that works on a given data and proselytes it to some
sought yield”. Definite input and desired output means that the sequence of operations that
act on input must be correctly placed and output of each operation need to satisfy for the
next input operation. From the words of DeMarco (1982), correct the system instead of
correct the program. Michael Fagans (1976) used an inspection model to improve the
quality of a software development by providing several inspection charts for requirements,
design, coding and testing.
Shigeo Shingo (1986) has sketched out a process cycle for supervision of errors and
defects as shown in figure 2.34. Shingo describes judgment, informative and source
inspection methods for discovery, reduce and eliminate defects [27]. Statistical Quality
 61

Control Systems (SQCS), Self-Check Systems (SeCS), and Successive Check Systems
(SuCS) are three categories under Informative inspection method. Amongst SeCS is a
higher order approach than SuCS because it avoids abnormalities immediately during the
process of software development by installing Poka-Yoke (PY, In Japanese Mistake-
Proofing) devices physically within the process.

Check
and
Feedback

Defects
Action

Cause
Check&
Action
Feedbac
k

Errors

Fig: 2.34 Cycle for Managing Errors and Defects (Shigeo-[27])

PY Approaches (Control and Warning Approach)

PY Methods (Contact, Counting, Motion Sequence,
Coloring, Shape, Icon, Symbols, Red-Flags)
Sensing Devices / Error Proofing Devices
(Physical contact, Energy Sensing, Warning sensors,
Checklist, Detectors, Meters, Readers, Counters )

Fig: 2.35 Three Tier Model of Poka-Yoke System

With respect to the above tiers in figure 2.35, three rules are framed for PY: Don’t wait for
perfection, do it immediately; for succeeding if a PY idea is satisfying 50% then do it;
lastly, does it now, later improve.
 62

Using the above methods successfully demonstrated in manufacturing, now the

time comes to apply the same and demonstrates similar success in software development
too.
Hewlett Packard introduced PY into their Common Desktop Environment software
and prevents hundreds of defects before that reached to their customers. The Primary goal
of quality assurance is bug prevention rather than the second goal bug detection [32]. As
part of this, Boris Beizer (1990) addressed a different author’s championed detection and
prevention methods in the development of software [36]. Steve Maguire (1993) represents
a similar sentiment in Writing Solid Code, in this book raised two questions: Prevention
and Detection devices in software [37]. Unit and smoke testing are very closer to the notion
of PY, which keep mistakes moving from one location to another throughout the process.
Ian Darwin addressed some closely resemble programs such as clash, cchk, lint etc.
for examining the syntactical representation of the program and gives alert to the
programmer before making a mistake indeed for correction. Also, eliminating of classes is
done using utilities in Static Analysis [38].
In the field of PY, a good number of articles and literature is available in product
design methods, programming testing methods, and management (Harry Robinson-1997,
Burlikowska M. Dudeket al.-2009, and Chao Lawrence P et al.-2003). These
recommendations are magnificent exhibitions of how PY outline approach can bring about
enhanced service performance and user-experience design with a less amount of defects in
their particular domains. Unfortunately, major research gaps between PY and Software
Engineering keep on existing in industrial practice, academics, and literature.
As of late, research on applying PY in software industry has become much
consideration [31], [32], [36], [39] and diverse methodologies talk in [31]. The standards
of PY (essentially utilized as part of generation to commit the procedure error verification,
this keeps individuals from committing errors and if oversights are made, they are gotten
right on time in the cycle) [33], [40].
According to AdzicGojko, creator of Impact Mapping "programming classes ought
not to permit us to continue and explode when something turns out badly. Special cases
 63

can be a compelling method for giving more documentation and however the sign ought to
be clear and unambiguous, all together not to delude clients or customer engineers.
Programming must be intended to keep a complete accident, even notwithstanding
framework failure. Auto-save components are a decent sample. "It's not frequently that the
power gets cut, but rather when it does, our clients will unquestionably value that saved a
large portion of their work [40]". A great part of the exploration center is for ZOC, quality
control, recognizing defects. Then again, the restriction that the related exploration brings
is not making a difference PY in whole.
Adzic (2012) has discussed mind-map (impact map) creation collaboratively with
senior technical and business people for answering questions like why, who, how and what.
This visualization map gives a big impact over software products and projects [40].
The PY principles also applied in education ZbigniewPrusak (2004) and Aaron
Sprunger, ChinweikeEseonu (2014) addressed the concepts of sensitivity, variability and
robustness and listed mistake proofing principles done by the students [35]. Also,
addressed lean principles integrated in PY for effective leadership in student organizations
[41]. In 2010, Mukesh Jain described a Six-Sigma based improvement model to analyze
end-user expectations, the effectiveness of the online services provided by Microsoft like
Hotmail, Bing and MSN [34].
ArashShahin and Maryam Ghasemaghaei has proposed a framework with the
technique PY for calculating the effectiveness of quality at design and delivery stages of a
product by assuming service recovery and service PY are post and pre solutions on service
fail-safing[42].

2.8.4 Software Performance Engineering using PY approach: An Example

Highlight of the current state of Microsoft online service performance in major regions,
challenges. Five steps PY based approach used in Microsoft to improve performance across
their online services.Refer appendix-B for detailed usage of PY in Microsoft online
products.
 64

2.9 Research gap

Even though the earlier waterfall model and the recent model, Poka-Yoke was used
at the company for several years, improvement of software development in practice within
a large-scale industry identifies a lot of issues. The earlier model of waterfall model
requires high costs and efforts. That is, it involves an endorsement of numerous archives,
changes are expensive to implement, emphasizes acquire a lot of rework and effort, and
issues are commonly pushed to later stages. If consider the recent model Poka-Yoke, it is
combined with the sigma model to improve software performance, but in reality, the
software performance is majorly affected with the other phase of software development
compared with quality measurement. By analyzing the literature of waterfall model and
Poka-Yoke concept, literature review has identified numerous research gaps, which is
utilized to address in this research. Following are the identified research gaps in the
literature:
(1) From the literature review, there is no case study of identifying the impact of the PY
concept to meet customer requirements, manage processes, measure design,monitor
success, and to improve business performance using UGAM and IOI.
(2) Even though there is some research done on quality measurement of software, the case
study for quality measurement by considering the real time software system was not
done.
(3) Most of the research related to the Poka-Yoke concept was not carried out in the
software industry and there was not any research done that is related to product
monitoring of SDLC.
(4) There is no research carried out to see the impact of a Poka-Yoke concept for error
monitoring and subsequent controlling of human error.
(5) It also found that much research done on quality improvement but product monitoring
is the main dependent variable required for all the phase of SDLC except product
definition.
 65

2.10 Objectives and Research Questions (RQs)

This research aims to develop new approaches for the following two objectives and
formulated research questions are illustrated in figure 2.36:

Fig: 2.36 Formulated Key Research Questions

OBJECTIVE 1:
How to design an alternative model for mistake proofing in a small and expansive
scale development of software which strengthens for services and products with high
quality desires? To tackle the above problem, detailed the genuine proposed procedure of
High Quality in a Large Scale development of software improvement using PY principles
(HQLS-PY) which solves the following Research Questions (RQ):

 RQ-1: How to influence principles of PY for inspecting each of the phases in software
development life cycle and how things can be arranged and outlined upfront to avoid
from finding issues late in the SDLC?
 RQ-2: How to create a model for implementing the variabilities in the connection of
Software Product Lines furthermore meets industry principles?
 66

 RQ-3: How to quantify design, oversee procedures, enhance the performance of the
business, meeting the requirements of customers and to monitor achievementby using
standard metrics?
 RQ-4: Which opportunities infuse to inject product monitoring at the right place to
capture the user experience, product quality and alerting at the right time?

OBJECTIVE 2:
When analyzing the activities involved in a software development of thesmall scale
companies, found out that lot of mistakes can happen at every stage and these mistakes
cannot be identified by the top level management. Also, management should aware about
the progress and mistakes happening in the software development at every stage as per
Poka-Yoke concept. The software company struggle, the following operations which cause
the overall delay of the operations. i) Daily activity evaluation and finding the goal reached,
ii) A progress bar to easily monitor the improvement level of a product, iii) Hierarchical
monitoring of the work activities and mistakes, iv) No numerical values to know about the
progress of the project, v) Human errors which come from the need to prevent human action
from a leading system to undesirable states. These attributes are important for the company
to improve software performance in terms of cost, time and energy. Based on this objective,
the following research questions are formulated for monitoring the process of software
development using Poka-Yoke concept with fuzzy theory.

 RQ-5:Does the monitoring phase play a major role in a software development cycle
to improve the software quality?
 RQ-6: Can the fuzzy logic integrated with the Poka-Yoke concept improve software
performance using the traditional metrics?
 RQ-7: Does the proposed FPYM model applied to the different companies have good
correlation in the improvement?
 RQ-8: Choosing four metrics that are considered in the research work, what is the
performance that is forecasted for future products in terms of said four metrics?
 67

The following are the list of chapters which solves the above research question:

 Chapter 3 solves RQ1, RQ2 and RQ3

 Chapter 4 solves RQ4
 Chapter 5 solves RQ5 and RQ6
 Chapter 6 solves RQ7 and RQ8