Complexity Estimation for Distributed Software Development Using SRS

In recent years distributed software development has gathered pace. Many development programmes now require asynchronous coordination several time zones apart between geographically dispersed teams. Owing to considerations such as effort spent on team development and technology sharing, software complexity calculation for such projects is difficult to establish a software system infrastructure that can be efficiently spread and minimizes cross-site connectivity, enabling communication between remote teams working on interrelated sections of the architecture and their day-to-day interactions. A globally distributed software project faces, in addition to the technological complexity, an additional complexity contributed by the different supporting parameters. This paper defines these parameters and attempts to estimate all the complexities described above and incorporate these two measures to obtain the corresponding overall measure of complexity during the requirement analysis phase.


Introduction
Geographic distribution of software development projects has been a requirement in recent years, and the software companies are now responsible for shifting their development teams to localized areas where qualified workers are more easily accessible, hence taking benefits of political and economic factors. The situation where a software company's numerous teams are spread outside a nation's limits is called Distributed Software Development. To produce a better quality of software products at low costs, as compared to co-located software projects, the main aim of this type of production criterion is to maximize capital. Sahay (UiO) defines DSD as "Software work undertaken at geographically distributed locations across national boundaries in a coordinated fashion involving synchronous (real time) and asynchronous interaction".
During the software lifecycle, Distributed Software Production enables team members to be located in multiple remote locations, creating a network of sub-teams that are geographically distributed in nature. Such teams may belong to the same organisation or there may be collaboration/outsourcing between various organisations. Face-to-face interaction between team members is a requirement when working on a distributed project and it involves the use of various technologies to promote communication and coordination [9].
For companies today, the distributed production of software systems and their implementations is increasingly growing in importance. There are various explanations why the trend of operating in a distributed environment should be embraced by an entity. It includes availability of a greater labour IOP Publishing doi:10.1088/1757-899X/1116/1/012193 2 pool and a good combination of skills and experiences, advantages in cost, and longer working hours [4].
A good development team for software has rich formal and informal interactions between its team members. It has a familiar organisational culture, required coordination and effective control; providing a good combination of technical skills and appropriate experience and known projectrelevant tools and technologies. DSD introduces new challenges and requirements to the product development process as it potentially threats all of the above mentioned ideal properties.
The aim of this paper is to define and then formulate different parameters that affect the software product cost in a globally distributed setting.

Related Work
Jorge Cardoso [1] discussed the requirements to develop a measure to analyze the complexity of processes in distributed software development. He stated that high complexity in a process is a key to bad understandability resulting in more errors, defects, and exceptions and hence lead processes to require more time to develop, test, and maintain. Therefore, avoiding excessive complexity becomes an essential part in software development.
Threats to communication, control and coordination in distributed development were considered by the authors in [2] due to Temporal Distance, Geographical Distance, and Socio-Cultural Distance.
Dr. Ashish Sharma and Dr. D.S Kushwaha proposed a complexity measure [16] based on the factors derived from SRS Document. Even before the analysis and design phases of SDLC, the measure can estimate the software complexity efficiently. But the approach is limited to centralized software development.
R Britto et.al in [15] developed a process that helps in developing systematically onboarding strategies.
Based on four key explanations for estimating the cost and effort of software development, the Function Points (FP) system approach was used in [35] by RS Dewi et.al. Considering Ricardo Britto et.al in [36], the findings of a systematic literature review for Global Software Development (GSD) effort estimation were presented so that the researchers and practitioners could have a clear understanding of the current state of the art about GSD effort estimation. Their outcomes indicated that an improvement on effort estimation in GSD can be made to the current state of the art. M Shameem et.al researched [37] in order to explore and prioritize the challenges of scaling agile practices in the DSD setting. Lack of efficient communication, management responsibilities, sharing of information, etc., are described as the most critical challenges for scaling agile methods by organisations.
Through [40] the authors contributed to the specification of the system and the analysis that has the ability to assist in mapping communication patterns for global software development. In addition, this platform includes communication evaluation interfaces and intercommunications from automated engineering instruments as bots.

Objective
The main aim here is to define and then formulate various factors that affect the software product's cost in DSD. The complexity of these factors is stated as Supportive Complexity (SC), which is then added to the technical complexity determined in the requirement analysis phase using RDPDC [12]. The given measure of complexity gives an approximate value of the total complexity of a software product (using SRS) to assist the project managers and analysts and the concerned development teams, who are greatly influenced by the dynamic behavior of DSD. [2], [8], [19], [21], [22] discuss the various parameters that affect the complexity of a globally distributed software project. These parameters are shown below (

Proposed Measure
The proposed framework for estimating complexity of software projects in distributed environment is shown in the figure below:

Technical Complexity
This complexity is estimated by adjusting the IRBC measure, as suggested in [16], in order to respond to the differences faced in DSD. The key benefit of using IRBC is to achieve the complexity of the software product using SRS in the requirement analysis phase itself.

Supportive Complexity
Different additional requirement parameters given in Figure 1 add supportive complications to the overall estimate of the complexity of the software product being produced in DSD, relative to the complexity of software in centralized production.
As shown in Figure 2, the fusion of the complexities determined by Predictor Variables (PVC) and Control Variables (CV) gives the Supportive Complexity (SC). The estimation of these complexities is described in section 5.2.1 and 5.2.2.

Predictor Variables Complexity (PVC):
The model suggested in [27] by H K Edwards & V Sridhar, uses separate predictor variables shown in Figure 2. The variables are identified after analyzing the factors that influence the efficiency and output of globally distributed virtual teams participating in the software development life cycle requirements specification process. Using heterogeneous teams scattered all over the world, the paper simulated the realities of the multinational software development environment. Now, in order to estimate PVC, the proposed measure is using the Predictor Variables defined by the authors in [27] and the corresponding 38 measurement items used in order to prove the construct validity as they are very well covering the parameters identified in section 4 and their impact over the complexity of a DSD project.
Requirements analysis phase is a critical phase in software engineering. The effectiveness or failure of the software project is decided by the compliance of the specifications especially in case of distributed development that presents several new difficulties as well as the rise of fundamental difficulties [32] [33]. So, right from the creation of the first version of SRS by the specification team, review and adaptation by the creation team, to the creation of the last version of SRS by the specification team itself, and the allocation of tasks and their approval by the team members at remote sites requires team members to communicate effectively and work collaboratively in order to obtain a good SRS apart from several differences, be it time, language, cultural, team size or technical. Finally, "virtuality requires trust to make it work: Technology on its own is not enough" [34].
The proposed measure suggests the calculation of the prediction variables by taking the evaluation of the measurement items by the remote site team analysts during the final stages of the SDLC's requirement elicitation and analysis phase. For the analysis to be conducted by the controlling location, the evaluations of the team analysts can be made by online GUIs accessible at the organisational sites. On a seven point Likert-type scale, all the items should be calculated as in [27] and then the mean rating of each variable for each site k is calculated as: Where MRp refers to the mean rating of the p th variable, RMIap is the p th variable's a th measurement item rating and i is the no. of measurement items for p th variable concerned. Obviously, the max value of these measures will be 7. Thus, the total value of MR for s no. of sites can be summed up as:

Control Variables Complexity (CCV):
Control is the method to fulfill the objectives, strategies, norms, or standards of quality defined by an organisation. As seen in Fig 1, this is one of the parameters determined in section 4. In essence, the proposed measure deals with the two major forces influencing an organization's control; they are Project Management and Instability/ Uncertainty. Using the project management variable PMGMT and an Uncertainty variable UC, both variables are calculated separately.
In order to accomplish particular objectives and goals, project management is the practice of preparing, coordinating, obtaining, and handling resources, and for this, an organisation needs welldefined procedures to help fulfill client and quality expectations.
As Dr. Edwards Deming, Quality Management theorist, consultant and author once said, "If you can't describe what you are doing as a process, you don't know what you are doing".
The SEI's Capability Maturity Model has five stages of organisational 'maturity' in terms of processes of software development that assess efficiency in the delivery of quality software. The proposed measure, as per the SEI-CMM Level, assigns a count value for the organisation and considers this value as the measure of PMGMT as shown in the figure below: Now, [26] claims that in the essence of globally distributed software projects, lack of knowledge of certain basic factors inherited makes developers fail and innovate new ways to survive. The paper summarizes various risks and their various negative effects and formulates the specifics of certain projects and their effects on the project success for managing uncertainty. Taking into account the length of the list of global threats and the difficulty of risk analysis, a method is built to computerize project outcome forecasts, appropriately labeled as a "risk barometer", for project managers to assess global project threats, taking into account the likelihood of occurrence and potential negative effects that can be correlated with past data of other projects. The instrument forecasts the amount of risk exposure for a hazard of scale [0; 1500].
Here the measure proposed divides the scale into 5 ranges and gives each such range a count value and considers this value as the measure of UC, as shown in the Table 3.
Thus it is appropriate to sum up the total complexity by control variables as: Hence, the overall Supportive Complexity can be measured as: And thus, for a project developed in a distributed setting, the final complexity can be given as:

Robustness Analysis of the Proposed Measure:
In order to analyze the robustness of CDSD, it has been evaluated against the 9 Weyuker's [5] properties. The results are shown in the Table 4: The application of the proposed CDSD measure has been explained in the next section.

Results
The proposed measure CDSD has been applied over ten well known algorithms and their results are compared and analyzed against the several existing ones like LOC, McCabe [14], IRBC [16], Halstead [6], CFS [41] and KLCID. Also, the complexity for "Email Classifier" project is calculated using CDSD measure. CDSD depends on the problem criteria and the additional parameters that were held constant for all 10 problems, such as connectivity, collaboration and control between team members. Thus, the IRBC plot, which also relies on the problem specifications, is very much compatible to CDSD (Figure 3).

Conclusion
This paper has investigated some factors that are affecting the performance and complexity in DSD. Through this paper, an attempt has been made to suggest a qualitative approach for estimating the difficulty of a project being developed in a distributive environment.

Motivation
There are several software complexity measures for estimating the difficulty while working in a centralized development environment. But, the same is not true in case of Distributed Software Development. Any framework or methodology for estimating the complexity in a distributed environment has not yet been proposed. So working on such significant area seems to be both challenging and interesting.