Practical Findings from Applying Quality Assurance Activities in the

Development of Three Information Systems for Power Companies

Geraldo Braz Junior

1 a

, Luis Rivero

1 b

, Jo

ao Almeida

1 c

, Simara Rocha

1 d

, Arist

ofanes Silva

1 e

Anselmo Paiva

1 f

, Carlos Castro

, Darlan Quintanilha

1 g

, Italo Santos

1 h

, Erika Alves

and Samira Barbosa

ucleo de Computac¸

ao Aplicada, Universidade Federal do Maranh

ao, S

ao Luis, Brazil

Equatorial Energia S/A, S

ao Luis, Brazil

Keywords:

Software Quality, Experience Report, Lessons Learned, Power Company Information Systems.

Abstract:

Quality can be achieved in software development by identifying and ﬁxing defects, improving the develop-

ment process and including conﬁguration management activities. However, for novice development teams,

including the above activities may be difﬁcult when developing large or complex information systems. Thus,

to gain insight on how to improve software quality, novice software engineers may review reports from real

software development projects and apply lessons learned. In this paper, we report how software engineering

activities for quality assurance were adapted within three power company information system projects. We

explain how activities regarding version tracking, software testing and user interface design were carried out

by three novice software development teams within a software organization of about 40 collaborators. Our

results indicate that version control can be costly at ﬁrst, but is useful to assess the current state of the develop-

ment of features. Furthermore, though low-cost evaluation and design approaches, the end product can meet

users’ needs and reduce rework when launching a version of an information system.

1 INTRODUCTION

Current research indicates the many beneﬁts of apply-

ing quality assurance activities such as (Rothenberger

et al., 2010): successful and cost-effective software

production, better product quality, user satisfaction,

cost reduction, rework reduction and meeting goals in

time. However, software engineers still indicate sev-

eral challenges in the implementation of quality as-

surance activities such as losing focus when dealing

with large teams; and difﬁculty in adapting methods

or practices into the development life-cycle (Kamei

et al., 2017).

To the best of our knowledge, there are few reports

https://orcid.org/0000-0003-3731-6431

https://orcid.org/0000-0001-6008-6537

https://orcid.org/0000-0001-7013-9700

https://orcid.org/0000-0003-3318-7281

https://orcid.org/0000-0003-0423-2514

https://orcid.org/0000-0003-4921-0626

https://orcid.org/0000-0001-8134-4873

https://orcid.org/0000-0002-2041-7538

on how quality assurance activities were performed

and the lessons learned from such experiences. Fur-

thermore, the available reports are not always related

to the development of information systems nor pro-

vide details of the applied process (Wonohardjo et al.,

2019). Considering the above, in this paper we de-

scribe how three quality assurance activities were per-

formed within the context of three different projects

developing information systems. In these projects, at

least one of the following methods/practices were im-

plemented: (a) exploratory testing; (b) version control

strategy with gitﬂow; and (c) usability evaluation and

redesign. During the execution of the projects, we

took notes on the process, positive outcomes and im-

provement opportunities of the activities we carried

out in an agile-based context.

2 RELATED WORK

Researchers and practitioners have reported their ex-

periences on how quality assurance procedures have

Braz Junior, G., Rivero, L., Almeida, J., Rocha, S., Silva, A., Paiva, A., Castro, C., Quintanilha, D., Santos, I., Alves, E. and Barbosa, S.

Practical Findings from Applying Quality Assurance Activities in the Development of Three Information Systems for Power Companies.

DOI: 10.5220/0011081700003179

In Proceedings of the 24th International Conference on Enterprise Information Systems (ICEIS 2022) - Volume 2, pages 159-166

ISBN: 978-989-758-569-2; ISSN: 2184-4992

159

been applied (Oprins et al., 2019). For instance,

Hron and Obwegeser (2018) discuss the results from

a systematic literature review reporting the challenges

and motivations that lead to modiﬁcations in an ag-

ile software development process. The authors iden-

tiﬁed some strategies for adaptation such as: (a) in-

troduction of additional processes, artifacts or roles;

(b) inclusion of notes or instructions to better guide

the development process; and (c) implementation of

changes in procedures, artifacts or roles. The results

are useful for understanding the motivations for in-

cluding changes, such as considering usability in soft-

ware development, or combining further methods to

improve the results of the development project.

In the ﬁeld of software testing, Collins and Lu-

cena (2012) shared their experience of applying soft-

ware testing automated tools. After describing two

software development projects and reporting the pro-

cedures for carrying out the test automation using Se-

lenium, the authors present lessons learned regarding:

(a) collaboration within the development team; (b) ﬁt-

ting the testing tools according to the test strategy;

(d) simpliﬁcation of the automation process; and (e)

types of tests that could be automated.

With regards to usability improvement, de Car-

valho et al. (2016) analyzed how user centered de-

sign is explored within an agile context. To do so,

the authors carried out a systematic literature review

and presented an experience report on how usability

evaluations can be applied in development. The eval-

uations were performed before the development of the

software, yielding less rework, usability improvement

and a change on the mindset of the team.

The above reports suggest an interest in describ-

ing how adaptations within a software development

process can support the quality improvement of infor-

mation systems under development. Yet, there is still

a need for further reports on the use of different qual-

ity assurance approaches in further contexts, since

some reports do not describe in which settings these

approaches were adopted, their strengths and weak-

nesses from the point of view of software engineering

practitioners (Theocharis et al., 2015). For instance,

some papers discussing how adaptations are being

made, do not describe the contexts in which they oc-

cur neither the speciﬁcs of the changes implementa-

tion (Hron and Obwegeser, 2018). Furthermore, to

the best of our knowledge, although there are works

describing the inclusion of speciﬁc activities in prac-

tice (Hassani-Alaoui et al., 2020) (Ruane et al., 2020),

they mostly provide an overview of the changes;

while others that focus on speciﬁc changes related to

quality assurance could provide further examples of

the artifacts that were speciﬁcally developed by the

software organization (Collins and de Lucena, 2012)

(de Carvalho et al., 2016). Thus, in this paper we

present further examples of how software engineer-

ing technologies and procedures have been included

for the quality assurance of information systems. Be-

low, we present details of our agile-intended software

development projects and what changes were made.

3 THE SOFTWARE

DEVELOPMENT PROJECTS

Three software development projects were carried out

for the development of information systems to help

solve problems in the context of power companies.

The Equatorial National Power Company hired the

Computing Group at Federal University of Maranh

for this task. The Computing Group had around 40

collaborators and worked in the development of infor-

mation systems using artiﬁcial intelligence and em-

bedding machine learning (ML) systems. Below, we

present each project chronologically (from the oldest

to the most recent), providing details on their purpose,

how they were executed and the implemented changes

for quality assurance.

3.1 Project A - Tracking Clients with

High Degree of Lawsuit Chance

Context: The goal of this project was to develop an

information system for automatically identifying the

predisposition of consumers in ﬁling lawsuits towards

power companies. Based on attributes such as power

outage, improper power cut, improper billing and in-

creased power consumption, a score indicating the

probability of a client to ﬁle a lawsuit was embedded

into a database, providing details of the dissatisfaction

of clients. With this information, the information sys-

tem could generate reports so that the customer ser-

vice of the company could provide support to these

clients and improve their satisfaction.

Project Details: This project lasted 18 months

(from 2018 to 2020). In all, the development team

had 24 software engineers. The project followed an

agile development process, following practices from

the Scrum methodology (Kamei et al., 2017), but

focusing on deliverables for each milestone within

the project. The following goals were set within the

project: (a) Scope and architecture deﬁnition (Months

1-3); (b) Development of Data Base (Months 4-10);

the data to export managerial reports (Months 4-10);

ICEIS 2022 - 24th International Conference on Enterprise Information Systems

160

(d) Development of Module II, which would optimize

algorithms for automatically generating and adapt-

ing clients groups (Months 6-14); (e) Development of

User Interface that would integrate the data and pro-

duce reports (Months 12-18); and (f) Testing, Integra-

tion and Release (Months 6-18). Each sprint lasted

for a month and the goals between sprints overlap to

improve productivity. Also, although there were 24

software engineers, they were split into smaller teams

to meet development goals concurrently, such as al-

gorithm, architecture and interface modeling, imple-

mentation and testing of features, implantation of the

system and others.

Adaptations for Quality Assurance: Since the

project had several updates regarding the user inter-

face requirements and handling of the data to provide

reports, there was no updated documentation for the

testing of the web application. As a result, the de-

velopment team decided to employ a manually ex-

ploratory testing approach, in which the tester actively

controls the design of the tests as those tests are per-

formed; and uses information gained while testing to

design new and better tests (Quesada-L

opez et al.,

2019). We planned the tests by identifying and orga-

nizing the different functionalities of the web applica-

tion through meetings with the development team and

scrum master, who had validated the requirements

with the product owner.

The testing team derived a test scenario with an

initial path to test how each function would work in an

expected way. Once such path was was covered, al-

ternative paths considering different inputs were con-

sidered in order to identify further paths. Figure 1

shows an example of a test scenario that was derived

through the exploratory testing. The identiﬁcation of

scenarios and development of test scenarios continued

during the development process in the ﬁnal sprints.

At the end of each sprint, new test scenarios would

be discussed and the old ones would be reviewed,

updated (if necessary) and re-executed to verify the

proper functioning of the ML web application.

3.2 Project B - Self Power Consumption

Reading

Context: The goal of this project was to develop a

mobile information system that could register power

consumption readings. By using the application,

clients would be able to register their consumption in

three different ways: by image, by voice and by key-

board. The power company wanted users to have dif-

ferent ways of measuring their consumption, as this

solution was originally designed for rural areas that

are difﬁcult to access.

Figure 1: Test scenarios for a functionality from the ML

web application.

Project Details: This project lasted for 24 months

(from 2019 to 2021). The development team had 14

team members and followed a similar development

process as in project A. Along with the functional-

ity tests, we applied usability ad-hoc inspections and

validations, to identify improvement opportunities in

the design of the mobile application.

Adaptations for Quality Assurance: In this

project, there was a need to identify usability prob-

lems and propose redesign suggestions to meet them.

To achieve this goal, we followed a usability evalu-

ation approach similar to the one by Plechawska et

al. (2013). A usability and UX consultant was con-

tacted to retest the entire system and also carry out

an ad-hoc usability inspection. The consultant re-

executed the identiﬁed test scenarios and during each

test, he veriﬁed usability attributes. Since the consul-

tant had more than 5 years of experience evaluating

the usability of web and mobile applications, he did

not need to check usability heuristics as performed

by Plechawska et al. (2013), thus characterizing the

inspection as ad-hoc (Damian et al., 2020). In this

sense, during the evaluation process, if usability prin-

cipals from mobile applications were not met during

the interaction of the analyzed test scenario from the

point of view of the consultant, a suggestion/doubt

Practical Findings from Applying Quality Assurance Activities in the Development of Three Information Systems for Power Companies

161

was included in the test report and it was discussed

with the development team and the representatives

from the power company. Figure 2 shows an example

of the tests scenarios that were adapted from project

A, which also show comments made by the consultant

indicating usability problems.

Figure 2: Test scenario for a functionality from the mobile

application and reporting of usability problems.

3.3 Project C - Automated Customer

Support of Clients

Context: The goal of this project was to develop

an information system to support the decision mak-

ing process of prioritizing the contact of unsatisﬁed

clients. In this sense, this application would provide

relevant information on the dissatisfaction degree of

a client based on information obtained from the data

base in project A, and indicate which clients require

immediate assistance.

Project Details: This project was carried out over

a period of 18 months, starting in 2020 until 2022.

In all, the development team consisted of 18 soft-

ware engineers. The development team applied the

same development process as in projects A and B.

To deﬁne which deliveries would be produced and

evaluated, goals were deﬁned for each month regard-

ing the development of each of the systems’ modules

implementing the solutions requested by the power

company. The following activities were deﬁned for

the project: (a) Deﬁnition of scope and architecture

(Months 1-3); (b) Database Development (Months 4-

10); (c) Development of Report Generation and De-

cision Making Modules (Months 4-14); (d) Devel-

opment of User Interfaces that would integrate data,

make contact with users and produce reports (Months

8-18); and (e) Test, Integration and Release (Months

6-18).

Adaptations for Quality Assurance: In this

project, the main issue was to track the different

changes of all the modules that were being imple-

mented. Also, there was a high degree of turnover

in software developers, which caused trouble when

maintaining current and previous software. As a re-

sult, the project manager decided to implement a

branching model for Git, which is the version control

system in use by our organization.

To decide which branching model would be em-

ployed, the management team, together with a sub-

set of the more experienced developers, held several

meetings with brainstorming sessions. In these meet-

ings, we deﬁned what risks/difﬁculties were frequent

in projects A and B that could be avoided using a

branching model to track changes. Among the main

problems, the team highlighted: (a) difﬁculty in ﬁnd-

ing the correct ﬁles in the team directories; (b) difﬁ-

culty in identifying who was responsible for modify-

ing the artifacts; (c) difﬁculty in keeping information

about results obtained in sprints in terms of developed

features; and (d) difﬁculty in maintaining version con-

trol and quality assurance in terms of test execution.

After analyzing different branching models and

considering the problems listed above, the develop-

ment team decided to employ Gitﬂow, which is a

heavily branch-based, but project focused deliverable

model that deﬁnes the roles of each branch and how

they should interact (Driessen, 2010). Among the

branches used within Gitﬂow, the following are sug-

gested (Olausson and Ehn, 2015): feature branches,

release branches and maintenance branches. Git-

ﬂow has been adopted in several development projects

with success but few practical information on how it

was applied is provided (Bretal Ageitos, 2020). The

team proposed a process in which the managers, de-

velopers and test team would have designated activ-

ities related to version control of the systems under

development, following Gitﬂow suggestions adapted

to the needs and reality of the team. To keep track

of the various branches of the system under develop-

ment, accounts were created in Git so that each team

member was assigned the responsibilities of feeding

ICEIS 2022 - 24th International Conference on Enterprise Information Systems

162

the repository. In addition, codes and structures were

designed to keep track of the actions of team mem-

bers. For example, when creating a new branch of

type feature, a developer would have to use the fol-

lowing standard: ”Create Branch - Feature - Fea-

ture Name”. Similar instructions and structures were

adopted throughout the newly deﬁned process.

4 RESULTS

In this section, we present how the processes applied

in Section 3 yielded results for each project, and what

lessons each team learned with these experiences.

4.1 Project A

After identifying a problem, the development team

adopted a report approach using a project manage-

ment system

and a set of spreadsheets. In the man-

agement system, we indicated information such as:

functionality id, tester name, problem description,

team member that was responsible for the correction,

degree of severity, date to correct the problem and an

image of the problem. To decide which problems

would be corrected ﬁrst, a scale for the degree of

severity was applied: (a) cosmetic: there is no need

for immediate correction of the problem; (b) minor:

it is a problem with low correction priority (could

be corrected); (c) major: it is a problem with high

correction priority (must be corrected); and (d) catas-

trophic: it is a problem of very high priority (if it is

not corrected immediately, the system will stop work-

ing). This scale was useful for deﬁning which prob-

lems were to be corrected and when. For instance,

layout problems were considered cosmetic or minor

if they not affected the usability of the system or were

almost unnoticeable. On the other hand, miscalcula-

tions were treated as major or catastrophic problems

if they impacted in the reliability of the software and

if they where problems in functions with high degree

of use from the point of view of users.

At the end of the project, 254 functional test

scenarios were identiﬁed using exploratory testing.

Through these tests, we veriﬁed the functionalities

in terms of proper response of the system, adequate

data presentation, system messages, input error han-

dling and navigation. By the end of the project, all

test scenarios passed and all minor, major and catas-

trophic problems were corrected, guaranteeing the

proper functioning of the information system.

http://trello.com

4.2 Project B

As in Project A, the functional testing through explo-

ration allowed correcting issues with regards to wrong

outputs of the system and missing information ac-

cording to the requirements. Furthermore, we iden-

tiﬁed around 30 usability problems through the ad-

hoc inspection. Figure 3 shows some of the screens

in which usability problems have been identiﬁed. For

instance, in part A (Home Screen) there is no infor-

mation on the clients account and when (s)he needs to

measure the power consumption. With regards to Fig-

ure 3 part B, messages were provided in orange, mak-

ing the user think that an error had happened when,

in fact, it was a message with instructions on how to

use the system. Finally, in Figure 3 part C, there is a

lack of information on loading time. If a report has a

lot of registers, the interface will only load the report,

which will freeze the screen.

Figure 3: Screens of the mobile application that contain us-

ability problems.

The complete evaluation of the mobile applica-

tion allowed us to identify improvement opportunities

from both functional and usability perspectives. Fig-

ure 4 shows an example of the new version of the mo-

bile application, after correcting the identiﬁed usabil-

ity problems. In these screens, a new circle appears

to indicate that the record has started so that users are

aware of state changes within the application (see part

A). Additionally, message colors were changed and

in-between processing messages were added (see Part

B). Finally, we standardized the reading screens and

improved the layouts, so that users do not have dif-

ﬁculty when understanding different screens during

readings (see Part C). These changes were made by

considering the feedback of the inspector and also the

feedback of the managers from the power company

who received the evaluation report and prototypes of

the corrected issues.

Practical Findings from Applying Quality Assurance Activities in the Development of Three Information Systems for Power Companies

163

Figure 4: Redesigned version of the application - interaction

of the meter reading through voice.

4.3 Project C

The proposed data registration templates allowed us

to register the developed features within the given

time stamp, the current version of the system, regis-

tration of the necessary conﬁgurations to use a mod-

ule, instructions for Building and Deployment, as

well as links with access to important external infor-

mation.

With regards to the use of Gitﬂow, Figure 5 shows

an example of how the team registered team mem-

bers’ activities in the Git version control tool. In this

example, two developers are registering their activ-

ities when working alone in a branch or collabora-

tively. Initially, master and develop create their cor-

responding branches, initializing the project. From

this point on, developers can work on separate feature

branches to be added to the develop branch. When

a merge with the develop branch occurs, developers

talk to each other to resolve conﬂicts. In addition,

when two developers work together on a branch of

a speciﬁc functionality, a speciﬁc nomenclature was

adopted indicating who is working on which part of

the functionality, allowing a better control of the ac-

tivities of the team members. At the end of the pro-

cess, merges occur in the branches feature, develop

and master, respectively.

5 LESSONS LEARNED

We were able to obtain lessons learned regarding the

application of functional and usability evaluation ac-

tivities as well as the version control activities. These

lessons are mainly based on focus group meetings and

discussions held with the development team of each

project at the end of the reaching of a project mile-

stone. We highlight that the discussion was held by

team members who participated in all projects, while

also considering the opinion of software engineers

Figure 5: History of implemented collaboration using Git-

ﬂow within Project C.

who provided feedback during their participation in

any of the projects.

The tests were affected by the ”communication

within the project environment”. A lot of information

regarding business rules and function speciﬁcations

was tacit (e.g. not documented, not thoroughly de-

scribed or not stored in the same place), which made

it difﬁcult to identify test scenarios after the model-

ing of the system was completed. Exploratory testing

allowed us to both understand the business rules and

revisit decisions that had been taken.

The view from the product owners also affected

the way in which the data would be presented. Sev-

eral changes were made to the design of the applica-

tion, including: new steps for performing tasks, new

data analysis and ﬁltering, changes in report presen-

tation, layout and interaction. The Variability of the

Functional Requirements affected the initially deﬁned

test scenarios. Thus, the changes must be monitored

in order to guarantee that the correct expected result

is being provided by the system. Each decision was

reported to both the development team and the testing

team during daily meetings. Also, the changes and

their impact were discussed with the clients so that

changes in the ﬁnal product would reﬂect the power

supply company’s expectations.

Exploratory testing can beneﬁt from considering

different types of test approaches. To select alterna-

tive scenarios for designing test scenarios in the ex-

ploratory testing, the development team applied the

use of functional testing strategies such as (Jovanovi

2006): equivalence partitioning, boundary value anal-

ysis and cause-effect analysis. Furthermore, although

we initially tried to automate the test scenarios to fa-

cilitate their replication in later sprints of the project,

ICEIS 2022 - 24th International Conference on Enterprise Information Systems

164

since the discussions with the clients included dra-

matic changes in the interface, the development team

had to change the testing strategy, using a manual

exploratory testing. This made the functional test-

ing process take longer than expected, but saved time

with: (a) rework in terms of programming new test

scenarios for the interface, and (b) not spending time

on automating test scenarios that would be removed.

We also gained insight on the use of usability ad-

hoc inspection for identifying problems and improve-

ment opportunities. When combining exploratory

testing and ad-hoc usability inspection, an experi-

enced inspector can reduce the time necessary to

check for different types of defects. Also, by sim-

ulating different usage scenarios, the test team can

verify to what extent these scenarios meet usability

principals, mainly when making mistakes during the

interaction, or changing between tasks and navigating

through the application.

When analyzing the disadvantages in the applica-

tion of the methods, we were only able to carry out the

evaluation due to the experience of the usability con-

sultant. Not all development teams may have such

experienced team members. However, by investing

some time and applying an appropriate checklist with

usability principals, an inexperienced inspector may

be able to identify similar problems. Furthermore, the

team had to deal with the delay of the identiﬁcation

and correction of the problems, as we carried them

out after the exploratory testing. Although the identi-

ﬁcation of usability problems and improvement sug-

gestions were welcome, these changes implicated in

further development time for correction, and another

round of testing and validation. In future projects, the

execution of evaluation approaches for different soft-

ware quality attributes should be executed together if

possible, to avoid such degree of rework. Another

alternative, given the appropriate human resources,

would be to carry out the usability evaluation during

the development of low ﬁdelity or functional proto-

types. This, however, was not our case, as the valida-

tion with the client was performed later in the project

due to the clients’ schedule, which also delayed the

execution of the usability evaluation.

Finally, although Gitﬂow is still under testing in

the development project, there was positive feedback.

Regarding the perceived usefulness of the approach,

there were comments related to the implemented or-

ganization, while obtaining the necessary information

for project management. Furthermore, there were

criticisms about learning the necessary steps to apply

Gitﬂow. The project manager indicated that this dif-

ﬁculty can be negative in the short term, but that, as

part of the organizational culture, it can bring bene-

ﬁts in the long term for the maintenance of projects.

His main concern was regarding the required training

and time spent for speciﬁc developers to play the roles

of master and develop, as these branches have high

credentials and errors could be dangerous to the con-

sistency of the project’s data and code. Furthermore,

regarding possible difﬁculties and suggestions for im-

proving the adopted approach, the team members ini-

tially indicated the adaptation to the process, due to

the work required to learn the technologies and rules,

as its use may be difﬁcult or discourage developers

with little experience. Additionally, the automation

of some activities of the process was suggested (e.g.

automated creation of tags to report changes) to im-

prove productivity.

6 CONCLUSIONS AND FUTURE

WORK

The applied software engineering approaches focused

on two quality aspects within the software organiza-

tion: product quality and project management. With

regards to the testing approaches focusing on prod-

uct quality, we: (a) adopted management tools and

artifacts to report the identiﬁed defects; (b) used col-

laboration tools that allowed us to set tasks, orga-

nize the different states of a bug (e.g. pass/failed, re-

ported, corrected, validated), made notes and use re-

minders; and (c) developed speciﬁc spreadsheets and

documents as a way to keep track of the different

decisions made, and which functional test scenarios

were removed, updated or created. As a result, ex-

ploratory testing allowed us to create updated docu-

mentation that could be used for further stages in the

development project, such as creating user manuals

and project reports. Additionally, the ad-hoc inspec-

tion process allowed us to identify further problems

from the point of view of users, which were not the

focus of the previous performed tests.

With regards to Gitﬂow adoption for project man-

agement, we noticed the acceptance of the proposed

process for quality assurance due to the positive feed-

back of the team members and that they are currently

using it in the project to better control its versions.

However, there was a unanimous concern in the short

term regarding the ease of use and learning of the var-

ious rules necessary for adopting the approach. Con-

sidering these issues, the organization is studying new

alternatives to automate or at least facilitate the use of

standard messages and steps.

One of the main limitations from our experience

reports is regarding the observations presented within

this paper. We gathered information from the records

Practical Findings from Applying Quality Assurance Activities in the Development of Three Information Systems for Power Companies

165

of our daily meetings, discussions held during devel-

opment, developed artifacts (documentation and re-

ports) and the obtained results measuring the success

of activities (e.g. number of identiﬁed problems).

However, there is still room for improvement, apply-

ing questionnaires and interviews with the team mem-

bers and carrying out focus groups with the develop-

ment teams of the three projects aiming at gathering

speciﬁc data on the applicability of the quality as-

surance activities and their acceptance in the future.

We intend to carry out further investigations so our

lessons learned can be useful for novice software de-

velopment teams willing to adapt their development

processes to achieve better results in terms of process

and product quality.

As new projects are developed within our software

organization, we expect that further software engi-

neering approaches and artifacts are incorporated and

that the lessons learned from such experiences are re-

ported considering both quantitative and qualitative

analysis methods. Through the lessons learned within

this paper and by providing details for its replication,

we intend to encourage software companies to adapt

software engineering approaches, cost-effectively im-

proving the quality of information systems.

ACKNOWLEDGMENTS

This work was supported by SijurI project funded

by Equatorial Energy under the Brazilian Electricity

Regulatory Agency (ANEEL) P&D Program Grant

number APLPED00044 PROJETOPED 0036 S01.

Additionally, this work was supported by the Foun-

dation for the Support of Research and Scientiﬁc

Development of Maranh

ao (FAPEMA), the Coor-

dination for the Improvement of Higher Education

Personnel (CAPES) and the National Council for

Scientiﬁc and Technological Development (CNPq).

REFERENCES

Bretal Ageitos, F. (2020). Project management platform for

the identiﬁcation of phytoplankton samples.

Collins, E. F. and de Lucena, V. F. (2012). Software test

automation practices in agile development environ-

ment: An industry experience report. In 2012 7th In-

ternational Workshop on Automation of Software Test

(AST), pages 57–63. IEEE.

Damian, A. L., Marques, A. B., Silva, W., Barbosa, S. D. J.,

and Conte, T. (2020). Checklist-based techniques with

gamiﬁcation and traditional approaches for inspection

of interaction models. volume 14, pages 358–368.

IET.

de Carvalho, J. M. I., da Silva, T. S., and Silveira,

M. S. (2016). Agile and ucd integration based on

pre-development usability evaluations: An experi-

ence report. In International Conference on Human-

Computer Interaction, pages 586–597. Springer.

Driessen, V. (2010). A successful git branching model.

Hassani-Alaoui, S., Cameron, A.-F., and Giannelia, T.

(2020). “we use scrum, but. . . ”: Agile modiﬁca-

tions and project success. In Proceedings of the 53rd

Hawaii International Conference on System Sciences.

Hron, M. and Obwegeser, N. (2018). Scrum in practice:

an overview of scrum adaptations. In Proceedings of

the 51st Hawaii International Conference on System

Sciences.

Jovanovi

c, I. (2006). Software testing methods and tech-

niques. volume 30.

Kamei, F., Pinto, G., Cartaxo, B., and Vasconcelos, A.

(2017). On the beneﬁts/limitations of agile software

development: an interview study with brazilian com-

panies. In Proceedings of the 21st International Con-

ference on Evaluation and Assessment in Software En-

gineering, pages 154–159.

Olausson, M. and Ehn, J. (2015). Source control manage-

ment. In Continuous Delivery with Visual Studio ALM

2015, pages 65–85. Springer.

Oprins, R. J., Frijns, H. A., and Stettina, C. J. (2019). Evo-

lution of scrum transcending business domains and

the future of agile project management. In Inter-

national Conference on Agile Software Development,

pages 244–259. Springer.

Plechawska-W

ojcik, M., Mora, S., and W

ojcik, Ł. (2013).

Assessment of user experience with responsive web

applications using expert method and cognitive walk-

through. ICEIS.

Quesada-L

opez, C., Hernandez-Ag

uero, E., and Jenkins,

M. (2019). Characterization of software testing prac-

tices: A replicated survey in costa rica. volume 7,

pages 6–1.

Rothenberger, M. A., Kao, Y.-C., and Van Wassenhove,

L. N. (2010). Total quality in software development:

An empirical study of quality drivers and beneﬁts in

indian software projects. volume 47, pages 372–379.

Elsevier.

Ruane, E., Smith, R., Bean, D., Tjalve, M., and Ventresque,

A. (2020). Developing a conversational agent with a

globally distributed team: an experience report. In

Proceedings of the 15th International Conference on

Global Software Engineering, pages 122–126.

Theocharis, G., Kuhrmann, M., M

unch, J., and Diebold, P.

(2015). Is water-scrum-fall reality? on the use of ag-

ile and traditional development practices. In Interna-

tional Conference on Product-Focused Software Pro-

cess Improvement, pages 149–166. Springer.

Wonohardjo, E. P., Sunaryo, R. F., and Sudiyono, Y. (2019).

A systematic review of scrum in software develop-

ment. volume 3, pages 108–112.

ICEIS 2022 - 24th International Conference on Enterprise Information Systems

166