Software quality

management
Dr inż. Krzysztof Rychlicki-Kicior
Lecture plan
● Definition of software quality

● Standards: ISO 25010

● Software development methodologies

● Code quality – metrics, indicators and useful tips

How to pass
● Lecture 50%

● Laboratories 50%

● Lecture will be passed as a test (additional terms during session)

● Labs will be discussed during labs – for now, it will be a group project
Presentation plan
● Software quality – a definition

● Why do we need software?

● Software quality v. code quality

● Software quality management Zarządzanie jakością oprogramowania

Bibliography
● Martin C. R., Clean Code: A Handbook of Agile Software Craftsmanship

● ISO 25010/2011 standard – https://www.iso.org/obp/ui/#iso:std:iso-iec:25010:ed-1:v1:en

Software quality
Software quality is defined as a several important characteristics used for describing software:

● performance,

● integrity,

● fulfilling functional requirements,

● usability,

● reliability,

● security.
Software quality
Software quality can be considered in both ways:

● In a business context – how to fit the business needs and the context where it is used

● In a technical context – code quality, its extensibility, error resiliency, connections

between components
Software quality – a business aspect
What is the most important aspect of high quality software for business clients?

● Performance?

● Integrity?

● Other of the mentioned aspects?

Software quality – a business aspect
● All of these aspects are desirable, but for a client, the most important part is…

● ...for them to get what they dream of!

Software quality – a business context
● Software can be secure, efficient and modern, but it does not mean a thing, if a need of a
client is not fulfilled

● The reverse rule is true, somewhat – software can be terrible, but as long as a business need
is fulfilled, they will be happy (although this, fortunately, changes over time)
Why do we need software?
● At this moment we can ask ourselves a question – why do we need software?

● Thinking about people and their needs related to software, we can mention many different areas:
○ solving everyday problems
○ communication
○ making life pleasant
○ as a tool for work
○ as an entertainment center
Why do we need software?
● In a business context, such a way of thinking does not make any sense

● Software must bring profits to the client!

● A profit can be achieved in two general ways:

○ By increasing the revenue

○ By cutting costs
Why do we need software?
● Both types of profit can be achieved in many ways

● In order to increase the revenue you can:

● Deploy software for customer management – CRM

● Use software for marketing campaign optimization, which lets you reach more clients
Why do we need software?
● Similar situation happens in case of cutting costs:

○ Process automation – converting nonoptimal business processes based on Excel (or

even regular sheets of paper!) to custom solutions

○ Team management software let you better utilize your available employees
Why do we need software?

● Not every client, of course, might realize that software can give them
some sort of benefits. Sometimes software is bought, because…:

○ "Our competition already has it!"

○ "Our CEO loves new technological gizmo"

○ "Our company is very modern and follows the biggest players in the business"
Why do we need software?

● Actually, such a situation can be very uncomfortable, because

sometimes it turns out that software is not actually useful for a client

● In the end – it is not difficult to deliver software that is described by a

client. It is difficult to deliver software that is truly needed by a client –
and if a client does not need anything, we should tell them so
Software quality – a technical aspect

● While a non-technical client is interested mostly in knowing whether

the software works, from a technical point of view other questions are
important, sometimes even more important:

○ Is the software secure?

○ Is it easily extensible?

○ Can you integrate it with other systems?

○ Is it reliable as a whole system?

○ Is it usable (in terms of UX)?

Software quality v. code quality

● Answering all these questions concern both software quality as a

whole, as well as code quality

● Remember that even high quality code does not necessarily confirm
the software quality overall

● High quality software should mean it has high quality code, but the
reverse statement is not always true
Software quality v. code quality
● Code quality can be measured using various metrics, from simple
ones based on number of lines per a file or a module, to more
complex, based on analyzing associations between various parts of
the application

● Very good effects can be achieved using simpler methods, tools and
processes during the software development process
Software quality management
● Now we reach the definition of SQM:

● A management process that aims to develop and manage the quality of software in such
a way so as to best ensure that the product meets the quality standards expected by the
customer while also meeting any necessary regulatory and developer requirements

● This definition is decent (much better than in Polish Wikipedia), but a bit generic one
Software quality management
● In the end, the goal of SQM is to ensure that the software will fulfill the client’s
needs and requirements, both functional and nonfunctional.

● The key aspects are:

○ Correct understanding of client’s needs

○ A proper management of available team employees

○ Fulfilling financial and temporal restrictions

ISO/IEC 25010:2011
● ISO/IEC 25010:2011 Systems and software engineering - Systems
and software Quality Requirements and Evaluation (SQuaRE)

● Standard ISO 25010 was introduced in 2011 replacing the ISO/EIC

9126
ISO/IEC 25010:2011
● Functional suitability

○ Functional completeness

○ Functional correctness

○ Functional appropriateness
ISO/IEC 25010:2011
● Performance

○ Time behaviour

○ Resource utilization

○ Capacity
ISO/IEC 25010:2011
● Compatibility

○ Co-existence

○ Interoperability
ISO/IEC 25010:2011
● Usability

○ Appropriateness recognizability

○ Learnability

○ Operability

○ User error protection

○ User interface aesthetics

○ Accessibility
ISO/IEC 25010:2011
● Relability

○ Maturity

○ Availability

○ Fault tolerance

○ Recoverability
ISO/IEC 25010:2011
● Security

○ Confidentiality

○ Integrity

○ Non-repudiation

○ Accountability

○ Authenticity
ISO/IEC 25010:2011
● Maintainability

○ Modularity

○ Reusability

○ Analysability

○ Modifiability

○ Testability
ISO/IEC 25010:2011
● Portability

○ Adaptability

○ Installability

○ Replaceability
Software development methodologies
● Software development methodology defines stages of a complex
software development production process

● There is no single, universal SDM that works everytime – everything

depends on the context

● SDM should be chosen based on a few important factors

Software development methodologies
● These factors are:

○ Predictability of development – does the client knows what they want?

○ Modularization – is the system monolithic or can the separate parts be useful for the client,
too?

○ Is the product dependent on the tight interaction with a client?

Software development methodologies
● One of the oldest SDM is Waterfall

● Its name stems from the fact that consecutive steps of the process
“fall” one after the other, just like in a real-world waterfall

● Called the cascade model

Waterfall
● Waterfall divides the whole software development process into six stages

1. Gathering the early requirements regarding software and the system – it

results in the Product Requirements Document

This stage should be done mostly by the client – it is important to define

what should be done by the product, not how.
Waterfall
● Product Requirements Document should contain:
○ The goal and the scope of the project
○ Stakeholder description
○ Target group description
○ Most important use cases description
○ Functional requirements description – concerning usability and information exchange with other
systems
○ Miscellaneous requirements, assumptions and dependencies
○ Evaluation metrics – project success criteria
Waterfall
2. Requirement Analysis – after requirements are retrieved from the client, you
need to process & analyze them. This includes the three following stages:

1. Requirement definition – getting all the information from the stakeholders and future users

2. Detailed requirement analysis – analysis of all information and dependencies used for
excluding any potential conflicts. The goal of this stage is to determine whether client
requirements have been properly understood.
3. Writing down the requirements – persisting the requirements in a way that fits the
particular case in the best way, e.g. user stories, use cases, diagrams.
Waterfall
● In cases of two previous phases it is important to define who the stakeholder is

● Stakeholders are people or organizations who are related to the discussed project

● They are not only employees of the client!

Waterfall
● Stakeholders are (i.a.):

○ Future users

○ People/organizations who will benefit from introducing the system

○ People/organizations responsible for assigning the funds/accepting the offer

○ People/organizations against introducing the system

○ People/organizations responsible for the software that will be integrated with the new system
Waterfall
3. Design – the goal of this phase is to prepare and describe all the elements
of the system based on the constraints received from the analysis phase

1. While both analytical phases have very precise results, in the design phase you need to
describe how will the effect be achieved

2. Artifacts (deliverables) created as a result of this phase will include diagrams,

descriptions, e.g. based on UML
Waterfall
4. Implementation – a proper delivery of the features

5. Tests – they are executed after the implementation phase

6. Deployment – placing the application in the production environment

7. Ongoing support
Agile programming
● Agile is an umbrella term for incremental SDMs created against to the
Waterfall

● The term was invented in the Agile Manifesto developed during the
2001 conference in Utah, USA
Agile Manifesto
To quote the original manifest:

● Individuals and Interactions over processes and tools

● Working Software over comprehensive documentation
● Customer Collaboration over contract negotiation
● Responding to Change over following a plan
Agile programming rules
1. Customer satisfaction by early and continuous delivery of valuable
software
2. Welcome changing requirements, even in late development
3. Working software is delivered frequently (weeks rather than
months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be
trusted
6. Face-to-face conversation is the best form of communication
(co-location)
Agile programming rules
7. Working software is the principal measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good
design
10. Simplicity—the art of maximizing the amount of work not
done—is essential
11. Best architectures, requirements, and designs emerge from
self-organizing teams
12. Regularly, the team reflects on how to become more
effective, and adjusts accordingly
Extreme Programming
● One of the oldest agile programming techniques, introduced even
before Agile Manifesto was proclaimed (1999)

● Focused on frequent release of consecutive releases and delivering

adjustments based on clients’ opinions

● The main goal is to create high-quality software in a more productive

way
Extreme Programming
● XP includes four main activities:

○ Programming (coding) – no coding means no product

○ Listening – understanding client’s needs

○ Testing – acceptance, unit and integration tests

○ Designing – only in larger projects, you need to ensure certain level of organization in your code
XP practices
● Pair programming

● Planning Game

● Test-Driven Development

● Team = developers + client (users of the system)

XP practices
● Continuous integration

● Refactoring

● Continuous improvement in released software

XP practices
● Coding standards

● Collective ownership

● Simple design

● System metaphor

● Sustainable pace
Agile – Scrum
● An agile methodology focused on improving software development process
by integrating the team and improving the communication within

● One of the most important assumptions is an ability to quickly and easily

adapt to changes

● The client does not always know what they want in the beginning, so you
need to focus on the fastest possible delivery of working software artifacts
– deliverables – and reacting to vastly changing conditions from the client’s
perspective and his environment
Scrum – three important rules
● Transparency – every team member should have access to all the
information related to his/her tasks

● Inspection – a frequent verification of a developed product and how it works

● Adaptability – an ability to adjust, adapt the project to the changing

requirements and the feedback from the client
Scrum – Product Owner
● Product Owner – represents stakeholders, responsible for the
business success of the project. It does not need to be an employee/a
representative of the client – it might be a vendor’s employee who has
contact with a client

● PO prepares user stories and prioritizes tasks to be done

Scrum – Product Owner
● PO discusses the state of the project, the state of the releases and the general progress
with stakeholders

● PO manages the product backlog – a list of all the requirements to be fulfilled

● PO defines budget, financing and describes more complex problems in the software
development process to the stakeholders

● To sum up, PO is an only connection between stakeholders and the development team
Scrum – Scrum Master
● Scrum Master is responsible for complying to and fulfilling the Scrum
requirements

● S/he is not a typical Project Manager, nor a Technical Leader – s/he

should resolve all the problems that make fulfilling the Scrum difficult

● Scrum Master does not manage other members of the team

Scrum – Scrum Master
● SM helps to define other team members criteria fulfilling definition of done

● SM removes all the problems and barriers that come up in the team

● SM helps supporting the team in implementing Scrum rules in everyday

work

● SM organizes all the events related to the Scrum project lifecycle

Scrum – Development Team
● The team that does the core work

● Includes different roles beside the software developers – it might

contain designers, analysts, testers, etc.

● It does not have an internal structure – DT organizes itself according

to its own rules

● DT does not contain a typical Project Manager

● Size – 3 to 9 people
Scrum – Sprint
● Sprint is a single part of a project lifecycle, which should result in
delivering a working, tested and deployed product

● Sprint has fixed duration – usually between a week and a month

Scrum – how the project goes
● After the initial requirements are established and prioritized in the product backlog, the first sprint
can be started

● Sprint begins with a planning that includes:

○ Choosing features to be delivered within this Sprint

○ Dividing features into separate tasks that are inserted in the spring backlog
Scrum – how the project goes
● A Daily Scrum is organized every working day when all the progress,
problems and challenges are discussed and addressed – albeit briefly

● They should be organized always at the same time, so there is no

time wasted on scheduling

● Every sprint is summarized during the Retro (Retrospective) meeting

Scrum – pros and cons
● Pros:

○ Flexibility

○ Constant progress – spring frequency forces the team to deliver the product in a
regular way which in turn gives a possibility to react quickly by the client

○ Focused on the client’s needs

Scrum – pros and cons
● Cons:

○ It works best if the team works at the same time and place – it certainly gets a bit
difficult when the team is located in different time zones

○ It is more difficult to conform to Scrum’s rules when there is a need to integrate with
external services
How to create high-quality code
● During first half of the semester we discussed the high-quality software

● High-quality software includes a lot of different aspects, but it is also related to

the code quality that stems from the programming

● High-quality code helps us manageability and extensibility – code that is not

well-managed won’t be easy to manage and further develop
How to create high-quality code
● High-quality code should be:

○ Understandable for other programmers (and for the author, too!)

○ Well-documented (it’s a bit controversial in terms of self-documenting code)

○ Extensible

○ Conforming to the standards that apply to a particular language, framework or

technology

○ Efficient – it is unacceptable if the code is well-written, but it works slow

How to create high-quality code
● Writing efficient and high-quality code from scratch since the very beginning
is very difficult

● That’s why we apply code refactoring – the process of improving code quality
without changing its behaviour
How to create high-quality code
● Code refactoring is a process performed after writing some amount of code

● Improving code quality is doable only after writing enough code, e.g. by
applying design patterns – it is only when we have enough code that we see
some patterns can be applied. Writing code that uses some patterns from
scratch is not impossible, but certainly is more difficult
How to write high-quality code
● Writing high-quality code is not an art of just writing excellent code itself

● It also covers including appropriate documentation (describing its structure,

how it works, how it can be developed) and keeping it in a proper shape in
control version systems
Fundamentals of writing high-quality code
● Clear and consistent naming scheme
● Proper use of comments
● Proper ways of creating functions/methods
● Code formatting
● Proper object-oriented programming
● Proper error handling
● Careful multi-threading programming

1
Clean Code: A Handbook of Agile Software Craftsmanship. Robert C. Martin
How to create good identifiers
Create human-friendly and clear names!

● One-letter names should be used only in well-known use cases (e.g. i, j, k

– iterators)

● Don’t include type information in a name of a variable (e.g. nameList)

● Forget the Hungarian notation (or don’t learn it at all :))
How to create good identifiers
Create human-friendly and clear names!

● Use consistent naming scheme (e.g. delete for all operations related for
deleting data instead of using remove and delete sometimes)

● Create complex names (e.g. state – can be a state of the machine, but
can be a geographical state in US)

● Use names that can be easily searched for

How to create good comments
Don’t comment bad code – rewrite it!1

● Comments are necessary evil – they help clarifying unclear code

● Sometimes comments complement information that should be present in the

code

● GOOD examples: e.g. legal notes

1
Brian W. Kernighan and P. J. Plaugher
How to create good comments
Don’t comment bad code – rewrite it!1

● GOOD: Sometimes it is good to put a comment, especially when the code

cannot be easily explained by itself and the explanation is truly required (e.g.
when explaining a regexp)

● GOOD: Metacomments, e.g. TODO or FIXME

● GOOD: Javadoc and other similar comments used for automatically

generating the documentation

1
Brian W. Kernighan i P. J. Plaugher
How to create good comments
Don’t comment bad code – rewrite it!1

● BAD: Most comments are bad, because they are redundant…

● …or, worse, they are simply wrong!

● BAD!: Commenting the code out – especially when the code is committed to
the code repository!

1
Brian W. Kernighan i P. J. Plaugher
Functions
Write short functions!
● Write functions that do one thing and do it well

● Stay on one level of abstraction (don’t mix different abstraction levels)

Functions
Write short functions!
● When creating functions hierarchy (a tree), write them as if you were writing a
story, with logical consequences

● Limit the number of arguments in a function

● Don’t use out arguments

Functions
Write short functions!
● If you need to pass more than 3 arguments, try to group them into more complex
data structures

● An exception can be made for variable arguments (the varargs), like in

printf/String.format type of functions

● Write functions that do not have side effects!

Functions
Write short functions!
● Instead of using out arguments, try using the objects that are passed as
parameters

● Use exceptions instead of code errors

Functions
Don’t Repeat Yourself!
● If any nontrivial code repeats itself, “try taking out the common factor” – get the
code that is repeated in a few places, put it in a separate functions and just call
this function wherever the original code was present

● Don’t expect that writing functions in that way happens from scratch – the
aforementioned advice is usually applied during code refactoring
Code formatting
● Code formatting increases readability which makes it easier to modify the code in
the future

● A single source code file should have a few hundred lines of code tops\

● Whitespace between rows should reflect associations between different code

snippets
Code formatting
● Local variables should be declared close to the place where they are used

● Class variables should be declared at the top of the class, in one single group

● Related methods should be close to each other

● A single line of code should have 100-120 characters tops – the most important
aspect is not to be forced to scroll the editor
Code formatting
● Code indentation!

● A single set of code conventions should be used within one project or even
one organization – not conforming to conventions might result in less
readable code and even certain type of technical problems!
Object-oriented programming
Hide implementation details!

● Share the abstraction at the level that is required by its users

● Don’t show internal details of data structures – you will save time
whenever you’ll decide to change it in the future

● Share operations, not data!

Object-oriented programming
Hide implementation details!

● Object-oriented programming vs. procedural programming in terms of

operation & data extensions:

● If your application requires an often change in data – write in an object way

● If your application requires an often change in operations – write

procedurally
Object-oriented programming
Hide implementation details!

● Method chaining should be used carefully

● Whether or not you should use them depends on whether you use objects or
data structures
Error handling
Handle errors, but do not obfuscate the code!

● Use exception catching instead of returning code errors or setting the error
flags

● Start from creating try..catch..finally clauses

● Don’t use checked exceptions!

Error handling
Handle errors, but don’t obfuscate the code!

● Create a reasonable exception class hierarchy

● Don’t use exceptions just to handle special cases

Error handling
Handle errors, but don’t obfuscate the code!

● Don’t return the null value…

● …and don’t pass the null value to the function!

Unit tests
Follow the five rules of unit tests (FIRST)

● FAST – tests should be fast, i.e. their execution should not take too much time

● INDEPENDENT – tests should be independent of one another; any test

should not rely on another test’s execution
Unit tests
Follow the five rules of unit tests (FIRST)

● REPEATABLE – tests should be repeated with the same outcome no matter

where they are run

● SELF-VALIDATING – tests should have only two possible outcomes – positive or

negative

● TIMELY – tests should be written just before the related feature code
Unit tests
Follow the five rules of unit tests (FIRST)

● On the top of the FIRST rule, tests should be readable and up to date with
the implementation code

● Execute assertions according to the following rule: one assertion means

one test case
Classes
Classes should be small, just like the functions!

● A good check on whether the class is too large is to check its name and
responsibilities

● If the name suggests that the class has too much on its plate – change it (the
class, not the name!)
Classes
Classes should be small, just like the functions!

● A class should change only because one reason (i.e. actor)

● Classes should have high cohesion and low coupling

Classes
Classes should be small, just like the functions!

● Be ready for changes!

Groups of classes
● Put the app initialization and configuration code in one place

● At the same time, separate implementation of the bootstrap process from the
rest of the code using factories design patterns
Groups of classes
● Use dependency injection, especially with annotations/decorators and
inversion of control

● Don’t use too much lazy initialization

Groups of classes
● Write code that follows all the tests

● Refactor code often and in small steps

Groups of classes
● Don’t repeat yourself

● Make your code more readable

Multithreading
● Threads don’t always improve performance

● Don’t use threads unless you have to

Multithreading
● Threads are nondeterministic, so the errors are not always repeatable

● It’s not always easy to change the application so it handles more threads
Multithreading
● Use critical sections and locks in order to limit access to shared data

● Use variables with the most limited scope possible

● Use copies of variables

Multithreading
● Limit data shared by multiple threads

● Use collections that are thread-safe

Multithreading
● Avoid deadlocks

● Limit scopes of critical sections

Code smells
● Code smells are certain traits of code that should make a programmer rethink
their code and include refactoring in the process

● Defined by Kent Beck and popularized by Martin Fowler in a book called

Refactoring: Improving the Design of Existing Code
Code smells
● Long methods, large classes – blocks that should be divided into smaller
entities

● Feature Envy – concerns methods that use external data or methods too
often. You should consider move such data or methods within the given class

● Inappropriate Intimacy – happens when methods of a class are too

dependent of the other class implementations. It shouldn’t happen as you
should only depend on the interfaces of other classes
Code smells
● Odrzucony spadek – derived classes change the contract/rules defined in
the base classes

● Lazy class – a class of too small responsibility

● Duplicated code – it speaks for itself☺

● Contrived Complexity – happens when too complex design patterns are

used
Code smells
● Complex build process – the build process should be reduced to just one
command…

● Complex testing process – …just like the testing process

Code smells
● Language mixture – you shouldn’t use more than one language in a single
file

● Lack of obvious features – a library/class/function does not have

behaviours that should be considered obvious
Code smells
● Dead code – the code that will never be called/executed

● Wrong static elements – using static methods in wrong situations, especially

when polimorphic code could have been used