LAB OF SOFTWARE ARCHITECTURES
AND INFORMATION SYSTEMS
FACULTY OF INFORMATICS
MASARYK UNIVERSITY, BRNO
ROADMAP TO SOFTWARE QUALITY
Barbora Bühnová
buhnova@fi.muni.cz
PV260 COURSE INTRODUCTION
1
Outlineofthelecture
• Course introduction
• Course motivation and goals
• Course organization
• Our team
• Roadmap to quality engineering methods
• Define quality issues
• Prevent quality issues
• Detect quality issues
• Repair quality issues
• Keep track of quality issues
• Choose well, plan well
© B. Bühnová, PV260 Software Quality
2
Outlineofthelecture
• Course introduction
• Course motivation and goals
• Course organization
• Our team
• Roadmap to quality engineering methods
• Define quality issues
• Prevent quality issues
• Detect quality issues
• Repair quality issues
• Keep track of quality issues
• Choose well, plan well
© B. Bühnová, PV260 Software Quality
3
Coursemotivationandgoals
“People forget how fast you did a job – but they remember
how well you did it” – some guy named Howard Newton
• The aim of the course is to help the students to
• understand activities contributing to building high-quality software;
• develop critical thinking and be able to identify code flaws related to
reliability, performance, scalability, maintainability and testability;
• be able to refactor existing code to improve different quality attributes;
• have practical experience with software testing and related tools.
© B. Bühnová, PV260 Software Quality
4
Outlineoflectures
Lect 1. [LaSArIS, B. Bühnová] Course organization. Roadmap to software quality engineering methods.
Lect 2. [LaSArIS, B. Bühnová] Clean Code & SOLID principles. Bad code smells and code refactoring.
Lect 3. [LaSArIS, B. Rossi] Software measurement and metrics, and their role in quality improvement.
Lect 4. [Solar Winds, Jiří Pokorný] Automated testing and testability. Continuous integration/delivery.
Lect 5. [LaSArIS, B. Rossi] Basic Principles of Testing. Requirements and test cases.Test plans and risk
analysis. Specific issues in testingOO Software.
Lect 6. [Siemens, J.Verner] Quality and testing in agile. Practical insights on QA in real product development.
Lect 7. [LaSArIS, B. Bühnová] Focus on quality attributes and conflicts between them.
Lect 8. [To be confirmed] Performance engineering and performance testing.
Lect 9. [YSoft, O. Krajíček]The role of software architecture - practitioner view.
Lect 10. [LaSArIS, B. Bühnová] Software architecture guidelines for software quality?
Lect 11. [Honeywell, J. Papcun, J. Svoboda] Static code analysis and code reviews.
Lect 12. [LaSArIS, D. Gešvindr] Challenges of quality management in cloud applications.
Lect 13. [LaSArIS, B. Rossi] Software quality management process.
31. 5. 9:00-14:00 [All]Colloquium event
© B. Bühnová, PV260 Software Quality
5
Courseorganization
• Lectures
• Shared by us and experts from companies
• May not be recorded
• Final colloquium event after the end of semester (May 31, 2022)
• Seminars
• Practical assignments on computers
• Teamwork, homework, projects
• Java group – by LaSArIS lab
• Java group – by NetSuite experts
• Java group – by Red Hat experts
• C# group – by Y Soft experts
© B. Bühnová, PV260 Software Quality
6
Courseorganization
• Evaluation
• 45 points for seminar assignments
• All the assignments need to be at least submitted, otherwise,
the student cannot attend the final colloquium event and write the test.
• 10 seminar activity points
• 10 lecture activity points
• 35 points for final colloquium assessment, consisting of
• obligatory attendance at the final colloquium event and
• final written test
• Minimum of 70 points for passing the course
• Colloquium event
• On May 31, 2022, between 9:00-14:00
• Discussion groups led by industrial experts
• Student presentations of outcomes
• Written test
© B. Bühnová, PV260 Software Quality
7
Outlineofthelecture
• Course introduction
• Course motivation and goals
• Course organization
• Our team
• Roadmap to quality engineering methods
• Define quality issues
• Prevent quality issues
• Detect quality issues
• Repair quality issues
• Keep track of quality issues
• Choose well, plan well
© B. Bühnová, PV260 Software Quality
8
QualityEngineering(QE)methods
© B. Bühnová, PV260 Software Quality
Usability testing
Security testing
Security tactics
9
RoadmaptoQE methods
Prevent
quality issues
Detect
quality issues
Repair
quality issues
Keep track of
quality issues
Define
quality issues
© B. Bühnová, PV260 Software Quality
10
Definequalityissues
• Software quality is commonly
defined as the capability of
a software product to conform
to requirements [ISO/IEC 9001].
• Requirements engineering
• Software metrics
• ’You cannot manage what you cannot measure’
• Quality attributes
• Of a product, process and resources
© B. Bühnová, PV260 Software Quality
Prevent
quality issues
Detect
quality issues
Repair
quality issues
Keep track of
quality issues
Define
quality issues
customer needs
11
What"quality"meanstoyou?
…andyourcustomer?
…andyourmanager?
© B. Bühnová, PV260 Software Quality
Cost
effectiveness
12
TheSoftwareQuality Iceberg
EXTERNAL QUALITY
INTERNALQUALITY
Visible / Symptoms
Invisible / Root
usability
accuracy
cost
performance
reliability
program structure
complexity
coding practices
testability
reusability
maintainability
flexibility
understandability
security
testinginspection
Inspiration from [5]
manualorautomated?
measurableornot?
© B. Bühnová, PV260 Software Quality
13
Thebig five
• Along the course we will focus on:
• Maintainability – ease of change (without increased technical debt)
• Performance – response time and efficiency in resource utilization
• Reliability – probability of failure-free operation over a period of time
• Testability – degree to which the system facilitates testing
• Scalability – system’s ability to handle growing work load
• Quality attributes studied in related courses:
• Security – system’s ability to protect itself from attacks
• Usability – ease of system use and learnability
© B. Bühnová, PV260 Software Quality
14
Preventqualityissues
• Coding best practices
• Clean code, SOLID principles
• Design patterns
• Pair programming
• Code conventions
• Language specif. recommendations
• Quality assurance processes
• V-model of testing,Test Driven Development
• Standards for development process improvement
• CMMI and ITIL reference models
• ISO 9000, ISO/IEC 25010
© B. Bühnová, PV260 Software Quality
Prevent
quality issues
Detect
quality issues
Repair
quality issues
Keep track of
quality issues
Define
quality issues
processescode-level 15
Detectqualityissues
• Testing functional requirements
• Manual or automated
• Testing non-functional req.
• Performance, usability, security
testing
• Design inspections
• Manual inspections of design artifacts
• Code reviews
• Manual inspections of code
• Automated static code analysis
© B. Bühnová, PV260 Software Quality
Prevent
quality issues
Detect
quality issues
Repair
quality issues
Keep track of
quality issues
Define
quality issues
staticanalysistesting 16
Roadmaptosoftwaretesting
© B. Bühnová, PV260 Software Quality
Inspired from [1]
Test cases
Test resources
Test plan
Testing
Strategy
Unit
Component
Functional
Test
Backend
Middleware
Third party
System and
IntegrationTest
Functional
Non-functional
Regression
ReleaseTest
Usability
Learnability
Requirements
Acceptance
(User)Test
Application
Infrastructure
Post-production
Tuning
Requirements
Acceptance
Criteria
Test management
Functional testing
Non-functional testing
Tuning
Specify Design Prototype Configure Validate Deploy Maintain
DevelopmentTestingEnd-to-EndView
ImplementationCycle
Penetration
Red team
SecurityTest
Response time
Stress
PerformanceTest
17
Repairquality issues
• Functional issue
• Code repair
• Reliability issue
• Fault tolerance mechanisms
• Performance issue
• Concurrency, effective resource utilization,
identify and remove system bottlenecks
• Security issue
• Identify and remove system vulnerabilities (single points of failure)
• Maintainability issue
• Refactoring to clean code principles, to design patterns
© B. Bühnová, PV260 Software Quality
Prevent
quality issues
Detect
quality issues
Repair
quality issues
Keep track of
quality issues
Define
quality issues
tacticsandpatterns 18
Keeptrackofqualityissues
• Issue tracking
• Supports the management of
issues reported by customers
• Technical debt management
• Level of code quality degradation
• Work that needs to be done before
a particular job can be considered complete or proper
• Configuration management
• Version management and release management
• System integration
© B. Bühnová, PV260 Software Quality
Prevent
quality issues
Detect
quality issues
Repair
quality issues
Keep track of
quality issues
Define
quality issues
19
RoadmaptoQEmethods–theBigPicture
Prevent quality issues
- Coding best practices
- Code conventions
- QA processes
- Standards
Detect quality issues
(Non)Functional testing Design
inspections Code
reviews Static
code analysis Repair
quality issues
- Reliability tactics
- Performance tactics
- Security tactics
- Maintainability tactics
Keep track
of quality issues
Issue tracking Technical
debt management Configuration
management Define
quality issues
- Requirements engineering
- Quality attributes
© B. Bühnová, PV260 Software Quality
20
Outlineofthelecture
• Course introduction
• Course motivation and goals
• Course organization
• Our team
• Roadmap to quality engineering methods
• Define quality issues
• Prevent quality issues
• Detect quality issues
• Repair quality issues
• Keep track of quality issues
• Choose well, plan well
© B. Bühnová, PV260 Software Quality
21
Choosewell,plan well
• Think well about your requirements
and the cost of the quality
© B. Bühnová, PV260 Software Quality
22
Choosewell–Combinationisthekey
© B. Bühnová, PV260 Software Quality
From [2,3], see also RebelLabs reports [4]
23
Plan well –The PowerofAnalogy
• Airplane Servicing
• Requires regular servicing e.g. every 100,000 miles.
• Takes place even if everything seems to work all right,
because we cannot afford a failure.
• Technical Debt Management
• Introduced by Ward Cunningham
• Analogy of quality degradation with financial debt
– if not paid off, interests increase.One can get into trouble.
• Sometimes it is wise to “borrow money”
• When one expects to have more money in the future (start-up company)
• When one needs to act fast not to miss a market opportunity
• When one expects money devaluation (e.g. developers will become
more experienced, it will be easier to understand user needs)
© B. Bühnová, PV260 Software Quality
Can we quantify it?
24
Takeaways
• Quality engineering (QE) is much more than testing,
including many different methods to
• prevent, detect, repair and keep track of quality issues
• Combination of the methods is the key to successfulQE
• But choose well and plan well, not all methods are best for your project!
• Make sure you understand the needs of your customer
• Balance both internal and external quality attributes for both
the present and the future
Barbora Bühnová, FI MU Brno
buhnova@fi.muni.cz
www.fi.muni.cz/~buhnova
contact me
thanks for listening
© B. Bühnová, PV260 Software Quality
25
References
• [1]TestingYou PerformWhenYou Develop a SiebelApplication.Available online at
http://docs.oracle.com/cd/E14004_01/books/DevDep/Overview5.html
• [2] Steve McConnell. Code Complete:A Practical Handbook of Software
Construction, Second Edition. Microsoft Press, June 2004.
• [3] Kevin Burke. Why code review beats testing: evidence from decades of
programming research. Available online athttps://kev.inburke.com/kevin/the-best-
ways-to-find-bugs-in-your-code/
• [4] RebelLabs. 2013 Developer Productivity Report. Available online at
http://zeroturnaround.com/rebellabs/developer-productivity-report-2013-how-
engineering-tools-practices-impact-software-quality-delivery/
• [5] Jonathan Bloom.Titanic Dilemma:The SeenVersus the Unseen. Available online
at http://blog.castsoftware.com/titanic-dilemma-the-seen-versus-the-unseen/
© B. Bühnová, PV260 Software Quality
26