Iteration Causes, Impact, and Timing in Software Development Lifecycle: SLR

Context: Iteration—performing an activity once it has already been done—is unavoidable and omnipresent during software development. Management of iteration is a challenging task due to the lack of detailed analysis and use of different terms for the iteration at different places in software engineering. Objective: In order to manage iteration in a better way during software development processes, we investigate different iterative situations, the causes, the stages at which it can occur during the development, and its impacts. Method: We use the systematic literature review (SLR) method to search using six bibliographic databases. The SLR includes 153 primary studies published from 2007 to February 2017. Results: We identify twenty-two leading causes, five stages, and positive and negative impacts of iteration. Then, we develop a lucid taxonomy of iteration perspectives based on the causes and timing at which it occurs during the software development lifecycle. Conclusions: The frequently reported causes of iteration are defects, code smell, and conflicts, whereas the least referenced causes are poor management and different methods followed by teams. The most cited phase at which iteration occurs during the software development is maintenance. The most cited positive consequence of iteration is quality improvement, whereas the negative impacts of iteration are increasing time, effort, and cost. Our study provides a framework to understand the nature of iteration, what sources can lead to which iterative perspective, a particular iterative situation can have what kind of impacts on project milestones, and also provide research directions.

ment [16]. Different design options are explored at the start of the project and during architectural design during software development. For example, the negotiated decisions are considered better with different stakeholders' concerns and alternative choices [15]. Whenever a change occurs due to any reason, it causes iteration linked with delays, extra cost, additional efforts, and risks. The reason for redoing can be defects, unexpected errors, or ambiguous user requirement specifications. Another study suggests that in the embedded system development, adjustment of the requirement is made in later phases. It causes unplanned and expensive iterations for making many adjustments to deal with defects at this stage [17].
Detailed studies of iteration exist in product development [18,19,20,21], construction [22], design [23,24,25,26,27], and engineering disciplines [23,26,28,29], whereas very few authors discuss them from software development viewpoint [5]. A study contribute by gathering and summarizing insights into iteration. They also create a comprehensive taxonomy of iteration in design and development discipline with the selection of a few articles from software engineering literature [27]. Another study contribute by modeling iteration in software engineering and simulating its impact on project completion time but it lacks detailed analysis of different iterative situation [5].
Iteration is unavoidable and part of the software development process. Despite the iterative nature of the software development life cycle, the least attention is paid to the detailed iteration analysis in software engineering. Research literature addresses different benefits and weaknesses of iteration that are ambiguous for the readers. For project managers and researchers, it is often impossible to understand the context. The problem gets complex by using vague terms to refer to iteration, sources, and impacts at different places. In this way, the management of iteration becomes a challenging task. Though iteration is ubiquitous during software development, a detailed analysis does not exist. Therefore, the management of iteration is a difficult task.
This article analyzes current knowledge about iteration in the software development discipline to understand iteration by conducting an SLR. We investigate the sources of iteration, impacts of an iterative situation, and timings of the development cycle at which it can occur. The contribution of this study is the development of a lucid taxonomy of iteration in software engineering, which describes that the different perspectives on iteration have different sources, timings of occurrence, and impacts. Furthermore, this study also demonstrates how taxonomy can be based on literature and used to map present studies. It is a step toward analyzing iteration in software engineering to understand different iterative situations that highlight new research directions.
The remainder of this paper continues in eight sections. Section II presents the research goal, questions, methodology to conduct SLR, and quality assessment of the studies. Next, statistical findings from selected primary studies are described in Section III. Section IV discusses the different FIGURE 1. Systematic Literature Review (SLR) methodology adapted from [30] sources that lead to iteration during software development. Stages at which iteration occurs during SDLC are discussed in Section V. Section VI presents the positive and negative consequences of iteration which exist in the software engineering literature. In section VII, we explain the proposed iteration taxonomy and its validation based on the finding of SLR. Threats to this review are explained in Section VIII. Finally, conclusions and future directions are presented in Section IX.

II. RESEARCH METHODOLOGY
The research was conducted through a systematic literature review. According to the guidelines, the SLR process comprises of three core phases, i.e., planning, conducting, and reporting [30]. The methodology followed, and the activities performed in each phase of the SLR process are shown in Figure 1.
The first step in the methodology ( Figure 1) is describing the need for the SLR. This SLR was driven by the lack of a detailed analysis of iteration in software engineering. Iteration is omnipresent during software development [2,15,31,32,33,34]. Despite the iterative nature of software development, very little attention is paid to iteration in software engineering. None of the publications in software engineering has treated iteration as the main subject. The use of diverse terms to refer to iteration at different places in the literature also contributes to this SLR's need.
We searched ACM, IEEE, Science Direct, Scopus, Google Scholar, and Springer digital libraries in September 2016. In the retrieved studies, the authors do not explicitly mention different iteration perspectives. A detailed, in-depth analysis was conducted to get insights into iteration.

A. RESEARCH QUESTIONS
This SLR aims to investigate the different perspectives of iteration that exist in software engineering. In order to define different perspectives and create a taxonomy of iteration in the software engineering discipline, the stage at which iteration can occur, the cause or source of iteration, and its impacts in the development cycle need to be determined. This is reflected in one primary and four secondary research questions described in Table 1 (Step2, Figure 1).

B. SEARCH STRATEGY
In developing the review protocol (Step 3, Figure 1), the search strategy is defined to include related studies and exclude unrelated ones. The strategy involved an automatic search using a string validated by the authors of the present article. Search in digital libraries was performed using search string. The string was specified using keywords derived from research questions. We identified alternative spellings and synonyms for the keyword to compose the search string. Our search string comprised of three parts: iteration, software development, and lifecycle. Keywords are connected through AND operator and synonyms are connected through OR operator. Automatic searches consisted of the web search of the most relevant indexed databases. The digital libraries searched and results returned are given in Table 2. We refined the search string through a pilot study and omitted the synonyms, which did not influence the paper returned via searches. We come to the following string after refining the string through several iterations.
(Iteration OR Rework OR Refinement OR Refactoring OR Negotiation OR Exploration) AND (Agile software development OR Software engineering OR software project) AND (Lifecycle OR process OR activities)

C. INCLUSION AND EXCLUSION CRITERIA
For a study to be included in the review as a primary study, it must fulfill the inclusion criteria summarized in Table 3, and it must not meet exclusion criteria presented in Table 4. We were concerned only in primary studies, between 2007 to February 2017, which are on software development lifecycle or any phase of the development process and present some contribution on the iteration during development. Validation of the review protocol (Step4, Figure 1) is performed by the authors of the article. Studies which was about software development but did not contain any information about iteration 8 Books, book chapters, Symposium, and news letter on software development processes 9 Redundant studies 10 Literature reviews

D. STUDIES SELECTION PROCESS
Primary studies were selected by following four stages process presented in Figure 2. Each stage of the study selection process is described in the following paragraphs.
In stage 1, automatic search using search string was performed to obtain studies from digital libraries. A total of 2072 search results were received, among which Google scholar returned 425 studies, IEEE Xplore 507, Scopus 185, Science Direct 678, ACM 172, and Springer Link 105 results.
Out of 2072 studies, 1391 studies were discarded at stage 2. At this stage, the exclusion of unrelated studies was performed based on title, abstract, publication venue, and keywords analysis. If there was a doubt about any study, including or excluding, it was added for later consideration. After this stage, 681 studies remained, which were downloaded and organized.
Selected studies from the last stage were revised by reading the introduction, conclusion, and discarded book chapters, newsletters, dissertations, short papers with a length of fewer than three pages, and symposiums. This stage excluded 179 studies leaving 502 studies in the selection.
Three hundred forty-nine studies were discarded in the last stage by applying detailed inclusion-exclusion criteria and reading the full text. Afterward, 158 studies were obtained in the selection, which was then subjected to quality assessment. Five studies having low-quality scores were discarded, leaving 153 primary studies.

E. DATA EXTRACTION AND SYNTHESIS
We included just journal articles and conference papers in this study. The selected primary studies were categorized into quantitative evaluation or validation, qualitative evaluation or validation, solution proposal, and experience or opinion study. A data extraction form shown in Table 5 was used to record details about the study overview and to answer the research questions. To extract information presented in Table  5 a detailed analysis of all the 153 selected primary studies has been conducted. A spreadsheet editor (Microsoft Excel) was used to record all the extracted data.
Data extraction involved all of the authors of the present article. One of the authors extracted the data, and others reviewed it based on convenience. There were disagreements related to some studies, which were resolved by discussion.
According to a study Data synthesis involves collating and summarizing the results of the included primary studies [30]. During the data synthesis, we extracted and normalized the terms used to refer to iteration, its source, the stage at which it occurs, and its consequences during software development. We built a comprehensive taxonomy of iteration based on its cause and stage of occurrence.

F. QUALITY ASSESSMENT
Quality assessment (QA) is critical in SLR [30]. The selected studies were evaluated against a set of 30 quality criteria given in Table 6.
To assess the quality of primary studies, we categorized the 153 studies into four categories. The four categories are Quantitative evaluation/validation (Qnt), Qualitative evaluation/validation (Qlt), Solution (Sol), and Experience/opinion (Exp/Op) studies. Each study was assessed against different quality criteria based on the category it belongs to. We used 16 quality assessment questions for Qlt papers, 19 for Qnt, 9 for Sol, and 6 for Exp/Op studies as presented in Table 6 and proposed by previous studies [30,35,36,37,38,39].
Each question is graded on the scale of three optional answers: yes=1, no=0, or partial=0.5. Thus, a quality score for a study is calculated by adding the scores of all the answers to quality criteria questions. The quality assessment scores for all the primary studies are presented in Table 12.

III. STATISTICAL FINDINGS
This section presents and summarizes this systematic review. In total, we selected the 153 primary studies, and we extracted data from these studies using Table 5. In the following subsections, we start by presenting quality assessment results and an overview of selected primary studies. The answers to each research question are described in the later sections.

A. QUALITY ASSESSMENT RESULTS
The selected studies fall into four categories, i.e., qualitative, quantitative, solution proposal, and experience/opinion. Different types of studies cannot be assessed according to the same criteria [30,35]. So, we formulated different assessment questions for each study type by following guidelines of [35,36,38,39]. Table 12 presents the quality assessment score for all the selected primary studies based on the quality assessment checklist given in Table 6. The average overall quality of the selected primary studies is 80.56, which is quite reasonable.

B. STUDIES OVERVIEW
Our SLR included the studies published from 2007 to Feb 2017. Temporal and geographical view of the selected primary studies are shown in Figure 3 and 4 respectively. We grouped the selected primary studies into four categories demarcated by [35]. Table 7 describes the research types of selected studies.
The majority of the studies are in the solution category with 83 studies (54.25%) followed by the quantitative evaluation/validation category with 53 studies (34.64%), qualitative evaluation/validation category with 34 studies (22.22%), and 12 studies (7.84%) in experience/opinion category.

IV. SOURCES OF ITERATION
This question aims to find the reasons that lead towards iteration during software development. We answer this research question by reading 153 studies returned by our SLR, given in Table 12. Sources of iteration gained from literature are summarized in Table 8 and explained in the following paragraphs.
The authors are not explicitly mentioning the causes of iteration in these primary studies. From a detailed analysis of these articles, we extracted different sources for the iteration. Due to many extracted causes, we grouped those into 22 leading causes. The most cited causes are conflicts, defects, and code smells, whereas the least referenced causes are poor management and different development methods followed by teams. Conflicts, referenced in 21 studies (13.56%), 28(18.06 %) studies cited errors/defects/faults cause for the iteration, code and design smell referenced by 23 studies (14.08 %), while 1 study (0.65%) cited poor management and 2 studies (1.29%) cited different methods followed by different teams cause.

A. CONCEPTUAL GAPS AND AMBIGUITIES
During software development, conceptual gaps and ambiguities become a reason to iterate. It includes vague and unclear requirements, imprecise and incomplete information, large and poorly defined features, missing the detailed requirement, ambiguity, and assumptions. Due to any one of    holders, mismatching goals, different levels of understanding of team members, uncertain and contradictory goals, and multiple quality objectives. Whenever there is any conflict during development, iteration occurs to resolve that conflict and get a mutual agreement. VOLUME 4, 2016 5 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication.

C. UNCERTAIN DECISIONS
Uncertainty and inconsistency in early decisions lead to bad decisions, e.g., taking poor or incorrect architecture structure as a blueprint, reassessments, and recalculating schedules. During software development, an uncertain and lousy decision is a source to perform a task again.

D. ERRORS,FAULTS, DEFECTS
Iteration occurs during software engineering processes due to unexpected errors, faults, misunderstandings, developers' mistakes, unclear specifications, problems discovered in the later phases, errors, defects. Cognitive bias leads to reasoning errors and becomes a cause of iteration. Defects in the requirement lead to incomplete, inconsistent, inadequate, and ambiguous requirements, which become a source of iteration.

E. COSMETIC CHANGES AND ENHANCEMENTS
When software development products are of aesthetic appeal or assessment criteria are subjective, there are lots of cosmetic changes that occur during development. These cosmetic changes, e.g., format, alignment, comment, are a source of iteration-code changes due to removal, refactoring, or extension of code cause iteration during software development. Enhancement to add a new feature, accommodate changes, and enhance existing features is also a reason to iterate.

F. POOR MANAGEMENT
Insufficient planning, continuous changes in requirements, configuration problems, defects, and critical stakeholders being overlooked are consequences of poor management, leading to performing work again.

G. LIMITED RESOURCES, UNKNOWN RISKS, SCOPE ADJUSTMENTS
Scope adjustments to meet schedule, multiple people involved in a decision and limited budget, different priority levels, unknown and risky conditions, unfordable and infeasible requirements, unforeseen events, and limited resources occur during software development and are the reason for iteration.

H. BUGS
Iteration in the software development lifecycle can be due to bugs that occur due to miscommunication, programming errors, and continuous changes.

I. CODE AND DESIGN SMELLS
Whenever there are bad smells in code or design, it becomes rigid and challenging to modify. Iteration occurs to remove bad smells and enhance the code and design flexibility. Code erosion, duplicated code, lazy-large, complex, unwieldy, and less cohesive-classes, coding style violation, design anomalies, and flaws, evolving code, non-compliance to design principles, extreme metric values, antiquated code, unstructured code, clones, rigidity and immobility in design, weak attributes in coding, and deteriorated code are all the different forms or reasons of bad smells which are the source of iteration during development and maintenance. Time pressure leads to a higher workload which also becomes a reason to introduce bad smells by developers.

J. TECHNICAL DEBT
During development, it is the situation when there is a need to take a shortcut. An advantage of technical debt is that it accelerates development but has to repay it later in the development lifecycle. Technical debt due to lack of trace structure, unimplemented features, outdated documentation, poorly organized logic creates iteration. Deferred technical debt during development creates much rework.

K. USER FEEDBACK
Maintenance requests, feedback discussions, late customer feedback, lack of user involvement, documentation unavailability, user feedback on prototypes, and usability evaluation of user interface are different causes of iteration in software development.

N. INACCURATE ASSUMPTIONS BASED IMPLEMENTATION
Iteration during software development can be partial implementation, incorrect implementation, inaccurate assumptions, ignorance, not exploring all possible solution options, and development order violations.

O. REQUIREMENT EVOLVEMENT
Requirements evolve during development which in turn leads to performing a work again. There are many reasons for requirement evolvement; some of those are changes in the environment in which software is situated, external changes by the company context, stakeholders cannot envision at the start, clients change their minds later, and deeper exploration of technology.

P. ABSTRACTION
Whenever there is a lack of clarity or detailed initial design, it needs to transform from abstract to concrete specification, which requires the iteration of the initial one.

Q. ENORMOUS DESIGN SPACE
When there is the involvement of multiple factors in selecting variants against a set of objectives, then, to avoid local optimization and select the best option, evolve the initial ideas that require iteration.

R. VIOLATION OF STANDARDS
Lack of standards and guidelines, violation of heuristics, and lousy programming techniques are some of the causes of performing work again during a software development project.

S. CORRECTIVE AND NON-CORRECTIVE CHANGES
Change can be corrective due to defects, perfective due to enhancement or expansion, adaptive due to modification, and preventive due to malfunctions. Requirement change due to error, modifications of original requirements, change of operational purpose, or support user request leads to requirement instability, volatility, and creep, which generates rework. Some iteration occurs to implement any changescorrective, non-corrective, or adaptive. When changes occur in a non-negotiable scope, it requires many adjustments.

T. DIFFERENT DEVELOPMENT METHODS FOLLOWED IN TEAMS
Unaligned agendas of different stakeholders and different methods followed by the teams, e.g., front end team follow agile and back end team follow plan-driven methodologies, lead to the iteration during software development.

U. COMPLEXITY
Wicked (underspecified and open-ended) problems, highly complex code, and volatile environment are reasons to perform a task again, develop a prototype to explore requirements, and refine initial ideas.

V. POOR UNDERSTANDING
Language differences, miscommunication, time zone differences lead to ambiguity in requirements and misunderstanding of design intent. The poor understanding causes much rework during software development.

V. STAGES AT WHICH ITERATIONS OCCUR
Iteration occurs during the whole software development lifecycle in different forms and at each stage has different impacts. Iteration occurs during requirement engineering to get a clear understanding and mutual agreements. Iteration invents an innovative and straightforward, less complex solution in the design phase, and making changes is easier later. When products have aesthetic appeal, iteration occurs during user interface design for quality enhancement of initial one and perfection. During implementation and maintenance, Stages at which iteration can occur during software development lifecycle from the extracted data against selected primary studies that cite these stages are summarized in Table  9.

VI. IMPACTS OF ITERATION
In software engineering, iteration has both positive and negative consequences. Impacts of iteration extracted from selected primary studies are summarized in Table 10 and explained in the following paragraphs.

A. ITERATION POSITIVELY IMPACT ON QUALITY
Enhancement of quality by iteration is referenced by 21 studies, whereas three studies write negative about iteration impacts on quality, as given in Table 10. Selected viewpoints of different authors about iteration impacts on quality are: refactoring improves code and software quality [31,49], negotiation during requirement engineering improves requirements quality [114], refactoring improves quality by removing code smells [3], iteration enhances the various characteristics of the software quality [51,163], iteration results in improving internal quality of the system while preserving its functionality [101]. In system evolvement, refactoring is performed to improve the code quality, but the analysis shows that some refactoring techniques improve whereas others depreciate the quality [120]. Iteration caused by wild requirements changes may damage the quality of the software [47].

B. ITERATION ENHANCES UNDERSTANDABILITY
The literature highlighted that iteration increases conceptual clarity and understandability. The positive impacts of iteration on understandability and clarity are cited by 17 studies, whereas none of the studies discuss its negative impacts on understanding. Iteration progressively refines the genuinely dubious objectives into precise requirements. Iteration enhances program understanding [126], helps the stakeholders to understand the requirements before they sign off [52], code gets simpler and easier to understandable after iteration [17].

C. ITERATION INCREASES PRODUCTIVITY
According to [42] and [59], iteration during development has a positive impact on productivity.

D. ITERATION MAKES MAINTENANCE EASIER
Iterations make the software easy to maintain and modify from the product and process perspective, i.e., make it scalable. Iteration enhances extensibility, makes it simpler to include new elements, and enhances maintainability. Fifteen studies cite the positive impact of iteration on maintenance, but none referenced its adverse impacts on maintainability.
Iteration progressively refines the genuinely dubious objectives into clear requirements. [6] write that code clones are the one reason that makes maintenance difficult. Refactoring can remove code clones and enhance flexibility, although it may not always be a good option. Iteration makes the software adaptable, and adding new functions becomes less demanding [126].

E. COMPLEXITY REDUCES AS A RESULT OF ITERATION
Thirteen studies cite the positive impact of iteration on complexity, as shown in Table 10. None of the selected studies referenced the negative impacts of iteration on complexity. Studies have highlighted that iteration lessens the multifaceted nature of code, design, and general framework; furthermore, it diminishes the size of the code and reduces the complexity [58,74,140,164,166].

F. ITERATION HELPS IN MAKING CORRECT DECISIONS
Iteration leads to the right decisions by removing ambiguities and making realistic estimations [9]. None of the studies cited the negative impact of iteration on decision making, whereas 8 studies referenced better decision making as a result of iteration. It results in the selection of the best among multiple options for the defined criteria [102]. When conflicts of interest exist among multiple stakeholders' goals, iteration helps in making trade-offs and building consensus [12].

G. ITERATION LEADS TO INNOVATIVE PRODUCTS
Creativity is thinking of new thoughts, and innovation puts those thoughts into a practical project. It can be new thoughts on the best way to build up a superior product, a better design, or better processes for development. Iterations lead towards innovation, creativity, and secure upper hands through feature separation [146].

H. ITERATION HELPS IN REMOVING DEFECTS
Increment in the defects by iteration is referenced by 6 studies, while 14 studies write that iteration results in removing defects, as can see in Table 10. Iteration removes ambiguities and results in complete and less ambiguous requirements [10]. Iteration fixes bad design practices [74]. Sometimes, while repairing defects, iteration results in the introduction of new defects [3].

I. ITERATION INCREASES COST, WHILE, IT IS COST EFFECTIVE IN LONG RUN
From selected primary studies, 8 studies highlighted that iteration increases the cost of the development, while 10 studies cited that iterations are cost-effective in the long run. Iteration during software development lessens maintenance costs by improving internal structure [101]. Refactoring reduces the cost of making changes to the system [58].  [14] write that iteration caused by poor management results in project delays. Code refactoring leads to rapid development [46]. According to [59], iteration results in reducing the time and cost of the project.

K. EFFORT
Iteration impacts negatively on the effort required to develop a software, as shown in Table 10, 5 studies cited that whenever there is an iteration effort required to complete a project increases, but, 2 studies also referenced a decline in the overall effort. Rework increases cost for customers and effort by developers [150]. According to another study, refactoring results in achieving the best outcome with the least effort [165].

VII. TAXONOMY OF ITERATION
The taxonomy classifies different iterative situations based on the source and timings of the development cycle at which it occurs. Iteration has different perspectives during software development because different iterative situations may originate from diverse sources, at different timings, and have impacts. So to handle different perspectives, different ways can be used. Four distinctive iterative perspectives are identified: Rework; Refinement; Exploration; Negotiation. Different perspectives of iteration defined based on source, stage, and impacts are described in the following subsections, and the taxonomy of iteration is presented in Figure 5.

A. REFINEMENT
Refinement is the enhancement of initial specification. It has subtypes in terms of its impacts. One of those is refactoring, which has minimal impact. This type of refinement is done when sufficient time is available or where products have aesthetic appeal or assessment criteria is subjective. It portrays a situation in which essential requirements have been satisfied and experience further iterations to upgrade optional qualities, such as enhancing style or diminishing cost. In general, refinement is the process of removing impurities and improving something by making small changes, e.g., refactoring. Refactoring is the way to change a software system not to modify the code's outer behavior but to enhance its interior structure.

B. REWORK
Rework is one of the iteration's perspectives that seem most regularly in literature. It is reattempting a work in the same manner as before due to changed information or suppositions. Rework requires the reiteration of an assignment since it has initially endeavored with incorrect data and suppositions. An example of rework in software development is a change in requirements, or simply requirements misunderstood. Rework may be produced because a procedure is unpredictable, so it is impossible to recognize the most productive order of work execution beforehand. It may be because of issues that appeared during analysis or requirement changes. If the timing constraints require starting it with incomplete information, it is impossible to eliminate rework because of changed input information later. Rework is adverse because of the increase in time and cost without any increase in 10 VOLUME 4, 2016 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication. software performance and quality.

C. EXPLORATION
Dynamics of exploration involve an iterative process of seeing different alternatives, assessing those solutions, and selecting the optimal one. It incorporates the investigation of new thoughts to tackle an emerging issue and iterative convergence to a solution.

D. NEGOTIATION
Negotiation is an iteration perspective that describes the circumstance in which the trade-off between various members' objectives and constraints is made by understanding and negotiating their conflicting goals. Negotiation is utilized to consolidate the commitment from various members who have little information about each-other's work, and they regularly have clashing targets. When too many conflicting parameters are involved, negotiation turns out to be excessively troublesome.
The taxonomy shown in Figure 5 presents four different perspectives of iteration that consistently exist in the software engineering literature. The objective is a detailed analysis of iteration, and the taxonomy will explain different terminologies used for iteration with its contextual description to researchers and managers. It will also help in making the comparison between different iterative situations.
To validate the taxonomy, four studies ( [14,15,32,116]) were selected to completely map and describe the different iterative perspectives to the taxonomy. First, we describe in detail how the studies can be mapped to taxonomy by selecting four studies then present a summary of all selected primary studies of the SLR. All four studies contain specific iterative situations mapped to the taxonomy. This mapping is summarized in Figure 6 and explained in the following paragraphs. For each paper, the paths from taxonomy, its classification, and its context are explained. In many primary studies, the iterative striations are deduced from the text, and it involves a detailed analysis of each study to extract the related evidence.
In the first study, the authors talk about an iterative situation that occurs during the architectural design for selecting an optimal option among the multiple variants, the analysis, synthesis, and evaluation cycle continue for choosing the best options in the given circumstances [15]. This study maps on exploration (iteration) in the design phase of software development due to the enormous design space.
In the second study, authors code an iterative scenario that arises during actual development time due to taking shortcuts for short-term benefit; repayment occurs in the long run in the different form of refactoring and code improvements [32]. This study maps on refinement (iteration) in the implementation phase due to the technical debt.
Two different scenarios of iteration are extracted from the textual description of the third study [116]. The first iterative situation is due to the limited budget and multiple people involved in the requirement elicitation that leads to the negotiation. In the second scenario, the product backlog is updated due to the feedback on prototypes from the customers in the requirement eliciting stage. This study maps on both refinement and negotiation.
In the fourth selected study for the validation, authors illustrate the rework perspective of the taxonomy, and multiple causes of it are discussed [14]. Overall, this study describes three paths from the taxonomy shown in Figure 6. The multiple causes extracted from the study are: critical stakeholders overlooked unaligned agendas, insufficient planning, continuous changes, defects that cause the rework throughout the whole software development lifecycle.
Further, we have revised the same 153 studies selected initially from the SLR search process to validate the taxonomy. We then extracted the iterative perspectives that exist in the study according to the taxonomy and summarized the paths from each study in Table 11. We followed the same data extraction, and mapping process explained in Figure 6. The number of studies verifying each iterative perspective against the stage of the development life cycle is shown in 7. Out of 152 studies, 41 studies were mapped on multiple perspectives of iteration, 10 studies on exploration, 59 studies on refinement, 28 studies on rework, and 13 studies mapped on negotiation. Note that it is also possible that a study can be mapped to multiple iterative perspectives if it contains several iteration scenarios that exist in software development projects. For example, both rework and refinement are mentioned in a study as given in Table 11 [125].

VIII. VALIDITY THREATS & EVALUATION
We used internal, external, construct, and conclusion validity threats classification adapted from the work of [178].

A. INTERNAL VALIDITY THREATS
According to [178], internal threats are related to the wrong conclusion drawn about the causal relationship. This type of threat can occur due to personal bias on study understanding. We tried to minimize internal threats by mitigating personal biases. We performed the selection process iteratively by multiple authors to remove personal biasness. Another threat to internal validity can be erroneous data extraction as the number of primary studies is significant, and data extraction involves subjectivity. Data extraction was harrowing because many studies did not explicitly mention sources, stages, and impacts of iteration, and an interpretation of data was required, which involves personal biasness. This threat was minimized by performing data extraction by multiple researchers.

B. EXTERNAL VALIDITY THREATS
The external validity of the literature review depends on the selected primary studies. The selected studies should be valid and representative of the review topic in the external evaluation. We applied inclusion, exclusion, and quality assessment criteria to minimize this type of threats to select good This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication. literature. To mitigate external validity threats, we defined the search process iteratively by performing some trials and getting agreement from all authors. The threat can be due to assessing all the studies by a single researcher for inclusion and exclusion decisions. The inclusion/exclusion decisions were discussed with the advisor, and a test-retest approach was applied, as recommended by the [30] to mitigate this threat. To check reliability of the decisions, reevaluations of inclusion and exclusion were performed for randomly selected studies.

C. CONSTRUCT VALIDITY THREATS
Construct-related threats are about generalizing the results [178]. We used search strings with different synonyms and six different databases to search related studies to minimize this type of threat. In synthesis, we extracted the common concepts described using different terms and normalized the terms used. Additionally, we created a lucid taxonomy based on these concepts. In the development of research questions, we have not completely followed the PICOC guidelines proposed by [30].

D. CONCLUSION VALIDITY THREATS
We cannot identify all the primary studies that exist related to research questions [30]. We used multiple synonyms for the keywords to cover maximum studies and minimize this threat while designing search string. To mitigate conclusion validity threats, the whole process was developed carefully and verified.
12 VOLUME 4, 2016 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication.

IX. CONCLUSIONS
The investigation into the iteration suggests that additional care is necessary for dealing with iteration during software development. In software engineering literature, different authors use different terms to refer to iteration at different places. Additionally, many different sources contribute to iteration at different phases of the development cycle and impact the project in different ways. In this context, the management of iteration becomes a troublesome task. Therefore, to resolve the issues related to iteration, we created the taxonomy of iteration. So, the main objective of this article was to combine the existing knowledge about the different iterative situations and enhance understanding of these situations that consistently exist in software engineering. Different characteristics of each iterative situation were analyzed, such as sources/causes that lead to that situation, stages of the development process at which it can occur, and its impacts on the development project, positive and negative.
Our SLR is based on 153 primary studies, selected out of 2072, through four stages. The review encompasses the whole software development lifecycle, i.e., the review is not restricted to a particular phase or domain. The broader scope of the review gives us deeper insights into iteration during the whole software development lifecycle. We have verified the created taxonomy using selected primary studies. The significant findings from this review and suggestions for further research are given in the following subsection. VOLUME 4, 2016 13 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and   [10,11,17,48,85,94,111,114,116,152,164,172,176]

A. PRINCIPLE FINDINGS
In answer to RQ1.1, we have found from the literature that there are lots of multiple causes/ sources that yield iteration in software engineering projects. It is also noted that different terms are being used in literature for the same cause/ source concept. Due to many extracted causes, we synthesized those into twenty-two leading causes. The most cited causes are defects, code smells, and conflicts, whereas the least referenced causes are poor management and different development methods followed by teams.
When responding to RQ1.2, we observed that the iteration could occur at different phases in different forms during the whole software development lifecycle. The 22 studies cited iteration at requirement stage, 20 studies at design, 21 papers at implementation, 4 studies mention iteration at the testing phase, 27 studies talk about iteration at maintenance, while 13 articles mention the iteration during the whole software development lifecycle.
In response to RQ1.3, it is found that iteration has both positive and negative impacts on the development project.
The most cited positive consequences of iteration are quality improvement (21 studies), flexible and more accessible maintenance (28 studies), understandability enhancement (17 studies), complexity reduction (10 studies), and better decision making (8 studies). The negative impacts of iteration are increasing effort (5 studies), time (7 studies), and cost (8 studies).
Regarding RQ1.4, we observed that the different iterative situations were rarely defined in the literature. Moreover, different authors use their terms to refer to iteration at different places, which is misleading. Sometimes, an iterative situation is being denoted by different terminology and vice versa. This makes the management of iteration difficult and problematic for the practitioners, and it also makes problems for researchers trying to synthesize results from different research studies. A detailed analysis of different iterative situations does not exist to clarify differences among different iterative situations. On the way towards building the iteration taxonomy, we organized an SLR. Our investigation found that most synonyms are being used for iteration and its 14 VOLUME 4, 2016 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and sources. Without defining clear and coherent terminology, researchers will continue choosing different terms for iteration. Additionally, it makes synthesizing process for reviews more complex.
The terms used in our proposed taxonomy do not entirely demonstrate the current use of the terms. However, we built the taxonomy of the different iterative perspectives based on the development cycle's stage and the iteration's source. Understanding different iterative situations and their aftereffects play an essential role in the success of a software project. It increases the visibility into processes. Enhancing visibility into processes during development supports better management of the project.

B. AUDIENCE
Though the primary purpose of the taxonomy is the detailed analysis of iteration in software engineering to facilitate the understandability and enhance visibility into development processes. The target audience for our research contribution is both practitioners and researchers. We see inconsistent and different terms to refere iteration are a hurdle for understanding and managing iteration during software development processes. The taxonomy proposed in this article enhances the understanding of different perspectives on unplanned iteration and serves as a roadmap for practitioners and researchers in understanding different iterative situations.

Research
The contribution of this study is the taxonomy of iteration in software engineering. It also demonstrates how taxonomy can be based on literature and map present studies. This taxonomy of iteration is a step toward further research on iteration in software engineering. If the terms are not clear and consistent, the search process, developing search strings, and directing literature reviews are challenging. The taxonomy can also be used to synthesize existing knowledge, find the gaps, and further analyze. The method used for developing the taxonomy can also be used in other research areas. It is also possible to investigate the relationship among different iteration perspectives. It is also likely to conduct an expert survey to validate the terminologies, causes, impacts, and taxonomy.

Practice
As a number of diverse scenarios for iterative situations are possible, it is reasonable to accept that an iterative situation that emerges from the requirement phase is different from that which emerges from another phase. It is also sound to understand that different causes at different stages lead to different iterative situations, and each of these scenarios cannot be managed in the same way. Thus, the context plays an essential role in managing iterative situations. The mapping of the studies to the taxonomy suggests that it is often challenging to understand the context of the iteration described in the software engineering literature. For better management support, an implication of the taxonomy of VOLUME 4, 2016 15 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication. iteration in software engineering is that it is possible to extract the paths and incorporate them in planning and management tools. Contextual information about the different iterative scenarios can be extracted from taxonomy which can further be used in simulating the particular situation for better decision making.

APPENDIX:QA RESULTS
Quality assessment results of the selected studies are shown in the Table 12.