The defect reduction in SDLC is very popular today, however, against a background of diverse interpretation of quality it is difficult to get a holistic view of the problem and the basic principles of quality management. Perhaps, the review of methods for improving quality and the approach to quality analysis suggested in the article will help to look at this task differently. According to GOST R ISO 9000-2001, quality is “the degree to which the inherent characteristics of the product meet the requirements”, which may not be interpreted in the field of software development. Therefore, the quality of the software product is the degree of correspondence of the functional, technical, operational characteristics of the developed software product to the goals that were set before the development of this product.
For quality analysis, we introduce a generalized criterion, a defect that determines any deviation from the quality standards established for the project. For example, lack of functionality or excess functionality-defect; inconvenient interface-defect; bad design or dirty code, which will adversely affect the accompanying, – defect; unacceptable performance-defect; incorrect program work, is a special case of a defect; the spelling error in the documentation is a defect.
Defects can be classified according to the following parameters:
- type (determined by the development phase or the activity on which the defect was introduced);
- criticality (how critical is the presence of a defect in the software product);
- priority (how important it is to correct the defect);
- complexity (how much time-consuming to correct a defect);
Having such a generalized indicator, it becomes easier to evaluate and analyze the quality of the developed software product, as well as the quality of the development process itself. We can consider the number of defects or the sum of their weights (by any parameter), we can estimate the density of defects per unit volume of the product, analyze which phases of the process are the most problematic for us, etc., reducing the struggle for quality to combat defects.
Defects search
Consider, for example, the system-testing phase, during which a certain number of Dfound defects are detected, but some defects remain unavailable at the time of completion of the Dmissed phase (Fig. 2). The total number of defects that have passed through the phase will be Dfound + Dmissed.
The ratio of the defects found to their total number, expressed as a percentage, will be called the efficiency of defect search – this is one of the main characteristics of the quality of the development process, which must be constantly monitored. For each phase during which defects are found and corrected, with a stable and predictable process and other equal conditions, this value can be considered approximately constant, which allows one to quantify the quality level (expressed in the number of defects not found) for the current and for the planned projects.
The effectiveness of defect search can be considered for separate phases as well as for the entire development life cycle. In this case, the efficiency of individual phases determines the efficiency for the entire life cycle. Each phase of defect search can be regarded as a kind of filter that retains some of the defects, and the entire life cycle is a filter system . If in the early stages of the life cycle there are bad filters that miss many defects, these defects accumulate, and in order to filter them well, a very good filter will be needed at the end of the life cycle (testing phase).
Defects with time tend not only to accumulate, if not to take early measures to eliminate them, but also to increase the cost of their correction, and often this dependence is exponential. For the waterfall model of the life cycle, this dependence is well illustrated by the graph in Fig. 3. For the iteration model of the life cycle, the picture will be similar, only the inscriptions will change: instead of phase, names there will be numbers of iterations.
Methods for finding and preventing defects
An effective defect search strategy consists in applying a combination of several methods, each of which will have its own level of efficiency, expressed in percentages. According to the data of, testing has a relatively low efficiency of defect search (30-40%), and in order to make it high, it is necessary to increase the cost of the testing process at times (the effectiveness of beta testing for the number of testers over 1000 is about 75%).
It is hardly possible to develop software without any defects, but it is worth trying to try to reduce the number of defects introduced. We list the most well known methods for preventing defects.
- Prototyping. Creation and testing of the model of the developed system in order to verify its characteristics and to identify incorrect assumptions and decisions that could lead to serious defects (and modifications) in the development.
- The use of standards for all types of products produced during the development of software (requirements, design, code, various documentation, etc.).
- Application of the component approach.
- Using ready-made components – the less you have to develop new solutions, the fewer errors.
- Preliminary development of test cases (before the coding stage) allows you to better understand the requirements for the system being developed and better design it. A particular case of this approach is Test-Driven Development, in which unit tests are developed not before but before encoding.
- Refactoring the code that is, bringing it into the proper form.
- Regular analysis of the causes of the appearance of the most serious defects and the search for ways to eliminate these causes.
This can occur at periodic meetings of the development team, or you can conduct such analysis for each serious defect found during the system-testing phase or after implementation. The result of such an analysis should be modifications of the development process aimed at eliminating the causes of defects or, at least, contributing to the early detection of such defects.
It is also worth mentioning the human factor; no methods will replace the professionalism and experience of developers and managers. Experienced professionals, as a rule, make fewer mistakes, which gives a good background for quality development.
Quality Management Process
For quality management, it is not enough to simply use various methods to improve it-they need to be consciously systematically applied, which would become an integral part of the process of developing software oriented toward quality. It is necessary to continuously monitor the quality of the software being developed through quality metrics (defect density, the size of alterations, the average time between failures, etc.), as well as quality control of individual sub processes that make up the entire development process.
Methods that worked well yesterday today can be a waste of time. Each project can have its own specificity, which requires a different set of methods for improving quality. For example, some projects (especially critical ones) may require thorough testing of all test cases, in others (when testing is very laborious), more attention should be paid to inspections, third (innovative) will require pre-prototyping, the fourth (resource-critical) will require stress testing and etc .. If you do not constantly monitor the effectiveness of methods, then in time it can significantly decrease.
References
Balaji, S. (2012). Waterfall vs v-model vs agile : A comparative study on SDLC. WATEERFALL Vs V-MODEL Vs AGILE : A COMPARATIVE STUDY ON SDLC, 2(1), 26–30. https://doi.org/10.1.1.695.9278
Ragunath, P., Velmourougan, S., Davachelvan, P., Kayalvizhi, S., & Ravimohan, R. (2010). Evolving A New Model (SDLC Model-2010) For Software Development Life Cycle (SDLC). International Journal of Computer Science and Network Security, 10(1), 112–119.
Amlani, R. D. (2012). Advantages and Limitations of Different SDLC Models. International Journal of Computer Applications & Information Technology, 1(3), 6–11.
Mahalakshmi, M., & Sundararajan, M. (2013). Traditional SDLC Vs Scrum Methodology – A Comparative Study. International Journal of Emerging Technology and Advanced Engineering, 3(6), 2–6.
Moparthi, A. N. R., & Geethanjali, B. N. (2016). Design and implementation of hybrid phase based ensemble technique for defect discovery using SDLC software metrics. In Proceeding of IEEE – 2nd International Conference on Advances in Electrical, Electronics, Information, Communication and Bio-Informatics, IEEE – AEEICB 2016 (pp. 268–274). https://doi.org/10.1109/AEEICB.2016.7538287
Tutorial.com. (2014). Software Development Life Cycle (SDLC). Software Development Life Cycle (SDLC), 1(1), 9–12. https://doi.org/10.1017/CBO9781107415324.004
Khan, P. M., & Beg, M. M. S. S. (2013). Extended decision support matrix for selection of sdlc-models on traditional and agile software development projects. In International Conference on Advanced Computing and Communication Technologies, ACCT (pp. 8–15). https://doi.org/10.1109/ACCT.2013.12
N.d. (2013). SDLC Waterfall Model. Tutorialspoint. Retrieved from www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm
Tutorialspoint. (2017). SDLC. https://doi.org/10.1017/CBO9781107415324.004
Arora, I., Tetarwal, V., & Saha, A. (2015). Open issues in software defect prediction. In Procedia Computer Science (Vol. 46, pp. 906–912). https://doi.org/10.1016/j.procs.2015.02.161
