A Comprehensive Evaluation of the System's Quality - Report Example

? QUALITY and Introduction The field of computer science comprises of among other items software developments. This report will present a review on literature relating to software development process and the various software products that exists. The report will also involve a comprehensive evaluation of the system's quality including stating the differences that exist as well as the arguments made by authors previously researching about the same. The researcher’s ideas and logical conclusion will be included in the report during the final analysis Software Process Definition, Evaluation and Improvement Armbrust et al (2012) describes software process as an activity oriented on set goals, which are relative, to the engineering of software development. Examples of such processes include product creation, system testing, code module measurement, project planning and experience packaging for use in other projects to be implemented in the future. They have also described some of the characteristics that identify software processes. Armbrust et al (2012) state that software processes are derived from the real world. The processes can be performed either by humans or machines or by both of them. Human performance is referred to as enactment while machine performance is referred to as execution. The processes can be refined or transformed into sub processes. The sub processes are capable of being refined. Finally, the processes consume further products so as to enable them transform input products into multiple output products. Acuna et al (2000) describe a software process as activities that are set in a partially orderly manner with the aim of managing, developing and maintaining software systems. The process is based on the process of construction and not the end product. Many organizations define their own means of producing software. Evaluation of software processes related to analysis of activities that an organization carries out in order to develop software or softwares as end products. The idea is that the quality of the final product, which is the software, is directly proportional to the quality of the development process. The aim of carrying out software process evaluation is to improve the production (cost and quality). The process of evaluation brings into knowledge standards for assessing the quality of software development (Acuna et al 2000). There are two methods that are popularly used to evaluated software process: software capability evaluation and ISO/IEC 15504. The SCE was developed by the software engineering institute with the purpose not just to evaluate for quality but for purposes of selecting suppliers, monitoring process and internal evaluation. The method focuses on analysis of the way certain key areas are implemented and institutionalized. The method analyses if the software processes adopted by a given organization are fully satisfying the requirements that are usually articulated in the yardstick (Armbrust 2012). The method comprises of three stages or phases: plan and preparation, conduct evaluation and reporting of results. Conduct evaluation involved visiting of the organization being evaluated by the evaluation team. The method incorporates CMM as referencing model. CMM describes various maturity levels that represent an ordinal scale used to rate the development process. The maturity levels are related to the evolution of the process to the end. The fist level is the initial level. This level represents the ad hoc stage, that is, stage that is not managed and unpredictable (Armbrust 2012). The second level is known as repeatable. The level is intuitive in nature. The processes are basically managed and there is the capability of repeating some projects. The third level is known as the defined stage. It is qualitative in nature. The processes are well defined and institutionalized. The fourth maturity level is known as the managed stage. The level is marked by quantitative analysis that amounts to measures and controlled processes. The last level is the optimized level where the processes are gradually and continuously improved (Wilson 2001). ISO/IEC 15504 is termed as a framework in which the organization’s software processes are assessed with the intentions and motives of improving the process or determining the capabilities of that process. This framework uses reference models for assessing the process. The framework sets the minimum requirement set for performance of an assessment. The results will, therefore, be assumed to be impartial, repeatable, objective, consistent and comparable with future results (Wilson 2001). The framework incorporates 5 levels namely performed, managed, established, predictable and optimizing. The first level measures the process performance and process outcomes achievement extent. The second level involves work product and performance management. It qualifies the extent to which management of the process has produced work products with proper documentation and verification. The third level qualifies the process definition and resources. The fourth incorporates process control and the final level is a call for continuous improvements (Wilson 2001). Software process improvement describes various measures an organization takes to improve the development of the process. Improvement comes after the evaluation process. Improvement is termed a gradual process and not one step activity. Evaluation and improvement of software processes is recommended to be on a continuous basis due to the unpredictable, unstable and ever changing nature of software development. SEI has improvised an improvement model labeled IDEAL. The acronym represents imitation, diagnosing, establishment, acting and finally leveraging (Wilson 2001). The initiation stage relates to the period managers realize the process needs improvement. The diagnosing stage related to setting a baseline or rationale for the current state of the process. The establishing stage relates to setting of goals. The acting stage establishes solutions to the given state. The final stage involves a current analysis of the activities of cycle in an effort to prepare for the next cycle. The level incorporates revision of goal and verification of resource commitments (Wilson 2001). Software Product Evaluation and Certification Evaluation of a product can be based on four items, that is, the context, inputs, process and products. Under this context, the environment that hosted program development and operations is analyzed. Some of the questions answered in this segment regarding the program or software related to the goals of the program. The questions seek answers on whether the program goals are congruent to the organizational goals. Also asked is whether the technical staff is allowed to participate in the improvement processes. Questions regarding the quality of the environment, definition of the processes and the detailed levels of those processes are asked (Wilson 2001). Other questions include whether the program is tailored to the needs of the company and whether realistic assessments of the pay-back period were done. Under the inputs category, factors and resources that were applied in the program development are assessed. Questions asked relate to whether the program was: properly resourced, staffed by people of high caliber and respect, for instance, IBM, assigned an appropriate number of persons. The training of the program is also questioned (Armbrust 2012). Under the process framework, the method that was adopted in developing, implementing and maintaining the product is assessed. Failure of a program can be attributed to ineffective implementation and lack of change in the management. The first category under the process framework is the process motivation and objectives. The means of promotion of the product is assessed, for instance was it promoted through encouraging ideas exchange or through publication of success stories, was the plan of program implementation in the firm published? (Wilson 2001). The second category is the process responsibility and the software process improvement team. It is required that the team be independent of the developers. Clear responsibilities should be assigned. The third category is the process improvement. It is required that the initial processes be defined. The mechanisms to be adopted in changing or manipulating the program should be orderly and a description of the methodology formulated to avoid errors. Questions asked relate to whether objectives and capabilities that would enable the users to explain phenomena and events relating to the program are provided (Wilson 2001). The last category is the process framework relates to training and awareness. An example of the question asked is whether there was adequate training carried out and whether the processes being improved were made public to everyone involved. Under the Product framework, questions asked during the evaluation process related to the end product. Were the improvement processes defined? Is the program providing the benefits anticipated at each level of management audience? Was the feedback provided to the staff? Is the improvement process flexible to enable further changes in the future? Software certification is done once the program has been tested and termed credible. There are various tools that are applied in testing the software. Also, some institutions of international standards have been set with the aim of certifying the software (Wilson 2001). Methods and Tools for Software Quality Management The concern, in this case, is to ensure the level of quality assured for a given software product is achieved. Management implies that quality standards or benchmarks are defined. The procedures that will ensure that standards set are followed should also be defined. The term quantity is used to imply a product that meets the demand specifications. The customer satisfaction is one measure of a quality product. Customers demand for efficient and reliable systems whereas the developer defines quality as a product that can be maintained and reused. Quality management involves undertaking various activities as part of achieving a quality product (Huang 2012). The role of software quality management is to enforce achievement of the required quality levels of a particular software product. Quality management encourages the company to adopt a quality culture and ensures every employee views quality achievement as their responsibilities. It also ensures that no gaps will emerge in case the team members involved with the development if the product change positions within the organization. Software quality management eliminates any fault that may arise in the course of developing a product. This is done through preventing or avoiding the occurrence of fault in the process as a result of proper development. Managers are responsible for quality assurance (Mendoza et al 2002). This means that procedures and standards that define the quality of a product in a given organization must be established. Software quality assurance revolves around actions that are systematically planned and designed in order to equip the software developers with adequate confidence. Confidence will be developed if the product conforms to the requirement or procedures of software development. Quality assurance, therefore, is a broad activity comprising of the techniques and methodologies that assess the process of developing software. It also comprises of the technologies and other tools that ensure the developed software is of good quality. Under quality assurance, knowledge of best practices is incorporated in the development of software. The managers are also responsible for quality planning. This involves making a selection of the most appropriated standards and procedures and tailoring them to ensure they are in proportion with the particular software project. A quality plan is written relative to each project with the aim of declaring that the project is committed to following the standards, procedures, regulations and tools in the course of developing the software. That plan also comprises of the quality goals expected to be achieved as well as the anticipated risk and mitigation techniques or rather risk management tools (Mendoza et al 2002). The managers carry out quality control. They have the responsibility of ensuring the development team of a specific software product puts to action or implements the standards and procedures that were formulated during quality planning. The aim is to ensure the software quality assurance and quality planning is adhered to by the team developing the software (Sabharwal 2008). Some of the activities included in this quality layer include explaining to the team ways of producing artifacts or documentation technique. The team is also made aware of the ways of conducting processes relating to standards, for instance training them on quality reviews. The management will be involved in performing in-process reviews on quality in order to evaluate, validate and confirm artifacts. Validation ensures procedures tools and methods usage is improved on a gradual and continuous basis. It involves the use of two approaches, quality reviews and software assessment and measurement (Mendoza et al 2002). There are specific tools that are put in place to support quality management of software. ISO 9000 is used as a benchmark for quality management. It comprises of internationally set standards. It is required that these quality standards are documented in every organization as a manual. Customers demand that suppliers of various products including software to be ISO 9000 certified. Another tool used in quality management is the squid approach. (Boegh et al 2000).This approach of quality management recommends definition of requirements relating to product quality. These targets are then pursued during software development where the internal quality characteristic targets are defined and monitored. According to this approach, relationship between internal and external characteristics is established with reference gained from past software development projects. This experience is also adopted when assessing the quality procedures feasibility prior to commencing a project. This model provides an organized criterion for defining, identifying and comparing quality measures (Boegh et al 2000). Other tools used in software quality management include the configuration and problem management and testing software. An example of testing software is Programming Research QA C++ and Parasoft Jtest. Borland StarTeam and Lucent Technologies Sablime are examples of tools for configuration management (Sabharwal 2008). Quality Metrics Metrics are defined as measures stated in terms of quality or quantity. It is used to capture performance of an activity relative to the given standard for carrying out that activity. Metrics are used for comparisons and supporting a business strategy. Any type of measurement that denotes as a system or process or document relating to software is known as software metric. Metrics are also for predicting product attributes and controlling development processes. The diagram below represents a control metric ((Mendoza et al 2002). When a developer uses metrics, various assumptions are taken into considerations, for instance, it is assumed that the software product is measurable. It is also assumed that there exist a known, validated and formalized relationship between the item being measured and the expectations of that measurement. The final assumption is that there exist difficulties in relating what item can be measured to the quality attributes that are desirable (Mendoza et al 2002). Dynamic metrics are related to attributes of software quality in a close range and make it easy to measure response time and failure extent. Static metrics are related to the software quality attributed indirectly. Statics are incorporated when deriving relationships between metrics and quality attributes. Metrics are termed effective if they clearly define performance in a quantifiable framework and if they allow for action based responses if the performance is not accepted. Quality metrics are used for spotting trends in performance, comparing alternatives and predicting performance (Mendoza et al 2002). Building Quality into Software Products Sutherland (2010) attributes technology overruns to late discovery of any defects of the product. He advocates for solution delivery rather than service delivery mindset when developing software products. There are two ways in which quality can be added in the software product. The first method is through detecting defects. He has differentiated the traditional and the modern ways of detecting defects. According to the traditional ways, developers passed the build code to testers who executed predefined tests against the build. This only helped in discovering defects after the facts, resulting to quality added to the solution. It is recommended that the groundwork for resolving defects to be conducted early when formulating requirements and during designing of the product. When testing is done on performance, integration and security, defects are discovered very late when most components are either completed or are close to completion. Quality can also be built through preventing the expensive defects from emerging in the requirement and design stages. The common observed trend in project management is adopting three test cycles. When this technique is adopted, reworks and re-tests that emerge, as a result, cause testing to extend even to the terminal stages. The quality assurance costs are expected to rise as the testing period is prolonged. The time that testers spend when developing new functionality is lessened (Sabharwal 2008). Sutherland (2010) advocates for a better approach of solving this mystery. He states that the test teams who work under the quality assurance principles should treat all products that are delivered in the course of the projects lifecycle as testable. The codes artefacts and documents should be considered part of the solution. It is considered a value-add activity of high degree when quality is improved through addressing technical and other business risk factors during the early stages of the product lifecycle. When assurance is started on the early stages of he lifecycle, the implication is that quality assurance resources will be engaged at a longer time framework. This will be compensated towards the end of the lifecycle since the workload will be less as a result of fewer defects to be retested. If testing and assuring of products is done earlier in the projects, the likelihood of being surprised by technical issues is reduced, and the project completion time reduced, as well (Sutherland 2010). In brief, there are four steps that can be implemented when building quality. The first is taming the mindset to think of the solution delivery software instead of software development software. This will entail subjecting the entire project artefacts to testing. The second step is identifying the key artefacts that are produced in the course of the delivery lifecycle. This will also entail defining the technical and business risks mitigating criteria. The third step is coaching or mentoring the testers to adapt to the review process put forth. There is need to equip the assurers with proper skill and objectives. The fourth step is recording the outcomes generated from the reviews. Priorities are then assigned to the defects. The record should include the manner in which the defects were discovered and the artefact in which they were found (Sutherland 2010). Quality can also be built through the use of software for detecting of defects. According to Veerachamy (2013) Aspirer’s integrated quality approach can be used to detect bugs during the early stages, remove the risks associated with product release and reduce the reworking costs. This integrated quality approach is implemented in three phases. The first phase relates to understanding and analysis of the requirement. This helps the stakeholders to have a clear picture on the technical architecture and design of the product. In this phase, the stakeholders are presented with the functional specifications requirements by the business analyst the team involved in quality approach is tasked with analyzing the requirements, usability and technical design. Once the analysis is done, the system test suite is derived from the system architecture by the team, who also do the testing of the requirements in order to detect defects in the early stage of product development. The reason for involving the stakeholders is to help reduce defects. The second phase is known as the development phase, where the team tests the new features completed and passed to unit testing. This renders the component ready for integration stage. Defects arising from coding standards, memory leakage, incorrect requirement, naming conventions and implemented logic are reduced in this phase (Sutherland 2010). The final phase is known as the testing phase. The team prepares test suites, which are, reviewed by business analysis. The move is meant to ensure the requirement coverage is 100%. Integration test paves way for regression testing. Testing of all manner, unit, functional, system, regression and system integration and acceptance testing is carried out. This approach detects defects in early stages of the development cycle, reduces development and reworking costs, increases the coverage of tests done and reduces testing participation from other supporting teams (Sutherland 2010). Rapid Application Development and Quality RAD is described as a methodology that an organization adopts with the aim developing quality applications faster in conjunction with minimizing development cost (Richter 2000). A number of techniques are applied in order to achieve that. The techniques include gathering requirements, re-using software components and prototyping. Prototyping includes the creation of a demonstrating result during the early stages of product and refining the product to suit the requirements of one being created. The techniques are normally combined with design schedule that is fast-paced and team communications and reviews that are less formal. Adopting this methodology helps in quality achievement in reduction of cost and improving developer productivity (Richter 2000). RAD automates the coding and design processes. This ensures the development process is more stable and less prone to errors (Richter 2000). The methodology has the capability of implementing change effectively into an application. This relates to new functionality or changed functionality implementation. RAD is also capable of deploying a changed functionality within the application being deployed. Its Uniface functionality is termed compatible with most methodologies relating to the development. RAD is implemented in four stages. The first one is the requirement planning phase. RAD combines the system planning and system analysis elements of a solutions delivery lifecycle. Managers, IT members and other users come to an agreement on the project scope; the business needs the system requirements and constraints. The conclusion of the phase is marked with team agreement on the key issues and authorization from the management to continue (Richter 2000). The second phase, the user design phase is marked by users who develop models and their prototypes through interaction with system analyst. The prototypes make a representation of system processes, outputs and inputs. The RAD team makes use of both joint application development techniques (JAD) and the CASE tools in order to translate the needs of the user into models of working. This phase is marked by a continuous interactive process between the user and the system that gives the user the opportunity to understand and modify a system’s working model. The construction phase relates tasks attributed to the application development and program. The users involved in the rapid application program participate and recommend their opinions regarding improvements or changes. The tasks allocated here include unit-integration, coding, application development and system testing (Richter 2000). Cutover is the last phase of the rapid application development program. In this phase, the final tasks in the solutions delivery lifecycle are resembled and the entire process compressed after comparison with the traditional methods. The tasks that are resembled include data conversion, changeover to a newer system, testing and training of the users. The new system is built after compression after which it is delivered into the operations. In terms of achieving quality of software development, RAD can play a major role in reducing costs, maintaining quality and developing the product faster (Richter 2000). Conclusion Many authors have described software process in terms of the activities undertaken to develop a product. The process is based on the process of construction and not the end product. Many organizations define their own means of producing software. Evaluation of software processes relate to analysis of activities that an organization carries out in order to develop software or software as end products. The idea is that the quality of the final product, which is the software, is directly proportional to the quality of the development process. This report has critically evaluated various concepts that related to software development. This includes analysis of the process evaluation and improvement. The paper has identified various tools or techniques of evaluating and improving software process. The paper has also identified three methods of software quality management. This includes quality assurance, planning and control. A number of tools are used when undertaking quality management of a product. The paper has discussed the quality metrics and most specially majored on the software metrics. The paper has identified four criteria in which quality can be built. Finally, the paper has discussed quality achieved through use of the rapid application development methodology. The methodology has been termed the fasted in developing applications at the lowest cost possible and high quality. Bibliography Acuna, ST, Antonio, A, Ferre, A, Lopez, M and Mate, L 2000. The Software Process: Modeling, Evaluation and Improvement. USA: World Scientific Publishing Company. Armbrust, O, Kowalczyk, M and Soto, M 2012. Software Process Definition and Management. London: Springer-Verlag. Boegh, J, Depanfilis, S, Barbara K and Alberto, P 2000. A Method for Software Quality, Planning, Control and Evaluation. USA: World Scientific Publishing Company. Huang, C 2012. Department of Computer Science. Taiwan: National Tsing Hua University. Retrieved from http://www.hindawi.com/journals/ase/si/274738/cfp/ Mendoza, LE, Perez, MA, Rojas, T and Griman, A 2002, ‘Selecting Tools for Software Quality Management’, Journal of Quality Management, Vol. 4, No. 4, pp. 139-147. Richter H, P 2000. Building Quality into Software: A Guide to Manage Quality in Software Development and Use. United Kingdom: Author House. Sutherland, G 2010. Building Quality into Projects. Retrieved from http://www.bcs.org/content/conWebDoc/38046 Sabharwal, S 2008. Software Engineering. New Delhi: New Age International Pvt Ltd. Wilson, DN, Hall, T and Baddoo, N 2001. ‘Framework for evaluation and prediction of software process improvement success.’ The Journal of Systems and Softwares, pp. 136, 137. Read More