FIT3SQA – Software Quality Assurance

Lecture 2

Software Quality Concepts

Use-case Modeling for Requirements

Faculty of Information Technology

Hanoi University
 Software Engineering Problems
• It takes long for software to be developed.
• High development costs.
• Lots of errors are found after software is
delivered to customers.
• Software gets outdated quickly.
• It requires much time and effort to maintain
software.
• It is difficult to measure the quality of software.
 Software Process
• A collection of activities, actions, and tasks that are
performed when some software is to be developed.
– Software process vs process model.
• 5 activities of a generic software process:
– Communication
– Planning
– Modeling
– Construction
– Deployment
 Umbrella Activities
• Activities that are applicable across the entire
software process.
• Typical umbrella activities:
– Project tracking and control
– Risk management
– Quality assurance
– Technical reviews
– Measurement
– Configuration management
– Work product preparation and production
 General Principles
• A software system exists for one reason: to
provide value to its users.
– All other principles support this one.
 General Principles
• KISS: Keep It Simple & Stupid!
– To make software that is understandable by others.
– To make software that is more maintainable and less
error-prone.
– Simple does not mean “quick and dirty”.
– Features should not be discarded in the name of
simplicity.
 General Principles
• Maintain the Vision
– A clear vision is essential to the success of a software
project.
• Emphasizes the role of a software architect.
– Who is a highly skilled, experienced software
engineer.
 General Principles
• What You Produce, Others Will Consume
– Always specify, design, document, and implement
knowing someone else will have to understand what
you are doing.
• Be Open to the Future
– Make it possible for your system to be modified,
extended, upgraded in the future.
 Software Quality
An effective software process applied in a manner that
creates a useful product that provides measurable value
for those who produce it and those who use it.
Bessin, J. (2004)

• An effective software process

• A useful software product
• Measurable values
– For software manufacturer
– For software user
 Software quality challenges
• Developer's capability
– a.k.a. How to ensure that a piece of software written
by a junior developer is as good as one written by an
experienced, senior developer.
• Product's complexity
• Device & platform diversity
– Different screen resolutions, OSes, hardwares.
– Different runtime environment support across
devices.
E.g. HTML5, JavaScript support on mobile devices
 Values vs. Costs tradeoff
• Failed software engineering
– Spend little time to produce terrible software
– Spend too much time and huge sums of money to produce
excellent software
• Internal failure costs:
– The costs of correcting defects before product delivery
– Defect correction costs much less if done during the coding
phase rather than the testing phase
• External failure costs:
– Caused by defects found when software has been released
to customers.
– Costs of: customer support, repair, lawsuit, refund,
reputation etc.
 The SQA plan
• A document that contains a road map for instituting
software quality assurance.
• Expected contents:
– Purpose and scope of the plan
– Description of all software engineering work products
– Standards and practices that are applied
– SQA activities and their timeline
– Tools and methods to support SQA
– Configuration management procedures
– People's roles and responsibilities
– Methods for keeping SQA-related records
 Verification & Validation
• Verification: The process of determining
whether or not the products of a given stage
of the software development life cycle fulfill
the requirements established during the
previous stage.
• Validation: The process of evaluating software
at the end of the software development
process to ensure compliance with software
requirements.
 Process Quality Assurance
• Build a software process
– Based on a proccess model
(Pressman 2019, chapter 2, 3 & 4)
• Monitor to see if the software process was
followed correctly
• Get feedbacks of the process-related issues
• Update the process to address the problems
(Process Improvement)
 Requirements Quality Assurance
• Software requirements activities
– Eliciting (discovering) requirements
– Specifying (writing) requirements
– Validating (reviewing) requirements
• Requirements QA activities
– Making & Reviewing the Requirements Plan
– Writing & Reviewing the Requirements Document
• Do or don't? How much does each of these
activities cost?
 Software Modeling QA
• Software Modeling deliverables
– Use case diagrams
– Activity diagrams
– Class diagrams
• Modeling QA activities
– Choosing how to do modeling: which diagrams to
use, whether or not to review the models?
– Accepting or rejecting the models.
– Making changes to the models.
 Software Design QA
• Software Design deliverables
– UI prototypes
– Description of methods & interfaces
– Sequence diagrams
• How it's done?
– Technical review meetings (Pressman 2019, chapter 16)
• A good design should:
– Implement all explicit and implicit requirements
– Be readable and understandable
– Provide a complete picture of the software
(Pressman 2019, chapter 9.2.1)
 Software Implementation QA
• Implementation deliverables
– Source code
– GUI
– Database
• How it's done?
– Pair Programming
– Unit Testing
– Integration Testing
– System Testing
 Garvin’s 8 quality dimensions
• Performance Quality
– Delivers all content, functions, and features specified in the
requirements
– Provides value to the user
• Feature quality
– Does the software provide features that surprise and
delight first-time end users?
• Reliability
– Does the software deliver all features and capability without failure?
– Is it available when it is needed?
– Does it deliver functionality that is error free?
• Conformance…
– to software standards
– to design and coding conventions
 Garvin’s 8 quality dimensions
• Durability
– Maintenance & debug do not lead to side effects
– Changes do not affect reliability & error rate
• Serviceability
– Fast maintenance & debug.
– Can support staff acquire all information they need to make changes
or correct defects?
• Aesthetics
– Elegance, uniqueness, attractiveness
• Perception
– The reputation of software vendor affects user's perception of quality

 Apply these concepts flexibly

 McCall’s 11 quality factors
• Correctness: the program satisfies requirements
specification, fulfills the customer's mission objectives.
• Reliability: the program can performs its intended function
with required precision.
• Efficiency: the amount of computing resources and code
required by a program to perform its function.
• Integrity: the control of unauthorized access.
• Usability: effort required to learn, operate, prepare input
for, and interpret output of a program.
• Maintainability: effort required to locate and fix an error in
a program.
 McCall’s 11 quality factors
• Flexibility: effort required to modify an operational (being
used) program.
• Testability: effort required to test a program to ensure that
it performs its intended function.
• Portability: effort required to transfer the program from
one hardware and/or software system environment to
another.
• Reusability: the extent to which a program [or parts of a
program] can be reused in other applications.
• Interoperability: effort required to couple one system to
another.
 Examples of quality factors
• Interoperability:
– Google Drive's ability to read & edit Microsoft Office
documents and spreadsheets
– The ability to login with Facebook on other apps
• Maintainablity:
– Updates on Microsoft Windows do not affect user's data
• Conformance:
– Website interface follows HTML5 and CSS3 specifications
– Relational database follows BCNF normalization
– Java programs follow standard coding conventions and
design principles (do some research on the Internet)
 Examples of quality factors
• Object-Oriented Programming usually provides
more maintainability, reusability and testability.
• Modular programming makes it easier to reuse
codes.
• The use of open standards (formats, protocols),
open-source libraries and open-source tools
increases portability, interoperability, reusability and
also reduces cost.
– However, some proprietary libraries and tools can result in
higher efficiency, maintainability and security.
 Negative examples of quality
• Interoperability:
– In iOS, you cannot upload a video from iCloud or Google
Drive to YouTube.
• Reliability:
– Course website goes down around assignment submission
deadline.
• Maintainability:
– When it takes less time to build a new software than to
upgrade existing software.
 Use case
• Requirements is one of SE’s a primary concerns
• Depicts the software or system from the end user’s
point of view.
– Narrative text (user story)
– An outline of tasks or interactions (use-case diagram)
– Template-based description (written use cases)
– Diagrammatic representation (activity diagrams)
 Examples of User Stories
• User stories can be expressed in a simple sentence,
structured as follows:
“As a [person], I [want to], [so that].”
• Examples:
– As a website member, I want to invite my friends, so we
can enjoy this service together.
– As a sales manager, I want to organize my work, so I can
feel more in control.
– As a manager, I want to know my colleagues progress, so I
can better report our success and failures.
 Use case diagram
• An outline of tasks and interactions.
• Describes the relations between actors and features,
relation/dependency between features.
– Break-down of complex use cases into smaller use cases.
• Can contain multiple actors, multiple systems, an
actor can interact with multiple systems.
Template-based use case elements
• ID, name, stakeholders
• Actor
• Trigger
• Pre-conditions
• Post-conditions (success condition)
• Minimal guarantee (failure condition, optional)
• Main/normal flow (how to lead to success)
• Alternative/exceptional flows (how to lead to failure)