A Catalog of Process Patterns for Academic Software Projects
Caroline Guterres Silva and Lisandra Manzoni Fontoura
Programa de Pós-Graduação em Ciência da Computação, Federal University of Santa Maria (UFSM), Brazil
Keywords: Software Process, Process Patterns, Research-based Software Project, University Partnership.
Abstract: Universities have established partnerships with industry or government through technological innovation
projects to develop solutions based on problems presented by institutions. Based on a systematic literature
review, we identified a lack of software processes suitable for projects developed in academia. This article
proposes a catalogue of process patterns documenting practices that have been successfully adopted in
academic projects involving external partnerships. Process patterns describe solutions to problems and
challenges commonly found in projects developed in the university environment. We conduct a systematic
literature review to identify problems commonly encountered in academic projects and the software
practices applied to solve them. Later, with the help of the literature, we deepened the understanding of how
the software practices can be used in software projects and documented them as process patterns. As a result,
we have identified thirteen problems and documented ten process patterns describing possible solutions
related to the problem. Eight researchers with experience in software projects in partnership with academia
participated in the validation. The validation showed that the proposed process pattern catalogue describes
relevant solutions to the problems and is applicable to the academic context.
1 INTRODUCTION
Due to the growing relevance of knowledge and
research for economic development, the role of the
university needs to be reviewed, as well as focusing
on teaching, research, and extension activities; it has
the mission to assist in economic development. For
this, it is necessary to bring the university closer to
other sectors of the economy, establish partnerships
with industries and the government, aiming to
propose innovative solutions to the problems found
in these organizations (Damoc, 2017).
However, it should point out that there are
differences between these institutions in terms of
culture and goals. In a simplistic view, the
government is oriented towards economic
development, universities towards knowledge, and
industries oriented profit, representing three
different environments (Mineiro et al. 2019).
In academic projects in collaboration with other
institutions, the chosen practices also need to be
suited to the project environment. It appears that
there is a challenge, considering the environment of
collaboration between institutions, which makes it
necessary to identify a software development
approach that benefits both parties involved.
According to a systematic literature review
conducted in 2020 (Silva et al., 2020), we see a lack
of software processes suitable for research projects
developed in academia in partnership with industry
or government. The research showed that there are
cultural and organizational differences between
institutions. These differences must be considered
when choosing appropriate practices for joint
software development. Several articles report
experiences or case studies in this context, but the
knowledge is not systematized (Brondani et al.,
2019), (Dias et al., 2013), (Cereci and Karakaya,
2018), and (Andrade et al. 2017).
This work proposes a catalog with the
recommendation of software development practices,
described as process patterns, for use in projects
developed in academia in partnership with industry
or government. In this way, an analysis was carried
out in the literature seeking to identify the problems
and challenges identified in the university
environment in the context of software development
in partnership with other institutions, and solutions
were linked to these problems, allowing, later, the
documentation of process patterns.
The remainder of this paper is structured as
follows. Section 2 describes the method used to
Silva, C. and Fontoura, L.
A Catalog of Process Patterns for Academic Software Projects.
DOI: 10.5220/0011090700003179
In Proceedings of the 24th International Conference on Enterprise Information Systems (ICEIS 2022) - Volume 2, pages 175-182
ISBN: 978-989-758-569-2; ISSN: 2184-4992
Copyright
c
2022 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
175
build and validate the software process catalog.
Section 3 explains how we document the process
patterns. In Section 4, we describe the validation of
the work. Section 5 summarizes our approach, its
results, our contributions, and future work.
2 RESEARCH METHOD
The software process patterns aim to assist the
development team in making decisions regarding the
choice of best software practices, allowing better
management of resources, activities, and artifacts that
involve software projects developed at the academy in
partnership with other institutions. For the elaboration
of the catalogue of process patterns, three activities
were followed (see Figure 1), which are:
Figure 1: Phases of the research method.
a) Identification of problems in academic
projects: identification of problems related to
software projects developed in universities in
partnership with other institutions from the
literature;
b) Association of software practices
successfully adopted in real projects to address the
problems identified previously;
c) Documentation of the process pattern
associating the problems found with the solutions
described in the literature as software practices;
d) Validation of the work through interviews
with researchers and professionals who develop
software in universities in partnership with other
institutions.
3 CATALOG OF PROCESS
PATTERNS
This section details the activities we follow to
document process patterns.
3.1 Identification of Problems in
Academic Projects
Based on the specialized literature, we identified
problems faced in software projects developed in
universities with partnerships with other institutions.
We searched the following databases: IEEE Xplore,
ACM, Scopus, and academic Google. The inclusion
criteria for the works were: having been published
between 2011 and 2020 and describing real
experiences.
From the analysis of the works, we list thirteen
problems that were cited by the works that are
described below.
High Turnover (p1): Brondani et al. (2019)
report that because the software teams are formed by
undergraduate or graduate students, they remain in
the project for an average of two years, resulting in a
high turnover in the team. Cereci and Karakaya
(2018) point out the turnover among undergraduate
students as a critical problem that causes the loss of
knowledge and some divergences from the project
plan.
Part-time Availability (p2): several works
report that academic teams are formed by
undergraduate and graduate students (Brondani et
al., 2019; Dias et al., 2014; Cereci and Karakaya,
2018; Andrade et al., 2017). These students need to
split time between the course and their research,
participating in the projects part-time that can
negatively affect the progress of the projects.
Communication Problems (p3): the availability
of part-time impacts the reduction in the frequency
of meetings. Cereci and Karakaya (2018) comment
that the less frequent the project meetings, the less
information researchers have about the status of the
project and the progress of other researchers. The
hierarchical communication system that exists in
some industries or government environments makes
communication between the team and stakeholders
difficult, causing the absence or delay in responding
to questions raised by the project team (Brondani et
al., 2019; Dias et al., 2014; Andrade et al., 2017).
Unclear Division of Responsibility (p4): Cereci
and Karakaya (2018) highlight that university teams
are dynamic, so the roles responsible for performing
each activity are not well established. Another issue
is that the experience level of the university team is
lower compared to industry teams.
Lack of Familiarity with Project Domain (p5):
Brondani et al. (2019) and Andrade et al. (2017)
describe difficulties related to understanding the
business domain and the activities carried out by
partner industries. This difficulty results in a demand
for additional time to understand organizational
processes before defining requirements.
Workers with Different Skills (p6): an
academic team consists of individuals with different
capacities. According to Cereci and Karakaya
ICEIS 2022 - 24th International Conference on Enterprise Information Systems
176
(2018), undergraduate students have less experience
and know-how than industry professionals.
Complexity of Solutions (p7): partner
institutions look to universities to develop complex
and innovative solutions that require research to
solve problems (Brondani et al., 2019). Crawrford
(2002) point out that as complexity increases,
effective communication becomes critical to project
success.
Unstable Requirements (p8): innovative
software development makes it difficult to define a
stable set of software requirements. The trend is that
the requirements evolve throughout the project as
the results are obtained in the research developed.
This iterative development implies changes in the
specifications (Brondani et al., 2019; Dias et al.,
2014; Cereci and Karakaya, 2018; Andrade et al.,
2017).
Little Contact with Customers/users (p9):
Cereci (2018) describes that, in some academic
projects, the end-users do not participate in the
project, not interacting with the team. In other
projects, end-users only engage in requirements
elicitation activities and provide feedback on
progress. Some authors cite the difficulty in finding
users to perform acceptance tests of the developed
software (Andrade et al., 2017; Dias et al., 2014).
Difficulty in Marketing Products (p10):
according to Dias et al. (2014), product marketing is
an issue for academic projects. This problem is
justified by the fact that the partner institution is
interested in obtaining the exclusive commercial
right of the product (Dias et al., 2014; Cereci and
Karakaya, 2018; Andrade et al., 2017).
Difficulty in Publishing Research Results Due
to non-Disclosure Agreements (p11): Andrade et
al. point out that in projects with other institutions,
non-disclosure agreements (NDAs) are most often
signed to protect the knowledge of hardware and
software made available during the execution of the
project, as well as information obtained in visits or
meetings. These agreements may limit the
publication of research results, which are needed
success indicators for university projects.
Divergent Visions/Goals (p12): Dias et al.
(2014), Cereci and Karakaya (2018), and Andrade et
al. (2017) report that the university and the industry
have divergent objectives with the project being
developed. Andrade et al. (2017) report that, in the
eyes of the industry, the academy has only
theoretical knowledge, while, for the academy, the
industry has only practical knowledge. These
different views can lead to conflicts that need to be
resolved for projects to achieve their goals.
Feedback Delay by Delivery Stakeholders
(p13): Andrade et al. (2017) describe that many
projects lack adequate and timely feedback from
stakeholders, thus causing a delay in software
development.
3.2 Documentation of the Process
Pattern
After mapping the problems encountered in software
projects in the context of the university, we
identified software development practices that have
been used successfully to reduce the impact of each
issue. We rely on the literature and consider only
works that describe experiences of software projects
developed in academia. For the description of each
software process pattern (PP), we use the following
properties: purpose, problem description, and
solution.
a) PP1: Develop Business Process Diagrams
Purpose: helps the team understand the business
domain related to the software that will be
developed. Creating a business process diagram
makes it easier to understand an organization's
business processes and helps the team understand,
specify, and prioritize software requirements.
Problems (p1,p8): the software team needs to
understand the business domain, as this domain
influences the understanding and specification of
software requirements. Understanding the business
domain is a complex activity for developers, as they
are unfamiliar with it. In many situations, some
manuals provide domain information but are easy to
understand, which complicates the understanding
and learning of organizational processes for the
team. The lack of knowledge of terms related to the
business process impacts the communication
between the development team and the client.
Brondani et al. (2019) cite in their work the
difficulties encountered in understanding military
doctrines for the development of a tactical virtual
simulator for military training.
Solution: for the elaboration of business process
diagrams, the team collects information about this
domain and documents specific terms to facilitate
the tasks related to requirements management
(Prieto-Díaz, 1990). Brondani et al. (2019) describe
that the adoption of business diagrams, in addition to
helping the team to understand the project domain,
improved the communication flow between the team
and the stakeholders.
b) PP2: Iterative and Incremental Process
Purpose: a life cycle for the software process that
uses short development cycles called iterations. At
A Catalog of Process Patterns for Academic Software Projects
177
the beginning of the iteration, the requirements that
add the most value to the customer's business are
prioritized. At the end of the iteration, an operational
version is delivered to the client.
Problem (p12): it is unrealistic to define a set of
requirements at the outset of the project and to
expect these requirements to remain unchanged
during development. In academic projects, there is
more uncertainty than in industrial projects, which
causes difficulty in defining stable requirements.
Many requirements depend on the results of research
carried out during the project.
Solution: the iterative and incremental approach
allows improving scenarios in which changes are
inevitable and, thus, controlling the resulting risks
(Schwaber and Sutherland, 2020). Beck (2000) and
Fowler (2004) describe that development should be
carried out in short, iterative cycles (1 - 4 weeks), in
which the result of the next iteration is an increment
of improved work. In this way, advances obtained in
the research carried out in the project can give rise to
requirements that will be implemented in subsequent
iterations.
c) PP3: Definition of Individual Research
Goals
Purpose: individual research must be defined
from the project objectives, aiming to delimit the
research context of each member of the project.
Personal projects may lead to end-of-course work,
master's dissertations, and doctoral theses.
Problem (p2): the more innovative the project,
the more complex the solutions are, and in many
cases, they are required to test various alternatives.
Therefore, several personal projects can be defined
from an innovative academic project.
Solution: due to the complexity and the different
possible alternatives for solving the problem,
research subjects with clear objectives can be
isolated so that they can generate research projects
to be developed by researchers or undergraduate and
graduate students.
Brondani et al. (2019) describe in their study as a
solution to this problem the identification of research
problems that may be explored in final papers or
master's dissertations carried out under the
supervision of a researcher in the area. The authors
suggest that if the research results are successful and
achieve the desired objectives be incorporated into
the software developed in the research project. It
should be noted that more than one research project
can be conducted simultaneously to analyze
alternatives to achieve a goal.
d) PP4: Refactoring
Purpose: elimination of unreadable or
unnecessary code.
Problem (p13): as identified in the systematic
literature review and related work, academic teams
are made up of people with different skill levels who
stay on the project for a while (high turnover).
Therefore, the lack of experience of some team
members impacts the production of understandable
and easy-to-maintain software.
Solution: Brondani et al. (2019), describes that
before milestones, the team can plan tasks for code
refactoring, aiming to improve readability and
documentation, in addition to removing unnecessary
lines of code.
e) PP5: Define Persons Responsible for
Communication between Teams
Purpose: define one person on the academic
team and one on the customer team as a point of
contact for clarifying questions or providing
information.
Problems (p1, p9): Brondani et al. (2019)
describe that hierarchical communication can cause
a delay in software development since a question
and its answer need to go through several levels in
this communication structure.
Other works cite the lack of involvement of the
user or the client in academic projects (Dias et al.,
2014; Cereci and Karakaya, 2018; Andrade et al.,
2017). Dias et al. (2014) describe that, in most cases,
the client's participation occurs only at the end of the
project.
Solution: to simplify communication between
teams, this pattern suggests defining one person on
the academic team and another on the partner team
as a point of contact for resolving questions.
They are responsible for receiving the
information and making it available to team
members interested in that information. They also
need to meet the needs of the partner team to
provide information and answer questions.
f) PP6: Full-time Contract Workers
Purpose: hire full-time professionals for the
development team. These professionals are
responsible for maintaining project history and
passing on knowledge to team members, minimizing
the effects of turnover among team members.
Problem: academic teams have many members
who are university students and stay on the project
for the duration of a course. As such, these students
balance the teaching activities with the project
activities.
Furthermore, according to Andrade et al. (2017),
project members often participate in research to
ICEIS 2022 - 24th International Conference on Enterprise Information Systems
178
produce scientific publications, participating in
conferences looking for solutions to proposed
challenges. Other works explore the high turnover of
the team and the participation of a large part of the
team on a part-time basis.
Solution: to minimize the risks of high turnover
and a large number of part-time and inexperienced
workers, Brondani et al. (2019) and Andrade et al.
(2017) suggest hiring experienced full-time
professionals to manage team members and retain
the knowledge of the project.
g) PP7: Collaborative Work
Purpose: allow a collaborative software
development environment to complement individual
skills and knowledge, minimizing failures and,
consequently, producing better results concerning
the development process of a software product.
Problems (p7, p8, p13): the high turnover of
team members can lead to a loss of knowledge
regarding advances made in research challenges and
on knowledge of the business domain and software
requirements.
The low frequency of meetings and the part-time
dedication of a large part of the team can generate
communication problems between project members
and between them and the client.
The university teams consist of many
undergraduate and graduate students, which results
in divergent skill levels among team members and a
high turnover rate as they stay on the project while
they take their courses.
Solution: according to Brondani et al. (2019),
team members can learn from each other, sharing
information about the business domain and
requirements and, in this way, disseminating
knowledge about the system being developed.
Knowledge sharing between team members can be
encouraged by using practices such as pair
programming and code review.
h) PP8: Review Material before Publication
Purpose: establish agreements regarding the
objectives and visions of the different institutions
involved in the project, and define a process for
reviewing publications.
Problems (p4, p5): considering the project
development environment in partnership with
academia, Andrade et al. (2017) indicate that
universities and industry have differing interests and
attitudes regarding the publication of project results.
The industry does not show interest in publishing
scientific papers due to the disclosure of strategic
information. Academia needs publications to
improve its productivity indicators.
Solution: Andrade et al. (2017) propose to solve
this problem the definition of an agreement in which
the academy must previously send the works and
articles produced under the project for review by the
partner. Only after approval, the academy may make
project-related content available to third parties. This
mechanism guarantees the partner that only
information authorized by it will be published.
i) PP9: Regular Meetings
Purpose: organizing regular meetings improves
communication among team members, helps in
establishing and tracking goals and objectives.
Problems (p1, p5): it appears that as the team
meets less frequently, employees have less
information about the status of the project and the
progress of activities, affecting communication
between those involved in the project and control
(Cereci and Karakaya, 2018).
Solution: the adoption of regular meetings
between project team members allows for an
overview of the project's progress, continuous
feedback, and the reporting of impediments that
affect the performance of activities by team
members (Andrade et al., 2017). The frequency will
depend on the team availability, but the idea is that
they are in very short intervals.
j) PP10: Project Plan Definition
Purpose: the project plan outlines the project
goals, sets out the responsibilities of each partner,
deadlines, and budgets for the development of the
project. The project plan establishes warranty terms
concerning the software product.
Problem (p1, p2, p3, p5, p11): Changes can
result in software development delays, causing
additional costs (Andrade et al., 2017).
Solution: The work plan is a formal document
that outlines the project's goals, specifies the tasks,
and indicators for monitoring the goals. Once drawn
up, it must be approved by all parties (Andrade et
al., 2017). It is verified that, through a work plan, it
is possible to establish the project planning, avoiding
possible misunderstandings and assisting in the
communication of those involved in the project.
The plan should describe the rules that govern
the partnership agreement, such as clauses regarding
confidentiality, publication of results, percentage of
royalties, rights, and duties of each institution.
4 STUDY VALIDATION
A case study is carried out to study a single entity or
phenomenon in a given time frame. Case studies
help to assess the benefits of process and tools and
A Catalog of Process Patterns for Academic Software Projects
179
provide a cost-effective way to ensure that process
changes predict desired outcomes (Kitchenham and
Pfleeger, 2002).
According to Wohlin et al. (2003), if the effect of
a process change is widespread, a case study is more
suitable. The effect of change can only be assessed
at a high level of abstraction because process change
includes smaller and more detailed changes
throughout the development process. Based on the
literature (Wohlin et al., 2003; Runeson and Höst,
2009), we define the following steps:
1) Conception and Project
In this step, we define the objectives, the
research hypotheses, how such hypotheses would be
evaluated and the results obtained.
This case study aims to verify the applicability of
the proposed process patterns in software projects
developed in academia with industries and/or
government. Experienced developers were invited to
assess the applicability of the process patterns
considering academic projects with external
partnerships already developed by them.
We defined a set of hypotheses based on the
documentation of process patterns to guide the
validation of this study. For each problem (p)
associated with the proposed process pattern (PP),
we define a hypothesis (h), as shown in Table 1. The
hypotheses are:
[h1] Adopting business process diagrams facilitates
team communication with stakeholders;
[h2] The elaboration of business diagrams helps in
understanding the application domain;
[h3] Using an iterative and incremental process can
minimize the number of requirements change
requests;
[h4] Individual research projects can contribute
solutions to complex systems;
[h5] Constant code review can improve code
readability and documentation and thus minimize
rework;
[h6] The appointment of a person responsible for the
flow of information can solve communication
problems;
[h7] Those responsible for the communication flow
help to resolve doubts whenever necessary,
increasing the client's contact with the team;
[h8] Full-time workers assist in managing team
members and managing the history and sharing of
information, allowing for continuity in the project;
[h9] Full-time worker management allows more
experienced collaborators to share knowledge about
the project domain;
[h10] Collaborative work allows everyone to have
information regarding the software project;
[h11] From collaborative work, it is possible to share
information from the application domain, keeping
the team with the same level of knowledge regarding
the development of the project;
[h12] Collaborative work allows more experienced
professionals to share their knowledge in a way that
empowers employees and improves their skill level;
[h13] Reviewing reports and articles before
publication allows for analysis and authorization of
published information;
[h14] The agreement regarding the publication of
information allows establishing guidelines on the
results of the software product, considering each
institution;
[h15] More frequent meetings help communication
in the project;
[h16] Periodic meetings facilitate contractual policy
issues;
[h17] Performing the software work process
definition allows for effective communication in the
project;
[h18] The problem regarding the division of
responsibilities can be solved by defining a work
plan;
[h19] Workplan helps in the context of the
complexity of software solutions;
[h20] In the work plan, it is possible to define
questions regarding the commercialization of
products;
[h21] Contractual guidelines can be defined through
a work plan.
2) Preparation for data collection:
We used a questionnaire, prepared in Google
Forms, as a data collection method, thus allowing a
better understanding of the problem situation based
on the participant's experience. The questionnaire
shows information about the description of each
pattern, explaining the related problem, the
suggested solution, and, when available, the
dynamics of the process pattern's execution. Then
the assumptions are shown, and the participant must
assess the extent to which the hypothesis is satisfied
by the proposed process pattern.
Table 1: Association of hypotheses (h) to process patterns (PP) and problems (p).
PP1 PP2 PP3 PP4 PP5 PP6 PP7 PP8 PP9 PP10
p
1
p
8
p
12
p
2
p
13
p
1
p
9
p
7
p
10
p
7
p
8
p
13
p
4
p
5
p
1
p
5
p
1
p
11
p
2
p
3
p
5
h1 h2 h3 h4 h5 h6 h7 h8 h9 h10 h11 h12 h13 h14 h15 h16 h17 h18 h19 h20 h21
ICEIS 2022 - 24th International Conference on Enterprise Information Systems
180
The target audience is classified as professionals
in the software development area who participate or
have participated in a project that involves
collaboration between academia and industry and/or
government and has experience in this context.
We selected participants through convenience
sampling, looking for projects related to the research
topic on the web and in projects known to the
authors of the work. Based on these selection
criteria, we invited ten professionals and, of these,
eight responded.
3) Collection:
The questionnaire describes twenty-one closed
questions and a descriptive open question. We used
Likert Scale ranging from strongly agree (5) to
strongly disagree (1) to evaluate each closed
question. We selected participants through
convenience sampling, looking for projects related
to the research topic on the web and in projects
known to the authors of the work. Based on these
selection criteria, we invited ten professionals and,
of these, eight responded. The questionnaire
describes twenty-one closed questions and an open
question.
4) Analysis:
In this step, the information collected was
analyzed in order to determine the applicability of
the process pattern to the described problem. Section
4.1 highlights the results of this analysis.
4.1 Results and Discussions
For each hypothesis defined in Section 5,
participants indicated whether or not they agree with
the hypothesis. We defined the following options: 5
- strongly agree, 4 - partially agree, 3 - neither agree
nor disagree, 2 - partially disagree, and 1 - strongly
disagree. Figure 2 shows the frequency distribution
of participants' responses.
Regarding the hypotheses (h4, h6, h7, h8, h9,
h10, h11, h12, h13, h14, h17, and h18), the
participants agree with the solution defined through
the process pattern for the associated problem. For
hypotheses h3, h5, h15, h16, h19, h21, a minority of
participants remained neutral in the evaluation of the
process. It is noteworthy that the others strongly or
partially agreed with the proposed pattern.
For h20, one of the participants strongly
disagreed that the Project Plan Definition (PP10) can
be a solution to the problem "Difficulty in marketing
products" (p3). In this specific case, we complement
the process pattern by defining the adoption of a
contract with the rights of each institution,
specifying the authors involved in the development
of the software, and defining issues regarding
intellectual property and commercial use rights for
the partner institution. After collecting and analyzing
the participants' responses, we concluded that the
proposed process pattern describe good solutions to
the main problems encountered in software
development projects carried out at universities with
external partnerships.
Figure 2: Frequency analysis of participant’s responses.
A Catalog of Process Patterns for Academic Software Projects
181
5 CONCLUSIONS
In this work, we searched the literature for studies
that identify problems present in software projects
developed in universities with external partnerships.
After identifying the problems, we look for solutions
successfully applied to real projects. Then, we
document these solutions as process patterns.
For validation, we define hypotheses that aim to
assess the applicability of the process pattern to
solve each associated problem. These hypotheses
were evaluated by experienced professionals who
have participated in academic projects with external
partnerships. We had participants from the three
institutions involved. The results obtained in the
evaluation were positive considering that the
participants agreed with the proposed process
patterns. There is a deficiency in the software
process literature that considers the characteristics of
software development projects in universities with
external partnerships. These projects have different
features from projects developed by the industry,
requiring processes tailored to this reality.
We cite as threats to the validity of the study, the
fact that the participants were invited by the
researchers to participate in the experiment. In
addition, the number of participants could have been
higher. However, we highlight the difficulty of
finding participants with the desired profile.
We requested that the hypotheses be evaluated
based on experiences in a real software development
project developed at universities with external
partnerships but we do not have information about
the projects considered in the evaluation.
As future work, we will experiment with the
proposed process patterns in a software project
developed at our university.
ACKNOWLEDGEMENTS
We thank the Brazilian Army and its Army Strategic
Program ASTROS for the financial support through
the SIS-ASTROS GMF project (898347/2020).
REFERENCES
Andrade, R. M. C., Lelli V., Castro, R. N. S. and Santos, I.
S. (2017). Fifteen years of industry and academia
partnership: lessons learned from a brazilian research
group. IEEE/ACM 4th International Workshop on
Software Engineering Research and Industrial
Practice (SER&IP), pp. 10-16.
Beck, K. (2000). Extreme Programming Explained.—
Embrace Change. Addison-Wesley Professional.
Brondani, C., Mello, O. and Fontoura, L. (2019). A case
study of a software development process model for
SIS-ASTROS”. In The 31st International Conference
on Software Engineering and Knowledge Engineering,
Lisboa, pp 600-605.
Cereci, I. and Karakaya, Z. (2018). Need for a software
development methodology for research-based software
projects. In 3rd International Conference on Computer
Science and Engineering, Sarajevo: pp. 648-651.
Crawrford, L. (2002). Profiling the competent project
manager. In: Slevine, Cleland and Pinto (Edts), the
frontiers of project management research (pp. 151-
176). Newton Square, PA: Project management
institute.
Damoc, A. I. (2017). The strategic role of partnerships
between universities and private corporations as a
driver for increasing workforce competitiveness in a
global economy. Proceedings of the International
Conference on Business Excellence.
Dias, D. M. P., Kodikara, N. D. and Jayawardena, M.
(2013). The need for novel development
methodologies for software projects in universities: a
Sri Lanka case study. In: International Journal of
Future Computer and Communication v.1: 494–98.
Fowler, M. (2004). Using agile software process com
offshore development. https://martinfowler.com
/articles/agileOffshore.html.Acesso em: Julho, 2021
Kitchenham, B. and Pfleeger, S. (2002). Principles of
survey research part 2: designing a survey. SIGSOFT
Softw. Eng. Notes, pp. 18–20.
Marijan, D. and Gotlieb, A. (2020). Industry-Academia
research collaboration in software engineering: The
Certus model. Information and Software Technology.
132. 106473. 10.1016/j.infsof.2020.106473.
Mineiro, A., Souza, D. L., Vieira, K. C., Castro, C. and
Brito, M. J. (2019). Da Hélice Tríplice A Quíntupla:
Uma Revisão Sistemática. Revista Economia &
Gestão. 18. 77-93.
Prieto-Díaz, R. (1990). Análise de domínio: uma
introdução. SIGSOFT Softw. Eng. Notes 15, 2 (abril de
1990), 47–54.
Runeson, P. and Höst, M. (2009). Guidelines for
conducting and reporting case study research in
software engineering, Empir. Softw. Eng., vol. 14, no.
2, pp. 131– 164, 2009
Schwaber, K. and Sutherland, J. (2020). O guia do scrum:
o guia definitivo para o Scrum as regras do jogo.
Silva, C. G., Filho, E. L. F, Fontoura, L. M. (2020)
Software Processes Used in University, Government,
and Industry: A Systematic Review. In The 22nd
International Conference on Enterprise Information
Systems. pp. 314-321
Wohlin C., Höst M. and Henningsson K. (2003).
Empirical research methods in software engineering.
Springer.
Yin. R. K. (2005). Estudo de caso: planejamento e
métodos. 3 ed., Porto Alegre: Bookman.
ICEIS 2022 - 24th International Conference on Enterprise Information Systems
182
