Reliability Assessment in Functioning of Requirement Defect Mitigation

International Journal of Information and Education Technology, Vol. 2, No. 5, October 2012 Reliability Assessment in Functioning of Requirement Defect Mitigation Sandeep Kumar Nayak, Raees Ahmad Khan, and Mohd. Rizwan Beg   II. DEFECT MITIGATION PROCESS Abstract—There are few techniques involved in mitigating defects in developing software at early stages. A concrete and cost effective technique for defect mitigation in early stage is highly indispensable in modern era of software application and implications. In this paper, we are attentive over an effort to initiate a requirement defect mitigation algorithm including three phases working step by step under mitigation process. In the mitigation process flow, the mitigation algorithm may be competent to fix up the defects for delivering significant reliable requirement for the further phases of system development process. The implementation of defect mitigation process would also be appreciated by industry, software developers and innovators in future. This study is the extension of our previous work [5, 6] in which free wheel structure for Defect Mitigation has been mentioned for mitigating the requirement defects. Here mitigation process is executed through some steps as mentioned in Fig. 1. for delivering the Reliable requirement Specification. Index Terms—Requirement mitigation process, mitigation algorithm, reliable requirement specification, requirement defect. Input by Defect Inspection Technique Requirement Defect Severity & Priority Level Requirement Defect Database (Defect Description) I. INTRODUCTION Decades have been passed for attempting to improve the reliability of the developed software by many researchers but the emergence of defects is still a big problem. Therefore it is necessary to introduce the best practices for identifying defects and their proper mitigation to deliver the reliable requirement for making reliable software. Defect identification and mitigation are limited to risk assessment on ad hoc basis [1], [2]. Some researchers entertain only frequently raised risks and provide a way to handle them. Researchers are interested in unleashing all the handling and avoidance mechanisms for software risks only [3]. Some study narrates only the effect of different patterns of requirements discovery on a software project [4]. In our previous study, free wheel processing assembly consists rotational free wheel structure (Fig. 1) named Defect Mitigation which takes the combined output of Requirement Defect and Severity & Priority to apply mitigation variables for mitigating the defect so that at the outer end a Reliable Requirement Specification (RRS) may deliver [5], [6]. In this paper we are giving an algorithm for mitigating the requirement defect as it identified by inspection technique [6]. Free Wheel Processing Incomplete Is Defect Mitigated Free Wheel Processing Complete Reliability Assessment Process Termination Document Storage Reliable Requirement Specification Fig 1 Requirement Defect Mitigation Process Flow Fig. 1. Delivering the reliable requirement specification. A. Requirement Defect Whenever the initial requirement enters into the Free wheel processing assembly, entertains by Inspection Technique to deliver the requirement defects then the severity and priority level be assign to each and every requirement defect as TABLE I:  Manuscript received May 1, 2012; revised August 14, 2012. Sandeep Kumar Nayak is with Dept. of Computer Science & Application, Integral University, Lucknow-UP, India-226026 (e-mail: [email protected]). Raees Ahmad Khan is with Dept. of Information Technology, Babasaheb Bhimrao Ambedkar University (A Central University), Lucknow-UP, India-226025. Mohd. Rizwan Beg is with Dept. of Computer Science & Engineering, Integral University, Lucknow-UP, India-226026. DOI: 10.7763/IJIET.2012.V2.195 Mitigation Algorithm TABLE I: SEVERITY AND PRIORITY LEVEL AND THEIR COMBINATION 521 International Journal of Information and Education Technology, Vol. 2, No. 5, October 2012 B. Requirement Defect Description Requirement defects must be contained in a tabular form within the database which may follow a template of specific attributes, (TABLE II) such as: TABLE II: DEFECT TEMPLATE WITH SPECIFIC ATTRIBUTES Defect Position Defect Indicator Defect Cause Defect Mitigation Cost Defect Severity Defect Priority Defect Definition Function Requirement Functional Actor Missing Inadequate Requirement Collection Effort & time taken in defect identification & Mitigation Critical (S1) Urgent (P1) a) Actor executes the operational Task. b) Mitigating action required immediately. Similarly, the number of mitigated defects (MD) may be assessing through the number of non mitigated defects so the percentage also. The Significance Level of mitigated defect may also be drawn with the help of below given two equations (1) & (2). Above mentioned specimen in the template is given only for one type of defect within functional requirement domain. Here, stored defect is assigned severity and priority for further mitigating action. C. Mitigation Algorithm In our previous study we identified many of the requirement type in the requirement document but due to specific elaboration here only five vital requirement types and respective defects is taken as in fig 2. The mitigation variables with respect to requirement defects are taken for fixing the defects. MD = N – NMD Significance Level = MD / N (1) (2) MD: Number of Mitigated Defects N: Total Number of Identified Defects NMD: Number of Non Mitigated Defects After the assessment of significance level of overall requirement document the mitigating action as well free wheel assembly process will stop working. E. Reliable Requirement Specification The mitigation process in this study has limitations to evaluate whole requirement defect. Several requirements are bounded for self efficacy completely those are depends on severity and priority of respective defect. In this reference, the mitigation algorithm may play a vital role to examine the requirement defect as well as for implementation for mitigation and so forth the Reliable Requirement Specification may deliver. This reliable requirement document may contain in specified storage place. III. CONCLUSION AND FUTURE WORK Requirement defect mitigation and its Reliability assessment against quality software entails recording of defects within the Requirement Defect database and assigns their Severity & Priority level. Therefore this study exposed the process to analyze requirement defects and their mitigation through comparison of defects and their equivalent mitigation variables through mitigation algorithm. Through mitigation algorithm half of the overall defects may be mitigated in the first pass and in second pass half of the rest part and if third pass is needed then few of the residue defects will be mitigated. Our future work is to implement and validate our framework to RRS and this mitigation process with algorithm so as to show its usefulness in the software industry for developing reliable software. Structure as an array A (m) & B (n) respectively. This algorithm is working in three phases, Phase 1: This will match the requirement defects and respective mitigation variables under requirement type (such as: RS matches with RSM). Phase 2: After phase 1individual defect will search its respective mitigation variable under specific requirement type. Phase 3: In this phase mitigation variables may perform three tasks (fix up, fix later or no action). D. Reliability Assessment and Process Termination As per the definition of reliability, R (t) = 1-F (t); F (t) is the probability of function failure during time t. [7], [8]. 522 International Journal of Information and Education Technology, Vol. 2, No. 5, October 2012  Redefinition of Product details (dm11)  Correction in definition of product behavior, mission, business cases (dm12)  Inject clear & complete product needs, goals, objectives (dm13)  Provide required Operational activity & interfaces (dm14)  Input data repository missing  Inconsistency of data naming  Precondition detail missing  Input data dictionary not defined  Creation of input data repository  Inject agreeable & compatible naming for input data  Provide prerequisite dependent input requirement  Give details of input data dictionary OUTPUT SECTION (OS)  Output data sink missing  Precondition detail missing  Input data dictionary not defined  Missing detail of expected results  Give details of output data storage place  Inject agreeable & compatible naming for output data  Provide prerequisite dependent output requirement  Provide expected outcome of the project  Condition and environment detail missing  Limited cross functional data link  Improper partitioning of modules  Unclear Resource allocation/reallocations  Provide specific environment requirement limitation  Specifies requirement limitations for cross functional activity  Provide criterion for module partitioning  Clear allocation/reallocations of Resources  Actor and its role missing  Operational component missing  Component name & State missing  Casual & cross dependent defects of operations  Name of operational actor, its roles & responsibilities must deliver  Provide all functional components detail  Specify the names & stages of functional component  Clear declaration of cross dependent operations FUNCTIONAL INPUT SECTION (IS) REQUIREMENT SCOPE (RS)  Incorrect portrayal for Product (d11)  Business Case, behavior or Mission not defined (d12)  Unclear needs, goals, objectives (d13)  Operational Concepts & interface description missing (d14) REQUIREMENT Mitigation Variables BOUNDARIES (RB) Expected Defect COMPONENT (FC) Requirement Type Fig. 2. Expected requirement defect and mitigation variables [7] REFERENCES [1] [2] [3] [4] [5] [6] [8] E. Hossain, M. A. Babar, H. Y. Paik, “Risk Identification and Mitigation Processes for Using Scrum in Global Software Development: A Conceptual Framework,” 16th Asia-Pacific Software Engineering Conference. IEEE, pp. 457-464, 2009. T. J. Wilmering, “Careful What You Wish For – Risk Mitigation for Unplanned Behaviors in Distributed Diagnostic Software Systems,” IEEE; 137-146, 2007. B. Shahzad and A. S. Al-mudimigh, “Risk Identification, Mitigation and Avoidance Model for Handling Software Risk,” Second IEEE International Conference on Computational Intelligence, Communication Systems and Networks, pp. 191-196, 2010. R. Thakurta, R. Roy, and S. Bhattacharya, “Impact of Requirements Discovery Pattern on Software Project Outcome: Preliminary Results,” 42nd Hawaii International Conference on System Sciences. IEEE, pp. 01-06, 2009. S. K. Nayak, R. A. Khan, R. Beg, “Reliable Requirement Specification: Defect Analysis Perspective,” presented at 4th International Conference on Recent Trends in Computing, Communication and Information Technologies Springer – LNCS in CCIS, pp. 740-751, 2011. S. K. Nayak, R. A. Khan, R. Beg, “Requirement Defect Identification And Their Mitigation Through Severity And Priority,” International Conference on Communication and Electronics Information.Thomson ISI, 2012. S. Xu, “An Accurate Model of Software Reliability,” 13th IEEE International symposium on Pacific Rim Dependable Computing, pp. 77-84, 2007. S. Xu, “Reconsideration of Software Reliability Measurements,” 16th IEEE Asian Test Symposium, pp. 159-162, 2007. Sandeep Kumar Nayak is an Assistant Professor in Department of Computer Science & Application, Integral University, Lucknow – Uttar Pradesh (INDIA) Sandeep Kumar Nayak did MCA from Uttar Pradesh Technical University & pursuing Ph.D. (Information Technology) from Babasaheb Bhimrao Ambedkar University (A Central University), Lucknow - Uttar Pradesh (INDIA). He has published six research papers in reputed and indexed International conference proceedings. He is member of some professional bodies. Raees A. Khan is an Associate Professor and the Head of Department of InformationTechnology, BBA University, Lucknow (INDIA) Dr. Raees A. Khan done MCA from Punjab University & Ph.D. (Computer Science) from Jamia Millia Islamia ( Central University), New Delhi. He has written one book and coauthored one book, published numerous articles, several papers in the National and International Journals and conference proceedings. The area of expertise are Software Quality Assurance, Software testing, Software Security. He has written two projects on Software Security. He is a member of various professional bodies. 523 International Journal of Information and Education Technology, Vol. 2, No. 5, October 2012 Prof. Md. Rizwan Beg is M.Tech & Ph.D in Computer Sc. & Engg. Presently he is working as Professor & Head Deptt. Of Computer Sc. & Engineering. and Information Technology, He is having more than 16 years of experience which includes around 14 years of teaching experience. His area of expertise is Software Engineering, Requirement Engineering, Software Quality, and Software Project Management. He has published more than 40 Research papers in International Journals & Conferences. He is member of large member of International professional societies & also member of Advisory Board for various institutions in India. 524