![](bg5.png)
The tools and process developed have to be negotiated
- but as each company largely works on its own, usu-
ally a two-step development process evolves: (1) de-
velopment of the interfaces which concern more than
one partner (2) development of the features that con-
cern only one partner. For (1), one solution might be
a workshop which defines the interfaces and the im-
plementation plan (waterfall model), whereas for (2)
one company might use Scrum, and another one no
process at all because only one person is involved.
4.2 Goals
While the goal of software product development is
software, in a research project the resulting software
is one of multiple goals.
For the funding bodies, goals include the quality
of research, the scientific impact, the economic po-
tential as well as the positive publicity. Typically, re-
sults and progress are documented in reports. These
reports may contain descriptions and results of devel-
oped software, but the software itself is not delivered.
For the project partners, the importance of soft-
ware may vary. For industry partners, the software
may be the cornerstone of potential future products or
may be integrated into existing products. For research
partners, software may just be a means to answer the
research questions without any planned reuse after the
projects. Often, individual researchers’ foremost goal
is to complete research papers or a dissertation, deem-
phasizing software quality. Thus, the lifecycle of soft-
ware varies between different project partners. For
some, the prototype is a long-term result of the re-
search project while for others the prototype is only
a means to achieve results. Therefore, expectations
of software quality, especially regarding usability, re-
silience and tolerable bugs will differ.
The experts noted that the different goals of the
project partners and their project team members are
one important source of architectural and software de-
velopment process opinions, negotiations, and deci-
sions.
4.3 Processes
The typical software development process consists of
several, more or less similar steps: Strategy, Analy-
sis, Concept, Implementation, Test, Go-Live (Jacob-
son et al., 1999). In agile development these steps
are repeated to iteratively develop a prototype, em-
phasizing steps like implementation and test while
spending less time on specifications, etc. (Beck et al.,
2001). However, research project goals include usu-
ally some kind of textual documents (so-called deliv-
erables), where effort has to be spent on specifica-
tions. Based on these, the development starts, but -
as already known in traditional software development
models - these documents are produced once typically
and not adapted anymore - the software outdates the
documents at some point in time.
Development processes in research projects of the
interviewees typically followed a loosely coupled it-
erative process. Software components are developed
by partners and then integrated, e.g. at the end of
work packages or for important milestones like model
trials. While these processes are iterative, they are not
completely agile. One factor is the lack of coordina-
tion and transparency in planning tasks of a partner,
the other reason are the usually longer intervals be-
tween iteration compared to methods like SCRUM.
Furthermore, documentation cannot be deemphasized
as it is a result for the funding bodies, and testing
is often not sufficiently included in project effort and
time planning. The reasons for this are manifold: the
project goal is politically usually to do research, not
spend time on product development. On the other
hand, pilot applications are needed to prove project
results. Resources are limited - as they always are -
but to win a research project usually the innovative
features are stressed, not the standard requirements
for software in general (reliability, scalability, etc.).
Therefore, time for testing is cut. On the other hand,
some industry partners offer mature products to be
incorporated in the research prototype. While these
offer a high degree of maturity and usability, the re-
search project may clash with the established devel-
opment process of the product, causing for example
compatibility and prioritization conflicts between new
product and research features.
The lack of a central authority impacts develop-
ment processes not only due to lack of a process
owner, but also in terms of conflict management. Dif-
ferent views on requirements and effort estimates can
often not be resolved by researchers, who strive to
have a good working relationship, leading to a post-
ponement mindset. The interviewees stress the impor-
tance of clearly defined development phases and their
associated results. Multiple integration steps should
be planned to avoid a so-called big bang integration,
where all components are integrated at the same time
(they usually aren’t).
Additionally, the importance of a solid conflict
resolution process is common between all reviewed
projects. A single partner not achieving a develop-
ment milestone may lead to issues for all other part-
ners. Reasons for this may range from underesti-
mated technical challenges and employee turnover to
bankruptcy of a partner. In case of delays or partner
CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science
622