Modeling Iteration’s perspectives in Software Engineering

Iteration is ubiquitous during software development and particularly notable in complex system development. It has both positive and negative effects; the positives of iteration include improving quality and understandability, reducing complexity and maintenance, leading to innovation, and being cost-effective in the long run; Negatives of iteration include; time, cost, and effort overrun. Its management is a challenging task and becomes more complex due to the non-uniformity of the terminology used at various places. Although Software Development Life Cycles (SDLC) are highly iterative, not much work related to them has been reported in the literature. Insights into iteration are explained in this paper by defining different perspectives (Exploration, Refinement, Rework, and Negotiation) on iteration through literature review, modeling each perspective, and simulating the effect of each iterative perspective on project completion time. An attempt has been made to create awareness about efficient use of iteration during software development by informing which perspective of iteration has what kind of impact on project completion time to avoid delays.


I. INTRODUCTION
Software development processes do not move in a straightforward, linear fashion. Deviation from linear movement is widespread and is depicted as iteration [1]. Iteration is performing a task again once it has been done. It is considered unavoidable and particularly notable in the life cycle of complex systems. Iteration can be categorized as planned and unplanned iteration. Planned iterations occur in iterative software development, particularly agile software development [2]. In comparison to planned iteration, unplanned iteration is costly and may affect a project's outcome. There are numerous causes of unplanned iteration in software development processes, including volatile nature of software scope [1,3]; inconsistency revealed at some later stage [1]; changing business rules, client criticism on prototypes [2,4]; mistakes uncovered by testing [5,6]; complexity, ambiguity or unclear requirements [7].
Iteration is well studied in product development [8,9,10,11], construction [12], design [13,14,15,16,17,18,19], and engineering disciplines [13,16,19,20], whereas very few authors discuss them from software development viewpoint. A study gathered and summarised insights into iteration from the design and development discipline. Additionally authors create the taxonomy of iteration that clarifies differences between different perspectives on iteration. They have selected a few articles from software engineering literature as well [17].
Iteration is hard to oversee and control. In the software industry, it is usually connected with time, cost, and effort overwhelms [4,5,21]. Early iteration on the investigation of thought lessens the recurrence of requirement changes later in the development and reduces completion time because there will be less modification on later phases of development cycle [22]. It expands the amount and quality of the end product and, in addition, diminishes the data sources required to create it [23]. Iteration leads towards innovation [24]. It increases the development process's complexity and moves from linear towards dynamic. It also restricts the multifaceted nature and positively affects the understandability and conceptual clarity [25]. One can use it as a tool to refine unclear goals into clear objectives [7]. Iteration makes the design adaptable, i.e. it boosts the perseverance of the design in future force changes as far as time and cost as well [26]. Empirical studies highlight that it also reduces the complexity and size of the code. For instance, iteration reduces code complexity, makes reverse engineering simple, and enhances the software design [27]. It has beneficial outcomes, including investigating ideas, finding and remedying blemishes, removing inconsistencies, and permitting development under unpredictability and change.
Although, iteration is unavoidable during software development [1,6,28,29,30,31,32], detailed analysis of unplanned iteration does not exist. Despite the iterative nature of SDLC, little attention has been paid to it. Most of the authors have used varied terms to refer to iteration at different places. Management of iteration is a challenging task, and it becomes more complex due to the use of different terms to define iteration at different places. To resolve issues related to iteration, there is a need for uniform terminologies. In software engineering literature, no such study exists that considers the issues surrounding unplanned iteration in software development processes. The authors of the present article gather insights into iteration to clarify the differences between different perspectives on iteration and find the impact of each perspective on project completion time. This article contributes in two ways; first, by defining different perspectives on iteration -based on source and stage of the SDLC in which it occurs-to clarify the distinctive viewpoints of iteration that consistently exist in the software engineering discipline; second, by modeling the impact of each perspective on project completion time.
A comprehensive analysis of different viewpoints of iteration in software engineering processes has been created through literature review. From an in-depth analysis of all relevant publications, it has been found that iteration positively influences quality, understandability, productivity, and conceptual clarity. The software, which is developed iteratively, provide flexibility and reduce maintenance. It reduces the complexity and code size, removes inconsistencies, fixes defects, and leads towards innovation. Iteration increases time, effort, and cost for a short time, but it is cost-effective in the long run. Overall, non-functional requirements get easily satisfied by iteration. This article defines different perspectives on iteration which exist in the software engineering discipline. Next, the authors have modeled the impact of each iterative situation on project completion time by using and enhancing [33]. A project manager should know of all these to manage a project in a better way.
The rest of this paper is organized into four sections. Section II introduces different perspectives on iteration to distinguish between diverse iterative circumstances in software development processes and demonstrates that previously no such distinction existed. Section III models each iterative perspective. Section IV verifies iterative perspectives and models by comparing simulation runs with deterministic solutions. Section V summarizes key points and conclusion.

II. PERSPECTIVES ON ITERATION
Iteration has different perspectives because different iterative circumstances may have diverse sources and impacts. An iteration might be seen from a different point of view contingent on the concern.
A. 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. Every progression of iterative procedure comprises of either a straightforward, surely known expansion, design, or alteration in implementation inspired by a better understanding of an issue acquired through the process [34]. Exploration alludes to an iterative process that concocts straightforward solutions, so there is less to change and rolling out those improvements is less demanding and enhances quality [7]. Exploration refines the problem statement and creates an in-depth analysis of the problem [35]. Authors portray iteration as exploring diverse design options, predicting each discretionary design's quality and selecting the one that best fits into a particular context [36]. It is central in critical thinking and problem-solving processes. Exploration usually includes the iteration of requirement building and high-level design, however not of low-level configuration, execution and testing [37].
Literature highlights that exploring different design options in the early stage of design are beneficial (see Table  1). Longitudinal action research found that investigating different design choices is the synchronous analysis of the issue and its solutions. Particularly for software development, performing this investigation during early or architectural design is advantageous [31]. Exploring the design choices is essential during software development, and just a couple of strategies exist to help in performing this investigation systematically. In User-Centred Software Development (UCSD), iterative prototyping for the exploration of the different design choices is one of the significant activities [40].
In requirement gathering, explore the requirements to get a higher-level understanding. In design, exploration is for inventing the innovative and straightforward solution [7]. Many writers talk about exploration in early design phases as [36] code iteration as exploring diverse design options, predicting each discretionary design's quality and selecting the one that best fits into a particular context. Exploration usually comes in earlier phases of SDLC. It usually includes an iteration of requirement building and high-level design [37]. System risks, e.g. risks identified with deficient, conflicting and vague requirements, are all explored and managed through the requirements elicitation stage [38]. Exploration alludes to the procedure to make and/or check the initial system specification [41]. Open innovation should be embraced as a complementary approach to ease internal innovation. There are two types of innovation those typically software develop-This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.  Early exploration reduces the occurrence of later changes, also makes changes less demanding, thus it reduces both the rework and the effort required for it [7,22] Understandability Initial specification get clarified after exploration i.e., it gives better understanding of the problem [22,34,36] Satisfaction When ever there is an exploration in the early phases, the end product meets user needs and the user gets satisfied [22,36]

Quality
Exploring diverse design options improves the quality of design and end products [7,23]

Complexity
Exploration invents simple solutions those are less complex [36]

Risk Analysis
Risks related to incomplete, inconsistent and imprecise requirements get managed [38,39] Time if there is exploration then project completes timely because later stages development time decreases [37] ment firms adopt, i.e., exploration and exploitation to stand in a promptly changing technological environment [42]. Early exploration on the investigation of thought lessen the recurrence of requirement changes later in the development and reduce completion time because lesser modification will be required on later phases of the development cycle [22]. It invents simple arrangements which are less intricate [34]. At the point when there is an investigation of multiple ideas at early stages, then development proceeds with continuous improvement [43]. Exploration more often includes an iteration of requirements and high-level design, however not of later stages, so software development life cycle grows timely because later stages development time decreases [37] and customer satisfaction increases [36]. It refers to an iterative process that concocts simple solutions, and then changes become less complex [7].

B. REFINEMENT
Refinement enhances initial specification and has subtypes in terms of its impacts. One of those is refactoring that 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 where essential requirements have been satisfied and experience further iterations to upgrade optional qualities, e.g., enhance the style or diminish cost. In general, refinement is the process of removing impurities and improving something by making small changes, e.g., refactoring. Different viewpoints about the after-effects of refinement from the literature are summarized in Table 2 and discussed below.
A few researchers characterize refinement as beginning with the basic introductory implementation of a small part of the issue and iteratively upgrading existing version, e.g., after reviewing the prototype with users, developers refine and extend it, this process continues through several iterations [34]. In the same way, [37] additionally depict refinement in the software development lifecycle as the first iteration should produce a miniature version of the system, and each iteration then enhances that version. Extreme programming is an agile technique that stresses the continuous refactoring of codebase [44]. While developing embedded systems, we refine the basic description into another representation that mirrors the choices we have made within exploration [36]. During software development, unclear arrangement of objectives is progressively refined into requirements [45]. It is also implausible that an architectural design process does not involve cycles to upgrade the design [46]. Traditional process management drives the differences out of processes by nonstop estimation, identifying errors, and process refinements [7]. In the software development process, refinement also exists in removing code clones. They depict that numerous practices can be utilized to eliminate the clones from code [47]. Larger organizations have different practices than agile, e.g., change control board in larger organizations and refactoring and continuous improvement in agile [32].
In SDLC, the prototype should be designed first and then refined in the next iterations [48]. User interface design and agile concern iteration, change, and refinement [2]. Numerous authors discuss refinement in the analysis, design, and implementation stages. As before, requirement analysis requirements are accumulated with little detail, and afterwards, those are detailed up within iterations (refinement) in the analysis [49]. In design, refinement is designing with a straightforward introductory outline, incorporating it persistently, and refactoring the outline [25,50,51]. In implementation, refinement is refactoring of code and database [25,50,51,52]. According to [47], refinement (iteration) occur during implementation and maintenance stage.
Refactoring has both positive and negative aftereffects in terms of quality improvement. While coding, refactoring improves practicality, upgrades execution, diminishes code size, removes duplicate code, improves testability, improves extensibility and require less work to incorporate new components. It improves quality and reduces time to market [57]. Refinement helps work faster, either we measure direct or indirect, there is a positive influence of refactoring on software quality. Refactoring restricts the multifaceted nature, overall positively affects the understandability and conceptual clarity for application engineers and understudies [25,64]. It enhances extensibility, simpler to include new elements, i.e. reduce its complexity, simplify reverse engineering, and enhance the software design. If there are clones in the

Effects
Selected consequences with references Quality Refinement improves software quality [25,53] It improves the quality of legacy code by removing code smells [26,54] There is a difficulty of merging and integration after refactoring [66] system, they have to change everywhere, so maintenance effort increases. Because of the negative effect of clones, one can uproot code clones by dynamic refactoring (iterative refinement) [27]. However, some studies claim that all types of refactoring do not constantly improve quality; sometimes, refactoring degrades software quality as well [67,68,69,70]. Code refactoring could bring about an efficiency punishment in the short run if the coding style gets to be not the same as the style designers have become appended to [65]. It makes the configuration versatile, i.e. support the persistence of the outline in future power changes as far as time and cost [26]. Refinement leads towards the investigation of new ideas that reduce change costs by creating straightforward arrangements so that there is less to change, and rolling out those improvements is less complex [36]. The consequences of clones can be classified in both positive and negative ways. While seeing an optimistic viewpoint, clones diminish the development time by reusing code. There are no compelling reasons to compose the new code, so clones in the code enhance development efficiency [47].

C. 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 endeavoured 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 excessively unpredictable, so that it is impossible to recognize the most productive order of work execution beforehand. It may be be-cause of issues that appeared during analysis or requirement changes. If the timing constraints require starting a project 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 improved software performance and quality. After-effects of the rework gained from the literature are summarized in table 3.
Cycles often get to be compulsory when some irregularity is found. At the point when there is irregularity, then need to revise to eliminate the issues [1]. If the operational outline is not correct, it will be perceived at a prior stage, and iterations with requirements and design can be revamped [81]. Change can be due to many reasons, software testing sometimes detects errors in programming, while clients can change the requirement, and usability testing can bring about change even without mistakes or changes in requirements [2]. Requirements instability alludes to evolution or fluctuations in requirements throughout the SDLC, and it causes rework [3]. Many cycles in the refinement procedure are because of prerequisites just misjudged and/or misconstrued [82]. The additional limit for change makes projects vulnerable to prerequisites change, or requirement creep [83]. To decide software cost and schedule, the measure of revamping and how it is dealt with are essential components [84]. When estimating the cost of a project, it is hard to reflect numerous cost variables which influence the product cost, e.g., requirement changes [21].
Numerous activities in software development involve significant changes in the requirements, scope, and technology used. These changes are outside the development control and regularly happen inside a development life cycle [7]. Most design cycles result from issues identified as late as  Negotiation makes trade-off between diverse stakeholders concerns and needs [77] /Conflicts Negotiations resolves clashes and get agreements among the multiple stakeholders requirements [78,79] Negotiation unites all the stakeholders on a satisfactory set of requirements by making a common vision among partners and develops requirement definition for projects [80] Rework Negotiation picks right set of the requirements. By picking right requirements the client gets satisfied By negotiation, vague and unclear requirements get clear. It avoids costly rework or changes [79] equipment or framework reconciliation time. At this point, when coordinated into a framework, these either do not perform the required functionality or execute the wrong functions [41]. There is a tremendous amount of change in a project regarding new and changed classes during its life cycle [85]. Change of requirements happens throughout a project. Function Points can be redesigned each time the use cases change so that they can determine the effect of a particular use case in the estimate of the complete project development [71].
There are some situations in the software development life cycle when a team turns the effort in a new direction due to a customer's change demand or the changing market. Then need to change the already developed portion to incorporate the changes [29]. Large organizations have resistance to change, and agile development welcomes the change. During software development, companies face the problem of rework and deferrals [44]. Unpredictable changes occur during development, and one must respond to those changes [86]. Small organizations find it challenging to manage time in light of changing customer requests [87]. Factors that contribute to rework are lack of expertise, lack of documentation, lack of communication, changes in requirements, lack of user involvement, and lack of adequate testing [88]. "Rugby" is an agile process model, and it permits response to change requirements [48]. Software engineers distinguish between artefacts that have more defects and, according to the defect density, take decisions related to rework [89]. Rework is the work implemented again because it was not appropriately accomplished for the first time. Short, medium and long term projects meet the different amount of rework. It exists in all phases of SDLC but the maximum amount in the requirement gathering phase. The greater part of the outcomes of rework is negative, yet there are some positive angles as well, e.g., it enhances the understanding of developers [73]. Early rework is also less costly, and it removes inconsistencies during design and in specifications [75]. Rework identifies developers' mistakes, improves understanding of developers, and fix defects. It also diminishes maintenance [74]. Negative effects of rework are more obvious e.g., increases cost [21], increases effort [71], much time will be used in fixing code [5], increases overall development cycle [4]. Rework is the main reason for schedule delays, budget overrun, and risks even after delivery [88].

D. NEGOTIATION
Negotiation is an iteration perspective that describes the circumstance in which the trade-off is made between various members' objectives and constraints 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 project comprises a dynamic chain of contracts, and iteration is moved by backtracking up to the hierarchy for decision making about what moves to make and growing another sub-chain of agreements to execute the decision [1]. Building a system that operates nicely with individuals of various backgrounds, in diverse places, and at different times is a significant challenge. There must be a requirements negotiation process that addresses the stakeholder heterogeneity. The selective consequences of negotiation gained from the literature are presented in table 4 and discussed below.
Rather than rigorous requirements in contracts, now organizations require stakeholders with a shared vision and flexibility to rapidly renegotiate another solution once unanticipated issues or opportunities emerge [80]. Risk management comprises negotiation, and risks are overseen throughout the VOLUME 4, 2016 development life cycle. Risk analysis is a business-level decision support tool [38,39]. It is essential to adjust the levels of simultaneousness and cycle appropriately to streamline the execution. The decision about when to release software is a business decision, and there is minimal information available regarding the business decisions in any software literature [84].
Requirement engineering involves a collaborative, interactive, and interdisciplinary negotiation process that includes diverse partners/ stakeholders. These stakeholders take part in a negotiation process so they can unite on a commonly satisfactory set of requirements [80]. To consolidate another change, one must first choose whether it should accept it or not and then decide to add this change in the previous or create another module. Negotiation occurs while doing risk analysis too [38,39]. Negotiation makes a shared vision among partners and develops project requirements definition. It also participates in COTS (commercial off-the-shelf) development for obtaining and integrating, transition planning, COTS enhancement, and release planning. We should perform prototyping in advance of and throughout requirements negotiations [80]. Distributed software development may expand process duration, and there can be numerous possible reasons for this delay. The most common delay was resolving the work issues, e.g., if a chunk of the design or code needs to be altered or needs a sound understanding of the product. To resolve this kind of problem, the individuals at more than one site should be included in information exchange and negotiation [76]. Negotiation can also take part in the selection of tools that will be utilized in the project development [114]. While discovering an optimal solution to an issue in search-based software engineering, there is a need to trade-off between diverse stockholders' concerns and needs. The solution is assessed on various distinctive subjective criteria [77].
Prune the product tree (online game) is being utilized for eliciting requirements and buying a feature (online game) for prioritization and negotiation to manage communication and knowledge transfer issues during the requirement engineering in [79]. The fundamental objective of negotiation is to resolve clashes and agree between partners about the most critical requirements. Sometimes, the restricted budget accelerates the requirements negotiation to settle on each requirement's choices and needs. Stakeholders consult to set the priorities and update the requirement list according to the priority. Prototypes get refined based on the client's criticism. By picking the right set of requirements, the client may get satisfied. As a consequence of negotiation, the vague and unclear requirements get more precise, avoiding costly changes. During software development, there is a negotiation between customers and stakeholders. Working software and user involvement is more critical than lengthy documentation and contract negotiation [48]. We have verified the defined perspectives by mapping each publication against the iterative perspectives as shown in table 5.

III. MATHEMATICAL MODELING
This paper modified Braha and Bar-Yam's model [33] by incorporating the effects of exploration, refinement, rework, and negotiation perspectives on the iteration as discussed in the preceding section. Analysis in [33] is based on the overall density of the incomplete tasks α. Hence their model does not require investigation of the individual tasks separately. However, we develop our model for the individual tasks as the different kinds of iteration will occur in different tasks; hence, their effects will not be present uniformly in all tasks. We can then look at the overall density of the incomplete tasks to establish a comparison with the results of [33]. As a test example, we use a directed random graph which contains 10 5 tasks with connectivity < k in >=< k out >= 12 and assuming all tasks to be incomplete at the start. Initially the internal completion rate r = 0.75 and sensitivity value β = 0.061 for all the tasks.
In our model, a network of nodes represents the software development, and an individual node represents a particular task during the development life cycle. During the software development life cycle, the state of a task can either be "complete" or "incomplete". The state of each task is influenced by its incoming tasks, and it also influences the outgoing tasks. The state of a task changes from being complete to incomplete or vice-versa by some stochastic rules. If a task's state is complete and has more incoming edges, its probability of getting incomplete will be higher. If a task is incomplete, its state may become complete in the next instance, depending on its internal completion rate and incoming incomplete tasks.
Let s i (t) represent the state of the task i at time t, then in our model a task can be either complete (i.e.s i (t) = 1) or incomplete (i.e.s i (t) = 0). Let k in i be the number of incoming edges to the task i, then k i (t) = k in i − j:(j,i)∈E s j (t) represents the number of incomplete tasks connected to the task i at time t. Following [33], the state of a task changes according to the stochastic rules given in (1), (6), (16), (20), (24), and (25). Corresponding to the case of task i being complete at time t and task i being incomplete at time t, the state of task changes according to (1) and (25) respectively.
In the above equations, β i represents the coupling of task i to its neighboring incomplete tasks, r i represents the internal completion rate of that task, and tanh(x) represents the hyperbolic tangent function defined as We are updating the internal completion rate r, whereas the coupling between tasks β, also get updated. In particular, β i = 0 corresponds to the case where all the tasks are independent, low β i value represents that tasks are not much affected by its neighboring incomplete tasks and β i → ∞  34,36,89,110,111,112,113] means that all the tasks are completely dependent on its neighbors.

A. ANALYTICAL RESULTS
Adhering to the nomenclature of [33], we define the density of incomplete tasks at any time t as: where N is the total number of the tasks. Keeping the assumptions of Braha and Bar-yam i.e. β i = β, r i = r for all tasks and the homogeneity condition.
where k i (t) represents the number of incomplete tasks and < k in > represents the average number of incoming edges. The rate equation for the evolution of overall density of incomplete tasks is give by (1 − tanh(β < k in > α(t))).

(4)
The time evolution of the state of an individual task is To look at the overall density of the incomplete tasks, one can recover (4) by using (3) in (5).

B. EXPLORATION MODEL
In the beginning, we assume that coupling between tasks is β and the completion rate is r for all the tasks. Tasks are going to complete once the project gets started. Expanding or diminishing coupling will not impact the exploration of a task, but it will influence the completion rate if exploration occurs. This is because a task being explored will take more time to finish. Later on, during SDLC, the coupling between the tasks will be less because the explored solution is straightforward and less unpredictable. Since tasks are now straightforward and less complex, rework will be minimum, the completion rate will increase, and all tasks will be resolved in time. If exploration occurs, then the convergence rate will be less. After exploration, the convergence rate will increase, and all the tasks will be completed within time. In short, exploring a task will decrease the convergence rate for a short time. In the long run, the completion rate of tasks will be higher than their coupling, and all tasks will be converged timely. Increasing early exploration will increase the probability that the project will converge. To illustrate, for a given β and r, exploration adds simplicity, minimizes complexity to a project network, and all tasks converge to resolve state within time globally. When initial state of task i is incomplete at time t and exploration occurs, the state changes according to the following stochastic rules.
N α e f e (t)) (1 − tanh(β i k i (t))), 1 with probability (r i + Ne N α e f e (t)) (1 − tanh(β i k i (t))) (6) Under the uniformity and homogeneity conditions stated in the beginning, we can write (5) as whereβ = β < k in >. Furthermore, modify as follows: where f e (t) = −w • erfc(t−t • )+0.75w 1 is the exploration function which decreases the overall internal completion rate during the exploration time and increases the overall internal completion rate after the exploration, w • , w 1 are the exploration weights which needs to be specified a priori depending upon the nature of the task and the exploration work required, t e is the time until which the exploration takes place. It should be noted that the choice of the exploration function, f e (t), is not unique. The particular form used here VOLUME 4, 2016 is motivated by the smooth properties of the complementary error function [115].
Let N be the total number of tasks in the development life cycle, N • be the normal task i.e., those that are not being explored, and N e be the tasks that are being explored,then the density of incomplete normal tasks (α • ) and tasks that are being explored (α e ) is defined as respectively. The rate equation for the evolution of the density of incomplete normal tasks and incomplete tasks that are being explored becomes respectively.
Combining (11) and (12), with the use of (10), we get the rate equation for the evolution of the overall density of incomplete tasks, Note that if none of the tasks are being explored (i.e. N e = 0), our model (13) reduces to that of Braha and Bar-Yam [33]. For N e = 0, our mathematical model (13) captures the effects of exploration not being incorporated in the Braha and Bar-Yam's model. We can calculate the asymptotic solution of (13) to analyze the system behavior in the end state (i.e. when t → ∞). Note that in the end state the slope, dα dt , representing the rate of change in the density of incomplete tasks will be zero i.e.
where f * e is the asymptotic limit of the exploration function f e (t) i.e. f * e = lim t→∞ f e (t). The above relation can be simplified by noting that in the end stage α e ≈ α, hence simplifying (14), we get which reduces to the results of Braha and Bar-yam for N e = 0. Notice that for N e = 0, the value of α (obtained using (15)) is smaller compared to the analogous results of [33] which is due to the increased values of internal completion rate after the exploration as discussed earlier.

C. REFINEMENT MODEL
Refinement is the process of removing impurities and improvement of something by the making of small changes. It commonly occurs at end of each phase of development process i.e, UI, analysis, design, and implementation. During refinement, the value of the coupling parameter, β, will not change, but the internal completion rate of that task,however, will be little slow. During that time, the task is being refined hence the rate of completion, during that time, will be zero. When initial state of task i is incomplete at time t and refinement occurs, the state changes according to the following stochastic rules.
The overall internal completion rate r will be less than the previous overall completion rate. For the tasks that are being refined, the state changes as where w r is the refinement weight and f r (t) is a rectangular function whose value is one for the times when the refinement takes place and stays zero otherwise. The value of refinement weight w r is chosen to ensure that the internal completion rate of the task stays zero during refinement.
When refinement occurs, the overall density of incomplete tasks evolves according to where N r is the number of tasks that are being refined. A similar analysis, as presented in the preceding section, gives the asymptotic solution of (18) in the end state, Notice that the above solution (19) is the same as Braha and Bar-Yam's which is due to the fact that the refinement effects the convergence rate locally i.e., when the task is being refined, however, the exploration effects are global i.e., its effects are present for all time.

D. REWORK MODEL
When project discloses, state of all tasks is incomplete. At this stage, β is coupling between tasks and r is completion rate of all tasks. We are also assuming that all tasks start at same time. Rework is task attempting again due to changed input. Source of change input can be internal or external. Increasing or diminishing coupling will impact on the amount of rework.
Whenever a task gets complete, rework is determined by its impact on successor completed tasks. If the successor tasks are incomplete then there will be no rework due to input by current completed task. If the successor tasks are incomplete then output of the current completed task can make them incomplete again and create rework. The amount of rework created depends on how many incoming links are in the task, those are coming from incomplete task, and coupling weight of each link. By combination of both these factors (i.e. number of incoming incomplete links, and weight of each link) rework is calculated. At a time a task that is going to be complete, can make its successor tasks incomplete by changing input of successors. It is the situation that we have performed a task with some assumptions and after completion of some other task; the assumption get updated, so have to perform it again. When a task gets complete, it can make as many task incomplete as number of outgoing links to completed tasks. When initial state of task i is incomplete at time t and rework occurs, the state changes according to the the stochastic rules given in 20.
When there are too many outgoing links from the task that is going to be complete, then at that time, number of tasks those are going to be complete is less than number of tasks going to be incomplete. Because, rework is going to perform a task again due to changed input, the internal completion rate of the task r greater than previous internal completion rate, when it was first performed. Coupling (β) value will be high for successor completed tasks. When there will be rework then density of unresolved tasks (α(t)) will be high leading towards slow convergence.
Hence whenever rework occurs, the state of a task changes according to where w rw is the rework weight and f rw (t) is a step function which stays zero everywhere except at the time when rework occurs (f rw = 1).The rework weight w rw is chosen such that the state of the task, in which rework comes, becomes incomplete (s i = 0) at that particular time.
The overall density of the incomplete tasks evolves according to where N rw is the number of tasks in which rework occurs. In the end state, the asymptotic solution of (22) is given by which is same as Braha and Bar-Yam's showing that the rework effects are local, similar to the refinement effects, as discussed in the preceding section.

E. NEGOTIATION MODEL
Negotiation either leads to rework, refinement, or exploration. Convergence slowdowns whenever negotiation occurs. Completion rate of the tasks become too slow i.e.,(new completion rate r is much less than previous completion rate).
When initial state of task i is incomplete at time t and negotiation occurs, the state changes according to the the stochastic rules given in (24).

F. CUMULATIVE EFFECTS
During SDLC, different perspectives on iteration occur at different stages. In the preceding sections, we have modeled these effects individually. We, now present a model which incorporate all of these effects. When initial state of task i is incomplete at time t, the state changes according to the the stochastic rules given in (25).
The overall density of incomplete tasks, as a result of combined effects of different iteration perspectives, evolves according to (26) VOLUME 4, 2016

IV. SIMULATIONS RESULTS AND VALIDATION
In order to validate the models given by (13), (17), (22), (24), and (26), we have conducted simulations with following test example (random graph with N = 10 5 , < k in >=< k out >= 12, N • = 8 × 10 4 ,N e = 2 × 10 4 , w • = 0, w 1 = 0.7). Figure 1 shows the simulation results for [33] and (13). In this simulation it was assumed that 20% of the total tasks are being explored for the initial 10 time units. We therefore see that during the exploration, the rate of completion in our model is slower compared to Braha and Bar-Yam's model (with no exploration) whereas after the exploration, the completion rate increases in our model. On the other hand, the curve due to Braha and Bar-Yam's model shows a continuously decreasing trend in time with no effects from the tasks being explored. As mentioned above, the values of α, in the end state, obtained through proposed model (13) are smaller compared to the values of α obtained through Braha and Bar-Yam's Model consistent with our argument that the internal completion rate accelerates after the exploration. Also notice that due to higher internal completion rate(owing to the exploration effects), in our proposed model (13), the system has reached the end state (t ≈ 50) earlier than Braha and Bar-Yam's model.  (13). For the results presented it is assumed that 20% of the total tasks are being explored for t ≤ 10. Figure 2 shows the simulation results (for the same test example) using our proposed refinement model (18) and [33].
For the presented simulation results, it is assumed that 20% of the tasks are being refined i.e. N r = 2 × 10 4 for 15 ≤ t ≤ 20. It can be seen (dashed curve) that during the refinement, the overall internal completion rate is slower consistent with the theoretical effects of the refinement as explained earlier. Notice that during the refinement (15 ≤ t ≤ 20), the solid curve due to Braha and Bar-Yam's model continue to decrease uniformly showing no change in the pattern expected due to ongoing refinement in some of the tasks.
The simulation results for the proposed rework model (22), for N rw = 2 × 10 4 , are shown in figure 3. At t = 30, the dashed curve jumps from 0.1 to 0. 28 showing an increase in overall density of the incomplete tasks resulting from the rework. On the other hand, the solid curve due to Braha and Bar-yam's continues to decrease showing that the overall density of the incomplete tasks decrease continuously without any influence from the rework.  [33] whereas dashed line corresponds to our proposed rework model as given in equation (22). In rework model (i.e. dashed line) it is assumed that 20% of the total tasks are being reworked, rework occurred at t = 30.
To elaborate the effects of negotiation, we assume that the rework occurs in 20% of the tasks as a results of the negotiation. Hence the modeling for this particular case is the same as for the rework presented in the preceding sub section. We show the simulation results, for the same test example, for N n = 2 × 10 4 , negotiation time t n = 5 in figure 4. The dashed curve shows a sudden increase at t = 5 due to the rework arising as a consequence of the negotiation. As noted in the results presented in 4, the curve due to the Braha and Bar-yam's model shows no influence due to the negotiation at t = 5.  [33] whereas dashed line corresponds to our model as given in equation (22). In negotiation model (i.e. dashed line) it is assumed that 20% of the total tasks are negotiated, negotiation occurred at t = 5.
The simulation results for the combined effects of all perspectives on iteration (26) during the complete software development life cycle are shown in figure 5. In figure 5, the negotiation occurs at t = 5 showing sudden increase in fraction of incomplete tasks at that time. We can see in the dashed curve that the tasks are being explored till 15 time units. During the exploration time, the rate of convergence in our proposed model is slower as compared to Braha and Bar-Yam's model (i.e. solid curve). It can be seen (dashed curve) that tasks are being refined between 30 to 35 time units. The overall convergence rate is slower during the refinement time which is consistent with theoretical effects of refinement. At t = 40, the dashed curve jumps from 0.8 to 1.5 showing an increase in the fraction of incomplete tasks resulting from the rework. On the other hand, the solid curve due to Braha and Bar-Yam's model continues to decrease showing that there is no effect on the fraction of incomplete tasks due to the different perspectives on iteration.
We have demonstrated the effects of the different perspectives on iteration during SDLC. The proposed mathematical models capture the effects of individual perspectives of iteration on the density of incomplete tasks. The developed mathematical models for exploration and rework are entirely  [33] whereas dashed line corresponds to our model as given in equation (26). In our proposed model (i.e. dashed line) negotiation takes place at t = 5, exploration continues for the first till 15 time units, refinement occurs at t = 30 and its duration is 5 time units, and reworks occurs at t = 40 time unit. consistent with the theoretical effects; however, there are some limitations in the model of refinement and negotiation. The refinement's theoretical effect is that the convergence rate becomes slow during the refinement period but speeds up after refinement. We have modeled the refinement to slow down the internal completion rate r during refinement time, but the model does not exhibit the accelerating rate of convergence after the refinement. In software engineering literature, rework can be external and internal. In this paper, we have successfully modeled the effects of external rework, but internal rework implementation is future work.
Finally, we have performed simulations and compared the simulation results with the deterministic solution. The simulation runs followed the deterministic solution as shown in figure 6.

V. CONCLUSIONS AND FUTURE WORK
Different authors use different terms to refer to iteration in the software engineering literature. To resolve the issues related to unplanned iteration, we are contributing in two ways. First, we have defined different perspectives on iteration to clarify the different viewpoints through a literature review on iteration in the software engineering discipline. The second contribution is the modeling of iteration perspectives to determine the impact on project completion time. We have modeled the impact of each iterative situation on project completion time. Understanding different iterative situations and their after-effects play an essential role in success. It increases the visibility into processes by simulating different iterative models to predict outcomes, see future risks, forecast how much time can be delayed, and results in identifying improvements based on those. We have evaluated our results by comparing simulation runs with the deterministic solution.  The developed mathematical models have some limitations. Models for exploration and rework are entirely consistent with the theoretical effects. However, there are some limitations in the model of refinement and negotiation. In software engineering literature, rework can be external and/or internal. In this paper, we have successfully modeled the effects of external rework, but internal rework implementation is future work. Furthermore, negotiation can either lead to rework, refinement, or exploration. Here we are only considering the negotiation during the requirement phase of the software development life cycle, and we have modeled the case of rework as a consequence of negotiation. However, we can improve the negotiation model by randomly selecting the type of iteration (i.e. rework, refinement, or exploration) or by using some average effect combining the effects of all three perspectives as a consequence of negotiation. We will create a taxonomy of iteration in software engineering through a systematic literature review to validate different perspectives on iteration.