Software Quality Assurance Capability Level 2 and Work Products for Requirements Elicitation Process - Case Study Example

Table of Contents Table of Contents 2 Executive Summery 3 3- Software quality assurance 4 4- Software quality assurance Capability Level 2 5 5- Work Products for Requirements Elicitation process 5 6.1- Performance management attribute 8 6.1.1- Additional work products 8 6.2- Work product management attribute 9 6.2.1- Additional work products 10 7- Conclusion 11 8- References 11 1- Executive Summery This paper presents the detailed analysis of the work products relevant to the assessment of capability level 2 in the requirements elicitation process. In this research I will present the detailed analysis of the work products that would demonstrate complete achievement of the defined outcomes for the requirements elicitation process. I will assess and elaborate the selection of each work product. This research will also identify the process outcomes that each work product addresses. 2- Introduction Nowadays we deal with a fundamental instant in the world of technology based standards, one that also engages the worldwide ecology and economy. The need to renovate our economic structure and put into practice means to protect as well as preserve the environment has acknowledged many times in the technical society a moment of simplicity by regard to the role standards have to play in these times (Laudon & Laudon, 1999). (Lane, 2009) outlined the main emerging awareness that as the technical standards technology world has functioned effectively enough for decades, the structure is in risk of being hijacked, broken, and exploited through political and partisan legal maneuvering. A lot of people now identify prospect to restore belief and put into practice steady and persistent safeguards in the standards society (Lane, 2009). This research will assess the software quality assurance capability level 2 in the requirements elicitation process. In this reassert I will assess a set of work products that would demonstrate complete achievement of the defined outcomes for the requirements elicitation process. 3- Software quality assurance According to American Heritage Dictionary “quality is a feature or element of something.” As an element of an item, quality refers to measureable features the things we can judge against to recognized standards for instance length, color, electrical properties etc. Software quality assurance comprises auditing and reporting activities of management. The purpose of quality assurance is to offer management with the data essential to be knowledgeable about product quality, by this means getting insight and assurance that product quality is meeting its objectives (Pressman, 2001, pp. 195-196). Demiriirs et al, (1998) outlined the main evolution of the software quality assurance in his research. Since 1980s a huge amount of software process enhancement/improvement efforts have been started globally to augment quality as well as efficiency while minimizing cost. Different quality assurance models are being utilized depending on the marketplace objectives of the organizations (Demiriirs, Demiriirs, Dikenelli, & Keskin, 1998). The term of CMM or Capability Maturity Model has established by Paulk et at (1993) is well accepted among the corporations that target the United States marketplace (Lane, 2009). Alternatively for European technology marketplace certification to IS0 9001 is the most frequently established quality program. Experience by means of both CMM and IS0 9001 has shown that less software associations by means of 15 or less developers have a number of complexities in putting these models. The primary difficulty is the models’ inherent theories on the business size. The quality applications that require to be installed necessitate numerous groups operational in parallel on diverse issues. In small corporations, the similar group of people has to pass these tasks consequently overloading the staff. Alternatively both CMM and IS0 9001 be unsuccessful to profit from the “smallness” which frequently means fast reaction time, flexibility and improved communication. Regardless of these complexities, the amount of small associations started process improvement is growing as the return of investment arrived in the shape of a huge marketplace (Demiriirs, Demiriirs, Dikenelli, & Keskin, 1998). 4- Software quality assurance Capability Level 2 The second level of the software quality assurance capability is about the managed process. Managed process is regarding the implementation performed process in a managed fashion (monitored, planned, and adjusted) as well as its work products are properly controlled, established and maintained (ISO/IEC-15504, 2004). Software quality assurance capability level 2 involves the handling of the managed process that convenes recognized performance aims, objectives, and produces work products that accomplish expressed quality needs contained by defined timescales as well as resource requirements (Rout, 2009). The fundamental elements of Software quality assurance capability level 2 is the management of its performance as well as the explicit attention on work product organization. The vital function that practical management of these two features of the process accomplishes is to augment assurance that what is formed and what is desirable plus that the procedure operates in a more predictable way (Rout, 2009). 5- Work Products for Requirements Elicitation process Requirements elicitation is a course of action of taking the system requirements through examination of existing systems, communication with possible users and actions, job analysis and so on. This process can also engage the development of one or more system models and prototypes. These assist the analyst recognize the system to be developed (Sommerville, 2004, pp. 97-98). The main work products for requirements elicitation process will be described here. These work products will be regarding the requirements elicitation process. The following work products are identified below (ISO/IEC-15504, 2006); Defines the functional and non-functional requirements for work products This work product will help in recognizing the main needs and requirements for the system development. Here we need to assess the functional and non-functional requirements. Outcomes for the Requirements Elicitation process- [Analysis report] Explain requirements to distribute, develop, and maintenance This work product is aimed at presenting the main system requirements for its generic, development, distribution, and maintenance. The definitions of these aspects provide us a better overview of the main system development aspects. This work product is really essential regarding the system development because it provides us the basic information of the system type and its target deployment area. Outcomes for the Requirements Elicitation process- [Customer requirements] Provides proof of meetings, communication, reviews and corrective actions for taking requirements During the requirements elicitation process we need to assess the main requirement for the system. These requirements are attained through the meetings, communication, reviews and interviews to the system owners or vendors. The book keeping and recoding the whole record is really essential because it offers us a proof for the established system requirements and also helps in system change management. Outcomes for the Requirements Elicitation process- [Customer requirements, Communication record] Discovers resources, tasks, infrastructure and responsibilities desired to perform the process: The assessment of the system resources, tasks, infrastructure and responsibilities is really necessary because it offers us a great help for the planning and developing budgetary plans for the system development. Outcomes for the Requirements Elicitation process- [System architecture design] Identifies stakeholders as well as communication mechanisms to be utilized The discovery of main stakeholders is also a main task in this area. This helps in defining the system scope and user operations. This definition helps us in a better establishment of the system main functionalities, interface, and operational structure. Outcomes for the Requirements Elicitation process- [Communication record, Customer requirements] Explain assumptions plus constraints measured in defining the objectives In requirements elicitation process, we also need to discover the main assumptions and constraints in defining the system objectives. This helps us regarding the enhanced management of different complexities and hurdles in the way of the system development. Outcomes for the Requirements Elicitation process- [Analysis report] Defines aims to carry out the process This area is aimed at defining the main process we will perform for the definition of the main processes that we are aimed to carry out. In this way we are greatly helped to develop the list of main system functionalities. Outcomes for the Requirements Elicitation process- [Analysis report, Progress status record] Incorporates milestones and timetable to generate the work products of the process In this area we establish the main milestones and timetable to generate the work products of the process. This regards the requirements elicitation process because consult the system owners for the decision of main date and milestones for the system deployment and development. Outcomes for the Requirements Elicitation process- [Progress status record] Describes quality control actions required to handle the quality of system Another main factor of the requirements elicitation process is the definition of the quality related aspects for the system. In this scenario we define the system quality related aspects that ensure that effective and successful completion of the system. Outcomes for the Requirements Elicitation process- [Customer satisfaction report] 6- Attributes at Capability Level 2 There are two attributes of the capability Level 2, a) Performance management attribute and b) Work product management attribute. The further explanation of each attribute is given below: by (ISO/IEC-15504, 2004). 6.1- Performance management attribute In the attribute of capability level 2 the performance management attribute is a measure of the degree to which the performance of the development is controlled. As a consequence of complete accomplishment of this attribute: we attain objectives for the performance of the procedure, we assess the performance of the development that is monitored and planned; performance of the process is accustomed to convene strategies; authorities and responsibilities for carrying out the process are described, communicated and assigned; here information and resources essential for performing the process are acknowledged, allocated, made available and utilized; interfaces among the concerned parties are directed to make sure both efficient communication as well as also clear obligation of accountability. 6.1.1- Additional work products This section provides additional work products we would require to find or demonstrate achievement of each attribute, and the specific characteristics. I have assessed the overall requirements elicitation process for the capability level 2. Here I have identified the two following given work products. Judge risks connected to fulfillment of defined objectives For this work product of requirements elicitation process for the capability level 2 we need to assess the risks connected to fulfillment of defined objectives. In this way we would be able to judge main risk areas in the initial phase of the system development. Here this risk can be project cost and time related. The better assessment and handling of this risk becomes easier through their initial identification in the requirements elicitation process. Outcomes for the Requirements Elicitation process- [Communication record, Customer requirements] Examine identified risks In this regard we recognize and examine the main risks we are facing regarding the system development. The identified risks in the requirements elicitation process are less reliable to operate on so we need to examine them for their appropriateness and confirmation. For instance we have indentified a cost related risk in requirements elicitation process due to less project cost established by the system vendor; as a result we will assess the entire areas and conformation the realty of the risk. Outcomes for the Requirements Elicitation process- [Communication record, Customer requirements] 6.2- Work product management attribute The second attribute of the capability level 2 is work product management attribute. This attribute is an assessment of the degree to which the work products formed through the process are appropriately managed. As a consequence of complete accomplishment of this second attribute: we would be able to assess the requirements for the work products of the development are defined; here work products are properly documented, identified as well as controlled; the requirements for control and documentation of the work products are described; work products are evaluated in accordance by means of adjusted and planned arrangements, as essential to convene requirements. In this attribute the requirements intended for control and documentation of work products can comprise requirements for the recognition of transforms as well as revision status, for making applicable versions of applicable work products obtainable at points of use and support and re-approval of work products. 6.2.1- Additional work products In the second attribute of the capability level 2 the requirements for the work products to be formed are described. Requirements can comprise defining structure and contents. Quality measures of the work products are recognized. Appropriate approval and review measures for the work products are described. Here requirements for the documentation and control of the work products are described. For instance here we have requirements intended for identification of work products as well as their components, traceability, distribution (ISO/IEC-15504, 2006). I have assessed following additional work products for the second attribute of the capability level 2: Dependencies among work products are recognized and understood In this regard we mainly recognize the main dependencies among work products. The main reason behind this aspect is to assess the main problems that can effect the overall system development and implementation. Outcomes for the Requirements Elicitation process- [Project plan, Communication record, Customer requirements] Requirements for the approval of work products to be controlled are defined In this scenario we develop essential requirements for the approval of work product. In this way we can be able to describe the main system development requirement and vendor satisfaction for it. Outcomes for the Requirements Elicitation process- [Project plan, Communication record, Customer requirements] 7- Conclusion In this research I have presented a detailed analysis of the capability level 2 and its associated attributes. Discussion about requirements elicitation process was also the part of this paper. In this research the main concentration was given on the assessment of the work products in the requirements elicitation process in capability level 2. This analytical research will provide deep insight into the overall analysis of the requirements elicitation process in capability level 2. 8- References 1. Demiriirs, E., Demiriirs, O., Dikenelli, O., & Keskin, B. (1998). Process Improvement Towards IS0 9001 Certification in a Small Software Organization. IEEE , 435-438. 2. ISO/IEC-15504. (2004). Information technology—Process assessment- Part 2: Performing an assessment. AS/NZS ISO/IEC 15504.2:2004 . 3. ISO/IEC-15504. (2006). Information technology—Process Assessment- Part 5: An exemplar Process Assessment Model. AS/NZS ISO/IEC 15504.5:2006 . 4. Lane, G. T. (2009). Best Practices for Standards Communities. Published by the IEEE Computer Society , 86-87. 5. Laudon, K. C., & Laudon, J. P. (1999). Management Information Systems, Sixth Edition. New Jersey: Prentice Hall . 6. M.C.Paulk, Chrissis, M., & Weber, C. (July 1993). Capability maturity model version 1.1. IEEE Sofhoare , 18-27. 7. Pressman, R. S. (2001). Software Engineering: A Practicioners Approach, 5th Edition. London: McGraw Hill. 8. Rout, T. (2009). Software Quality Management. Lecture Notes - Process Definition & Assessment . 9. Sommerville, I. (2004). Software Engineering, 7th Edition,. New York: Pearson Education (Addison Wesley). Read More