Software Development Life Cycle early phases and quality metrics: A Systematic Literature Review

Most of the currently used software development metrics are concentrated on the latter stages like development and testing. However, early revealing of errors during the SDLC(Software Development Life Cycle) tremendously affects the efficiency of the team work by spending more time on prevention and less on correction in later stages. Furthermore, reworking in later stages increase the cost of quality, lead to extra waste of time of the development team. The objective of this review is to examine the classification of the existing SDLC(Software Development Life Cycle) early phases and define the set of software process quality metrics. Based on the SRL research protocol, we selected the most relevant studies from overall 200 publications by the use of search keywords and inclusion/exclusion criteria for quality assessment of primary studies. This systematic literature review yields the correlation of cost, time and software product quality with the SDLC stages.


Introduction
For the past few decades, the software development methodologies have been evolving intensively. Newly created Agile methodologies have changed the concept of SDLC and Software development methods implementation. Software Development Life Cycle (SDLC) is the time required for the activities such as defining, developing, testing, delivering, operating and maintaining the software or the system. The development team's productivity and the software quality depend on the effectiveness of defining and analyzing the software process metrics throughout the SDLC. Early defects detection in early phases of the software process is one of the sources in the way to a successful project. However, the classification of early phases can vary referring to the methodologies the company uses. Hence, methods for assessing and evaluating the quality of the software process depend on the company preferences. Therefore the set of measurements that should be tracked during the evaluation process differ as well. This paper demonstrates the classification of SDLC phases, in particular early phases, sundry software quality evaluation methodologies and set of measurements.
Therefore, we decided to conduct a Systematic Literature Review of Software Development Life cycle phases and metrics that can be collected during early phases of software process. This research will help us further sort metrics according to the process methods, define development stages of assessment methods and to create the base set of metrics to predict the efficiency of the team and the process.

Research method
Research methods we chose research questions on software development life cycle phases and metrics to perform the review of relevant literature to address in this SLR. Referring to [1] first we defined search strategy to detect as much of the relevant literature as possible, then we use explicit inclusion and exclusion criteria for assessing potential primary study.
The aim of this Systematic Literature Review is to obtain information about existing types of phases in software development process in variety SDLC's (Software Development Life-Cycle) from primary study. Later in this section, the quality criteria to evaluate the primary study will be also provided.

Research questions
The following Research Questions for definition and analysis of the relevant literature were formulated: (i) What is the classification of the software development life cycle phases? (ii) What are the existing models/approaches to assess and evaluate software quality in early phases? (iii) What activities are performed in the software development life cycle phases? (iv) What metrics are collected during the software development life cycle phases?

Review protocol
This section describes the set of activities performed to answer the formulated research questions during this SLR. Firstly, search strategy was defined by setting the search parameters to use for search strategy. Search parameters include: • "Software development life cycle phases and quality metrics" • "Software development early life cycle phases and metrics" According to Kitchenham Achimugu [1], we used enhances strategy of deriving major terms from the research questions.
Data sources for searching the search terms were selected based on the availability of free libraries, which are: As a result, we get more than 200 publications in the listed open-source libraries above. The results of the search terms were sorted into a primary selected studies in accordance with the selection instructions that is proposed in [2]. The approach includes several steps to conduct a qualitative assessment of the publications selected: (i) First, we selected the initial set of publications with automatic and manual search techniques; (ii) Second, studies were selected as primary studies according to their related keywords, title and abstract. (iii) Third, the primary studies were then scanned in a details by fully reviewing the papers.
The studies were not selected on the report of the year of publication. In the Figure ?? Owing the fact that the field of early stages of SDLC is not fully researched yet. During the SLR, we applied exclusion criteria of eliminating the duplications, irrelevant and not complete studies. The studies that do not represent exact separation of stages of SDLC were not included.  In the first step of studies selection according to title and abstract, only 29% of studies were accepted and 5% were eliminated for duplications. The next step were conducted by reading the whole publication with details.

Results
This Systematic Literature Review assess software metrics, models and methods to track and analyze software quality in early phases, concentrating mainly on Requirements management and Design phases of SDLC.
In the first iteration proceeded by inserting search strings to open-source data libraries,slightly over 200 publications were selected. Whereas, in the second iteration where we analysed Title, Keywords and Abstract we sorted 60 primary studies related to our topic of interest. After scanning primarily selected studies whole content in detail, they were classified from 0-2 scale in the order of relevance(0-not relevant,1-partially relevant, 2-relevant) in Table 1. From the whole set of papers 6,9% works were eliminated as duplication.

Results
In this section, the results of conducted review is provided. By analyzing the existing software process early phases, methodologies and metrics to assess and evaluate the quality of the software we have answered all four research questions.
In general, almost all of the studies elaborated software life early phases into Requirements Management and Design phase, and sometimes Code. The publications weight representing the respective early phases of software life is described in the following list: • Requirements phase -17,2% • Requirements and Design phases -24,1% • Design -31,0% • Design and Code phases -3,4% • Code and Testing phases -3,4% • All phases -17,2% But some of the papers defined phases of software process differently. As the paper [37] defines the software development life cycle early phases includes User Needs Analysis, Definition of the Solution Space, External Behavior Definition and Preliminary Design. Where the first three stages union is the Requirements stage. It consists of all the activities up to the decomposition of the software architectural components.
Whereas,researchers in [37] have established typical software Life Cycle early phases preceded by these phases listed below: • Initial planning phase -the technical and economic basis for the project should be established • Analysis -the functional performance requirements for the software configuration items are defined. This phase's result is the successful completion of Preliminary Design Review (PDR) • Design -this phase include the allocation of requirements to software components and culminates with complete Critical Design Review (CDR) As it can be seen here, the initial planning and analysis phases stated in [37] can be traced to Requirements Management phase according to the activities proceeded during these phases.

3.2.
What are the existing models/approaches to assess and evaluate software quality in early phases?
In particular there are some studies and surveys suggesting models or approaches to assess and evaluate the software quality in early phases. One of these kinds of researches that analysed Requirements documentation can be Aversano et al [38], which performed assessment of the documentation of ERP(Enterprise Resource Planning) open source systems to understand the high quality documentation. They analysed the quality in terms of two aspects: Structure Quality and Content Quality. The paper highlights that the documentation is composed of documents that can be of the different kinds, API, Wiki, text and code comments. First, Structure Quality indicators are listed in the Table 4 in Appendix.
As the paper suggests,for evaluation of these metrics NLP application, Information Extraction and Information Retrieval techniques are required in order to make an objective analysis [39]. Second, content quality model includes a set of quality attributes to evaluate the documentation(see in Table 5 in Appendix) The authors were applying three ERP systems: Openbravo, Compiere and ADempiere to obtain results.
According to [40], suggests that quantitative measures and metrics be integrated with requirements specification language and other automated tools like Ada, ISDOS, PSL, PSA, SREM, SADT, SAMM, etc. CAME tools -(Computer Assisted Software Measurement and Evaluation) tools are tools for modelling and determining the metrics of software development components referring to the process, the product and the resource. Presently, the CAME tool area also includes the tools for model-based software components analysis, metrics application, presentation of measurement results, statistical analysis and evaluation [41].
ESQUT software quality evaluation tool -which was used by many software development departments in authors' company,can measure C and COBOL source code and detail design documents are expressed by tree-structured charts [42].
Service Oriented Requirements Traceability Tool (SORTT) -authors developed a prototype tool towards process automation. The tool automates the aforementioned translating, indexing, querying, filtering, and rendering activities. It's purpose is to mitigate factors such as the time and effort of extracting trace links [43].
Source Monitor and CCCC tool -to compare the programs written using design patterns with those written without using design patterns [44].
Some of the research studies interpret several clustering analysis techniques to predict software metrics quality like fuzzy c-means, k-means Gaussian mixture model and etc [45]   According to [37], the taxonomy of early phases includes phases and activities include User needs analysis, Definition of the Solution Space, System requirements, System Design In general, the software development process early phases involve Requirements Analysis and Definition, and Design phases [49].
Requirements Analysis and Definition phase involves activities like Feasibility study, requirements elicitation, requirements analysis, requirements validation, and requirements documentation.
Design phase, in which the overall system architecture is established [?]. This phase involves several activities like examining the requirements document, choosing the architectural design method, choosing the programming language, verifying, specifying, and documenting design activities.
To conclude, we can argue that the activities to be conducted during the phases of software process depend on the type of quality assessment and evaluation method the company choose. However, the default activities during the general phases are given as the results from the several studies in this section above.
3.4. What metrics are collected during the software development life cycle phases? SDLC software metrics are usually associated with uncertainty that can be assessed by fuzzy set theory [50]. The authors in [46] suggests that the way to capture uncertainty, vagueness and imprecision in software metrics is a fuzzy set theory. The same concern have the other  [53].
Victor R. Basili [54] conducted an empirical validation of OO metrics that in the environment of Object oriented analysis and design method. They discussed the relationship between Chidamber and Kemerer's OO metrics and Fault Probablity in high-and low-level design phases of the life-cycle. The result of the research has shown that five out of the six Chidamber and Kemerer's OO metrics was useful to predict class fault-proneness.
Similarly, Kumar et al. [55] suggests a model for the defect detection in the early stages of development life cycle like design and early coding phases can be pre-defined with the Complexity, coupling and cohesion (CCC) related metics.
According to Bharathi et al. [56], the realiability of the system can be decided by mapping of design metrics that depend on the external parameters like operational profile, maturity and the domain of the project.
Also in [37], the primary factors of the user interest in the requirements management phase were defined as functions performed, response time, user interface and reliability. Whereas the primary factors of customer interest include functions performed, development time, cost, maintainability, modifiability, and reliability.
However, [46] argues that predicting the reliability of the software is impossible due to the computational complexity. Consequently, authors selected top reliability relevant metrics for requirements engineering phase -Requirement Defect Density, Requirement Specification Change Request and Requirement Inspection and Walk through; for design phase -Cyclomatic Complexity and Design Review Effectiveness; Whereas, Phillips et al. [57] offered methodology approach to improve space system resilience with architecture design, system engineering and increased software security by reducing the risk latent software defects and vulnerabilities.
During the SLR, we have collected variety set of metrics, nonetheless, McCabe, Halstead, Cyclomatic Complexity and CK metrics were the most popular software metrics that were mentioned in majority of selected studies [ Table 2) and Design phases (see in Table 3). The degree to which a software system meets the specified requirements, design and coding

Dicussions
As we stated from the beginning, the aim of this SLR is to define and evaluate the methods, their corresponding metrics and the early phases to conduct assessment and evaluation of quality of the software process.
Created research questions to define are the classification of the software development life cycle phases, the existing models/approaches for software quality in early phases, activities that are performed during these phases and metrics accordingly.
Firstly, we defined a general set of phases and helpful metrics that are applicable to the widely used models like Waterfall and Agile methodologies. The limitations of our research paper is that we took the general classification of SDLC phases not classifying them into Agile or Waterfall. Despite the fact that Agile methodology phases are performed in a short period and iteratively as opposed to Waterfall model. The results of SLR has shown that 75.7% of the studies indicate Requirements Management and Design phase as early phases of software development process.
Second, there exist many methods to assess and evaluate the software quality like: Software tools (CAME tool [3], Source Monitor [4], CCCC, BBN model [5], ESQUIT tool [6]) use of Machine Learning approaches [7] (decision trees, SVM, genetic algorithm Naive Bayes) analysis of particular modules to analyze complexity, functionality and maintainability (Enterprise Resource Planning [8], UML diagrams [9]) Some of the research studies interpret several  The extent of working on new functionality rather than just enhancing the older functionalities of software Table 3: Design phase Metrics clustering analysis techniques to predict software metrics quality like fuzzy c-means, k-means Gaussian mixture model and etc. The method can be chosen at any phase of the software process aiming at evaluation of quality parameters unders interest. Starting with cost evaluation frameworks for fault prediction models in analysis level till formal measurement approaches to evaluate static code and automated tools for assessing maintainability of the software. Third, SDLC software metrics are usually associated with uncertainty that can be assessed by fuzzy set theory [10]. The authors in [11] suggest that the way to capture uncertainty, vagueness and imprecision in software metrics is a fuzzy set theory. There are considerable number of studies dedicated to software quality evaluation, nonetheless, the base metrics that were mentioned in almost all of these researches are almost the same: Chidamber and Kemerer's OO metricssoftware metrics tailored to object-oriented software design Cyclomatic complexity -responsible for measurement of structural complexity of the code Lines of Code -emphasizes on calculating numbers of lines in a piece of code. Halstead complexity metric -identifies measurable properties of source code, and the relations between them. To sum up, selected metrics give more insights if the basic measurement is correctly traced and analysed.

Conclusion
In conclusion, a successful project acquires the track, control and analysis of the software development process throughout the SDLC. To maintain the constant pace of project development [12] and timing, one needs to measure the software process as early as possible. Generally,the early phases include requirements management and design phases. The metrics can vary depending on the methodology and the goal of the company. The future works in this direction will be the further discussion of Uncertainty level,experiment on the useful and working methods to conduct the software quality evaluation process. As Benjamin Franklin said [13], "The bitterness of poor quality remains long after the sweetness of low price is forgotten". Therefore, one should never delay in ensuring the process quality that will lead to a consequent product.