Software Quality – a software product meets the gathered requirements.
Software Quality Assurance – 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.
o Reputation – software developers and their organizations rely on this. Software bugs
can have immediate impacts on clients or customers
o 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. “technical debt”
o Software Certification – use of the software might requirement some form of
certification, require evidence of the application of various quality control and
assessment measures.
o Legality – overriding legal obligations that apply to organizations that use the software.
Every practicable measure must be taken to demonstrate that the software does not
pose a risk to its users.
o Ethical Codes of practice – software system is not covered by software certification and
legislation. 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 prototyping – building software application prototypes which displays the
functionality of the product under development.
o Allow users to evaluate the software system design and how the software actually
works.
o Clarify the functionalities of the software to both users and developers.
o Reduce cost and time relative to building software product and iterating the process.
o Reduce the need to recreate the software system due to some gaps on the
implementation.
Throwaway Prototyping – relatively fast method of prototyping that focuses on employing prototypes
to generate insights about the software design idea.
o Low-Fidelity Prototyping – to check and test the visual appearance and user flows of a
software. A throwaway prototype can be created in low-fidelity.
Paper-based Prototyping – used to create a prototype based on hand drawings
that represent user interface of the software.
Wireframing – visual representation of a product page that developers can use
to arrange pages of user interface. ( Balsamiq Wireframes, Axure, Mockflow,
Adobe XD.
Evolution Prototyping – paradigm is reused after the testing in a way that they are altered according to
the test results and then reused in a new test cycle.
o High-Fidelity Prototyping – created when developers have a solid understanding of
what they are going to build. They need to test it with the actual users.
Software Quality Assurance – structured approach to improve software quality. (Defect prevention,
detection and removal, defect containment activities.
Software inspection/review – formalized peer review process for detecting and correcting defects or
bugs in software artifacts.
o Software artifacts – any things that have been documented and stored during
the software development process. (Documents, code, test plans/cases).
Fagan inspection methodology – developed by Michael Fagan, identify and remove errors in the
software products and to identify any systematic defects in the processes that are used to create
software products.
o Moderator – leads the inspection team and takes care of logistics.
o Author – creator of the software artifacts under inspection. Author will actively
answer all the question regarding the artifacts during the inspection meeting.
o Reader – an experienced peer who can be a subject matter expert on the
software artifacts under inspection.
o Tester – responsible for writing and executing test cases for the software
module or product
Structured walkthrough – a peer review in which the author of a deliverable, document or source code,
brings one or more reviewers through the deliverable.
Code reviewing/inspection – act of systematically convening with the fellow programmers to check
other’s code for faults to ensure the code meets quality standards.
o Tool-Driven Code Review – use of automated code analysis techniques that can pick out
problematic patterns within the source code.
o Developers-Driven Code Review – some properties of code quality are difficult to asses
automatically.
Modern Code Review – lightweight variant of the code inspections because it does not rely on face-to-
face meetings.
o Tool-Driven Code Review – enable code reviews, integrate reviewing tools such as
Google’s Gerrit and Microsoft’s CodeFlow with version repositories to act as
gatekeepers to commits.
o Pull-Based Development – approach enforces modern code review and does not use
code reviewing tools. This revolves around a mechanism known as a “Pull request”.