AppDev Pre-Finals PDF

IT1814 Prototyping and Quality Assurance The Software Quality Assurance Software quality is the degree to which a software product meets the gathered requirements. Software quality assurance is a set of activities that define and assess the adequacy of...

IT1814 Prototyping and Quality Assurance The Software Quality Assurance Software quality is the degree to which a software product meets the gathered requirements. Software quality assurance is a set of activities that define and assess the adequacy of software process to provide evidence which establishes confidence that the software processes are appropriate for and produce software products of suitable quality for their intended processes. This is based on the planning and implementation of a series of activities for ensuring quality in the software development process. Many organizations implement software quality assurance to ensure that their software system product is of high quality. Here are some key reasons that drive software quality assurance: Reputation – Software developers and their organizations rely on this. Software bugs can have immediate impacts on clients or customers. Limiting Technical Debt – Poor quality software tends to be expensive to develop and maintain, which can negatively affect organizations or end up maintaining the software in the longer term. These costs are often referred to as “technical debt.” Software Certification – The development and use of the software might require some form of certification, which can often require evidence of the application of various quality control and assessment measures. Legality – There may be overriding legal obligations that apply to organizations that use the software. As such, every practicable measure must be taken to demonstrate that the software system does not pose a risk to its users. Ethical Codes of Practice – In cases where a software system is not covered by software certification and legislation, and where its failure is not necessarily business or safety-critical, there can remain moral obligation to the users. This implies that software engineers should do whatever is possible to maximize the quality of their software and to prevent it from containing potentially harmful bugs. Software Quality Assurance Through Prototyping Software prototyping refers to building software application prototypes which displays the functionality of the product under development, but may not actually hold the exact logic of the original software. A prototype moves the quality assurance earlier and makes it easier. Prototyping software is used to achieve the following: Allow users to evaluate the software system design and how the software actually works. Clarify the functionalities of the software to both users and developers. Reduce cost and time relative to building software product and iterating the process. Reduce the need to recreate the software system due to some gaps on the implementation. Models of Prototyping and Tools Prototyping Paradigms Throwaway Prototyping – This is a relatively fast method of prototyping that focuses on employing prototypes to generate insights about the software design idea. The created prototypes on this paradigm are discarded after testing and after obtaining feedback. This is used in early design stages where the gathered requirements are still unclear. Evolutionary Prototyping – The prototypes on this paradigm are reused after the testing in a way that they are altered according to the test results and then reused in a new test cycle. This evolves to become the end product itself. This is usually used in late development stages where sufficient insides about principle design decisions exist and the prototype addresses technical and long-term use issues. Prototype Fidelity and Prototyping Tools Prototypes can be created in different fidelities. The fidelity of the prototype pertains to how it conveys the look and feel of the final product. It can range from low-fidelity to high-fidelity, which are explained further below. Low-Fidelity Prototyping – Its role is to check and test the visual appearance and user flows of a software. A throwaway prototype can be created in low-fidelity. These are some techniques to create low-fidelity prototypes: o Paper-Based Prototyping – This prototyping technique is used to create a prototype based on hand drawings that represent user interfaces of the software. This allows developers to explore ideas and refine designs quickly. 05 Handout 1 *Property of STI  [email protected] Page 1 of 2  IT1814 o Wireframing – A wireframe is a visual representation of a product page that developers can use to arrange pages of user interfaces. Wireframes are used to create interactive prototypes by linking different wireframes together. Prototyping Tools for Wireframing There are various available tools made specifically for prototyping which are designed to help developers create wireframe prototypes for mobile applications, websites, and computer software. Some of the low-fidelity user interface (UI) wireframing tools that reproduce the experience of sketching an interface mockup using a computer are Balsamiq Wireframes, Axure, MockFlow, and Adobe XD. High-Fidelity Prototyping – High-fidelity prototypes are created when developers have a solid understanding of what they are going to build. They need to test it with the actual users. For example, evolutionary prototypes are created as high- fidelity prototypes. These prototypes are usually created in the form of programming codes and Integrated Development Environment (IDE) software. REFERENCES: Babich, N. (2017, November 29). Prototyping 101: The difference between low-fidelity and high-fidelity prototypes and when to use each [Web log post]. Retrieved from https://theblog.adobe.com/prototyping-difference-low-fidelity-high-fidelity- prototypes-use/ Bahr, B. (2017). Prototyping of user interfaces for mobile application. Cham, Switzerland: Springer International Publishing AG. Galin, D. (2018). Software quality. Concepts and practice. Retrieved from https://books.google.com.ph/books?id=5aNMDwAAQBAJ&printsec=frontcover#v=onepage&q&f=false Walkinshaw, N. (2017). Software quality assurance. Consistency in the face of complexity and change. Cham, Switzerland: Springer International Publishing AG. 05 Handout 1 *Property of STI  [email protected] Page 2 of 2  IT1814 Software Review and Inspection Overview of Software Review and Inspection Software quality assurance is a structured approach to improve software quality. It involves defect prevention, detection, and removal, as well as defect containment activities. Software testing and inspection are the two (2) commonly used methods to detect defects in software, while software inspections and reviews are concerned with the review of software artifacts. Software inspection or software review is a formalized peer review process for detecting and correcting defects or bugs in software artifacts. Software artifacts are any things that have been documented and stored during the software development process, such as requirements document, source code, user documentation, and test plans and test cases. Requirements, design, and other non-executable artifacts cannot be tested by machines and have to be reviewed by humans. With inspection, both requirements and design can be read and analyzed, which do not require the artifacts to be complete or executable. The objective of software inspections is to help developers build quality into the software product. Software Inspection Techniques There are several approaches to software inspections, and these vary in the level of formality employed. There are formal software inspection methodologies that include different formal activities and guidelines. Some of the most well-known software inspection methodologies are the following: Fagan inspection methodology – This methodology was developed by Michael Fagan. The objectives of this methodology are to identify and remove errors in the software products and to identify any systematic defects in the processes that are used to create software products. This process requires that software artifacts be formally inspected by experts independent of the author. These are the following inspector roles that each participant plays as defined in the Fagan inspection process: o Moderator – S/He leads the inspection team and takes care of logistics. o Author – S/He is the creator of the software artifacts under inspection. The author will actively answer all the questions regarding the artifacts during the inspection meeting. The author is responsible for fixing identified defects and bugs in the artifacts. o Reader – S/He is an experienced peer who can be a subject matter expert on the software artifacts under inspection. o Tester – S/He is responsible for writing and executing test cases for the software module or product. The role of the tester is focused on how the product would be tested. The inspection process will also consider whether the software design is correct with respect to the requirements and whether the source code is correct with respect to the design. Refer to Table 1 for the seven (7) activities of the Fagan inspection methodology. ACTIVITY ROLE OBJECTIVE Identify inspectors and roles. Verify if the materials are ready for inspection. Planning Moderator Distribute inspection materials to participants. Arrange meeting place and time. Overview Author Brief participants on information of materials. Participants prepare for the meeting. Preparation Inspectors Checklists may be employed to facilitate the preparation. Read through the deliverables and mark up issues and questions. The moderator sets the time limit for inspection and keeps the meeting focused. Inspection The inspectors perform their roles to find defects. The emphasis is to Moderator/Inspectors Meeting identify as many possible defects, not solutions. Record and classify defects. An inspection outcome is agreed. 06 Handout 1 *Property of STI  [email protected] Page 1 of 4  IT1814 ACTIVITY ROLE OBJECTIVE Continuously improve the development and inspection process. Record the causes of major identified defects. Perform root cause analysis to identify any systemic defect with Process Inspectors development or inspection process. Improvement Determine corrective action to address any systemic defects in the software process. Make recommendations to the process improvement team. The author corrects the defects and carries out any necessary Rework Author investigations. The moderator verifies that the author has resolved the defects and Follow-up Moderator/Author investigations. Table 1. Fagan inspection process Source: Concise Guide to Software Engineering: From Fundamentals to Application Methods, 2017. p. 93 The inspection meeting consists of a formal meeting between the author and the inspectors. It is concerned with finding defects in the particular deliverable and verifying the correctness of the inspected material. INSPECTION TYPE PURPOSE PROCEDURE Requirements Find requirements defects. Inspectors review each page of requirements Confirm if the requirements are and raise questions or concerns. correct. The moderator records identified defects. Design Inspection Find defects in design. Inspectors review each page of design, compare Confirm if the design is correct with it to requirements, and raise questions or respect to requirements. concerns. Code Inspection Find defects in the source code. Inspectors review the code, compare it to Confirm if codes are correct with requirements and/or design, and raise respect to design and/or questions or concerns. requirements. The moderator records identified defects. Test Plan Find defects in test cases or test plan. Inspectors review each page of test plan or Inspection Confirm if test cases can verify the specification, compare it to requirements design and requirements. and/or design, and raise questions or concerns. The moderator records identified defects. Table 2. Inspection meeting Source: Concise Guide to Software Engineering: From Fundamentals to Application Methods, 2017. p. 98 The inspection meeting consists of a formal meeting between the author and the inspectors. It is concerned with finding defects in the particular deliverable and verifying the correctness of the inspected material. Structured Walkthrough – It is a peer review in which the author of a deliverable, such as a document or source code, brings one (1) or more reviewers through the deliverable. Its objectives are to get feedback from the reviewers on the quality of the document or code and to familiarize the review audience with the author’s work. The walkthrough includes several roles, namely, the review leader, the author, the scribe, and the review audience. These are the following steps of a structured walkthrough: Step 1: The author circulates the deliverable, either physically or electronically, to the review audience. Step 2: The author schedules a meeting with the reviewers. Step 3: The reviewers familiarize themselves with the deliverable. Step 4: The review leader chairs the meeting. Step 5: The author brings the review audience through the deliverable, explains what each section aims to achieve, and requests comments from them as to its correctness. 06 Handout 1 *Property of STI  [email protected] Page 2 of 4  IT1814 Step 6: The scribe records errors, decisions, and any action items. Step 7: A meeting outcome is agreed, and the author addresses all agreed items. If the meeting outcome results in a second review, then go back to Step 1. Step 8: The deliverable is circulated to reviewers for sign off, and the reviewers sign off indicating that the author has correctly amended the deliverable. Step 9: The author or project leader stores the comments and sign-offs. The objective of software inspection is to build quality into the software product. It is more cost-effective to build quality during software development process rather than adding it later. The effectiveness of inspection is influenced by the expertise and experience of the inspectors, adequate preparation and the speed of the inspection, and compliance to the inspection process. Code Reviewing Techniques Code reviewing or inspection is the act of systematically convening with fellow programmers to check each other’s code for faults to ensure the code meets quality standards. Code reviews may focus on coding standards only or as well as finding defects in the software code. The identified issues during the review are recorded and may include items requiring further investigation. There are two (2) families of approach to identify defects in source codes: Tool-Driven Code Review – This approach uses automated code analysis techniques that can pick out problematic patterns within the source code. The source code analysis drive automated code reviews. The code checkers are often built-in into Integrated Development Environments (IDEs). The IDEs automatically assess the codes to identify code problems. For example, if a variable is declared but never used or used without being initialized, this is commonly flagged up without the developer having to invoke a tool explicitly. The nature of the code problems that can be identified varies from one (1) tool to another and depends to an extent on the nature of the underlying programming language. Automated tools are especially good at identifying problems that are relatively localized to a single method or class. Developer-Driven Code Review – Some properties of code quality are difficult to assess automatically. In this approach, the developers themselves reviews the code to pick out problems. Then, the reviewers manually assess source codes before deployment. This is usually a two-step process where the developers have to understand the program first so that they can form an opinion of its implementation and design. Only then they can properly evaluate the program. When evaluating the program, the specific goals depend on several factors. Developers may focus on evaluating the security and maintainability of the codes. Modern Code Review The modern code review is a lightweight variant of the code inspections because it does not rely on face-to-face meetings. This operates on tools and development processes. The specifics of modern code review vary from one (1) development context to another. These also often depend upon the nature of the development process, the makeup of the development teams, and the workflow required by the associated code review tools used. These are the two (2) version repository-based tools used to compose lightweight code reviews. Tool-Driven Code Review – To enable code reviews, integrate reviewing tools such as Google’s Gerrit and Microsoft’s CodeFlow with version repositories to act as gatekeepers to commits. A repository is a central file storage location. It is used by version control systems to store multiple versions of files that can be accessed by multiple users. Figure 1 illustrates a typical modern code review workflow using a code reviewing tool. 06 Handout 1 *Property of STI  [email protected] Page 3 of 4  IT1814 1. The developer checks out a version from the repository and makes changes. 2. This change is then submitted for review. This is often automatically initiated when the developer tries to push his/her change to the central version repository. 3. Before the commit can be finalized, the patch submitted by the developer is subject to review by a pool of reviewers. 4. If the reviewers accept the patch, it is then passed to someone who verifies it by testing it, and finally commits the reviewed, verified code fragment to the version repository. Figure 1. Typical modern code review work-flow using a code reviewing tool Source: Software Quality Assurance: Consistency in the Face of Complexity and Change, 2017. p. 129 Pull-Based Development – This development approach enforces modern code review and does not use code reviewing tools. This revolves around a mechanism known as a “pull request.” Refer to Figure 2 for the illustration of the flow of a pull-based development. 1. A developer who does not have the privileges to push his/her changes directly to the central repository takes a clone of the code from the repository then makes changes. 2. The developer then submits his/her proposed changes to the repository as a pull request. 3. A developer with appropriate privileges (referred to as “integrator”) examines the proposed changes, integrates them with their own clone of source code, and makes the commit. Figure 2. Pull-based development workflow Source: Software Quality Assurance: Consistency in the Face of Complexity and Change, 2017. p. 130 REFERENCES: Ming Zhu, Y. (2016). Software reading techniques. Twenty techniques for more effective software review and inspection. Retrieved from https://books.google.com.ph/books?id=MTCIDQAAQBAJ&printsec=frontcover#v=onepage&q&f=false O’Regan, G. (2017). Concise guide to software engineering. From fundamentals to application methods. Cham, Switzerland: Springer International Publishing AG Walkinshaw, N. (2017). Software quality assurance: Consistency in the face of complexity and change. Cham, Switzerland: Springer International Publishing AG. 06 Handout 1 *Property of STI  [email protected] Page 4 of 4