According to Brambilla; Cabot; Wimmer [13], models are first-class artefacts of software development based on Model-Driven Engineering (MDE). On the other hand, Model-Based Engineering (MBE) is a process in which software models play an important role, but they are not necessarily key artefacts of the development, as is the case of models created to document systems.
iStar [8][9] is a goal-based modelling language proposed to represent software at the requirements level. It has been used in MBE and MDE industrial projects. In [7], the authors describe practical applications of iStar in the industry, such as analysis of the adoption of open-source software ecosystems [18] and regulatory compliance in aviation security [17]. Sharing successful experiences using the iStar in industrial projects encourages the adoption of the language in future projects. It also presents a way to go and identify problems to be avoided. Some studies have been developed relating iStar to the agile methods. iStar was used to represent social aspects of the Scrum process and identifying key factors for the success or failure in [11]. The integration between iStar and Scrum was presented to map the organizational dependencies between the actors in the process [14]. The usage of iStar for planning and monitoring sprints in a project based on Scrum was presented as an experience report in [16].
Thus, we have chosen iStar due to its potential in the modelling of industrial projects and agile projects. However, the use of the iStar in an agile industrial project to evolve an application has not been explored. This paper presents an experience report about the usage of iStar in an agile modelbased industrial project to evolve an e-commerce application. iStar was used to represent the current context of the application and new functionalities to be included in the solution. A questionnaire applied to the participants points to some benefits, such as increasing the project knowledge level.
The paper is structured as follows: Section 2 presents the context of the project, Section 3 describes the experience of using iStar in the project, Section 4 reports the main results of a questionnaire applied to the project team to evaluate the usage of iStar and Section 5 shows the conclusions and future work.
This research was performed in a technology company with an enterprise digital commerce platform that enables brands and retailers to achieve faster time-to-market, reach their customers across any channel, and uncover new growth areas. This company has about 1200 employees in 32 different countries.
The company has been developing a project in collaboration with Universidade Federal do Ceará -Campus Quixadá in Brazil to evolve the platform administrative tool. Due to the COVID-19 pandemic, this project has been executed online. The project team has 11 participants, whose profile is detailed in Table 1. Initially, we interviewed members of the support team and applied a survey to understand the context and needs. Next, a set of HCI/UX techniques were applied. The CSD matrix2 was created to clarify Certainties, Suppositions and Doubts. A proto-persona [12] was created to represent a set of users and their interests. Scenario and User journey [10], which are empathy techniques, were used to understand the limitations and the users' needs. We also used UX canvas [2] to describe the proposal of experience to clients and users, representing their goals, resources, and artefacts. Following, we performed a set of steps (almost all related to modelling) to understand the existing system and represent the new features to be introduced. We modelled an overview of the system using Service Blueprint 3 . Next, we used iStar to model the administrative module of the system AS-IS. A brainwriting session [1] was performed to understand better the new features to be developed. Finally, the iStar model TO-BE was created. It was used as input to the creation of the prototypes and UML models. Prototyping, creation of UML models, coding and testing has been occurring incrementally.
Tasks 1-7 and 11 were performed by the designer trainees and the design leader. During tasks 1, 4, 5 and 9, the design team performed the requirements elicitation. Tasks 12 and 13 were performed by developer trainees and technical leader. Tasks 8-10 were performed collaboratively by all team members.
This paper focuses on describing the usage of iStar in this project. So, a detailed step-to-step is presented in the next section to describe the use of iStar.
iStar was used to represent the application AS-IS and represent the new functionalities of the system in development (application TO-BE). All steps were performed online due to the COVID-19 pandemic. One of the participants (Rch in Table 1) has large experience with iStar modelling and conducted the use of iStar. Other participants had not previous experience with iStar.
The first step was to train the project team in iStar, following three steps:
• Theoretical presentation: Presentations of slides with the history, syntax and examples of iStar; • Practical use of iStar: collaborative modelling of an example with iStar to practice the concepts; • Questionnaire about iStar models: We applied a questionnaire with iStar models and questions about the understanding of these models. The total of training was 4 hours. There is no collaborative online tool available, which allows creating an iStar model by different modellers simultaneously. So, we had to improvise collaboration using piStar 4 to create the models. We listed below some observations identified during this phase:
• A great part of the team did not identify the and-refinement and or-refinement correctly;
• Contribution, participates-in and is-a are represented by the same arrow with a textual marker to specify their kind, which causes confusion to some participants. Following the AS-IS modelling was performed. All participants accessed the platform previously, and each one had different levels of knowledge of the system. Design trainees performed a great part of the initial exploratory tasks, so their knowledge level was greater than other participants. We presented a short textual description of the system to be used as a starting point. This textual description was based on the service blueprint model and other previous results.
Thus, we performed a collaborative modelling of the system AS-IS following a DOJO-like [3] approach. Each participant had between 3 and 5 minutes to comment, add, modify, or remove modelling elements. Three iterations were necessary to finish the modelling. At the end of each iteration, the team discussed for about 15 minutes.
We started with the modelling of the SD diagram, whose final version had 2 agents, 5 actors, 5 participates-in and 1 dependency. Then, we move on to modelling the SR diagram, whose final version overview is shown in Figure 2-left.
We reached a modelling saturation (at which point it was not possible to add more elements to the modelling, and there was no more discussion/divergence among the participants) after three hours. The use of iStar was important to unify and discuss the different views on the application, by the end of the AS-IS modelling. The participants reached a consensus on their views and a common ground on the project.
TO-BE modelling was also performed through a DOJO modelling section similar to the previous one. We used SD and SR diagrams AS-IS as the start point of TO-BE modelling. The results of requirements elicitation were used as basis to the iStar modelling. We executed modelling moments (about 1 hour and a half each one) on two different days to reach saturation. The final version of the TO-BE SD diagram had 3 agents, 14 actors, 5 roles, 19 participates-in and 8 dependency links. Then, we move on to modelling the SR diagram, whose overview of its final version is shown in Figure 2right. For reasons of project confidentiality, it will not be possible to show a readable version of the generated models.
We identified some problems during the modelling: 1) The need for a collaborative modelling tool to give more autonomy to the participants; and 2) The iStar SR model TO-BE has many nodes and links, so we had scalability problems during its creation.
The usage of iStar in this project increased the team's knowledge of the team about the application to be evolved and the new features (see Figure 3 for more details). Consequently, this increase in understanding made the execution of the next steps (prototyping, UML modelling, coding, and test) easier. The iStar models generated were used as the base for prototyping and UML modelling.
This section presents the results of the evaluation. main objective of this study is to analyse the team's viewpoint about the usage of iStar in the mentioned industrial project. We created a survey with 14 questions presented in Table 2.
Evaluation Questionnaire. Questions 1) Describe how was the use of iStar 2) Were there strong points? List them 3) Were there weaknesses? List them 4) What are your observations about using iStar regarding communication and knowledge levelling of the project context? 5) Mark your knowledge level about the context before the use of iStar (scale from 0 -10) 6) Mark your knowledge level about the context after the use of iStar (scale from 0 -10) 7) Was there an increase in your knowledge about the context? 8) Mark your knowledge about the new features before the use of iStar (scale from 0 -10) 9) Mark your knowledge about the new features after the use of iStar (scale from 0 -10) 10) Was there an increase in your knowledge about the new features? 11) Would you recommend (or not) the use of iStar in other projects? Why? How? 12) Did you have difficulties during the modelling? List them 13) What could be different in the method used? 14) Is there anything not commented yet that you would like to share?
A pilot was applied with a non-participant of the project and we made corrections. The questionnaire was applied to 10 members of the project (the member that created the questionnaire did not answer it), whose profile was presented in Table 1. The results will be presented in three categories of analysis: 1) positive points; 2) negative points; 3) evolution in understanding.
Regarding the positive points, they were mentioned in questions 1, 2, 4, 7, 10 and 11. The most mentioned advantage by the participants was the support given by the modelling to the learning and understanding about the context and the problem of the project, as well as about the features and customizations to be implemented. Examples of this vision are: "With the modelling moments, it was possible better understand the current solution and the solution we want to deliver" (DvT); "It helped to have a more holistic view of the system and its actors." (DgL). Another positive point was the alignment between team members provided during the modelling: "The discussions helped to put everyone on the same page" (TcL); "It was possible to align the different perspectives that the team members have." (DvT). Participants also pointed out some advantages over the iStar language itself, such as: "The level of details you can do with iStar is very good and the scope of being able to represent all parts of the system." (DvT); "iStar is a more 'human' language for modelling systems, without many technical concepts and that contributes to the process of understanding the application that the user wants to model" (DvT). Other positive points presented were: the opportunity to meet and discuss multiple points of view; the epistemic nature of the language, that is, being an instrument of reflection on the problem/solution; the collaboration between team members during modelling and the satisfactory dynamic conducted during modelling sessions.
Regarding the negative points, they appeared in questions 1, 3, 4, 11, 12 and 13. We can separate the negative points, complaints and suggestions for improvement into two large groups. The first is related to the difficulties identified by the participants in relation to the iStar language (complexity of concepts and notations) and the modelling activity itself. Examples from this group are: "Sometimes so much detail can get in the way of those who don't have so much experience" (DvT); "More documentation is needed on [iStar]" (DvT); "It's quite complete, but I found it very complex and for me it REQUIRES a lot of practice." (DgT); "My biggest difficulties were 'how to pass what I'm thinking to the modelling? Do I use X or Y?' " (DgT); "I had difficulties with some concepts initially, such as roles, agents and actors." (DvT). The second group of problems and suggestions for improvement is related to the dynamics adopted in the modelling sessions. For example: "The meetings were too long and discussions often had things that, in my point of view, were not relevant" (TcL); "Sometimes there was an anxiety to speak when it wasn't my turn yet" (DgL); "[Having] a person responsible for manipulating [the tool on] the screen ended up taking some of the diagramming experience of the other participants" (TcL). This last comment highlights the need to using a collaborative modelling tool which all participants can model by themselves in a shared iStar model.
Additionally, a negative point was presented by DvT: "When the model becomes large, the understanding is difficult" (DvT). Scalability is one of the most intractable issues in the design of visual notations in general: a well-known problem with visual representations is that they do not scale well. Lima et al. [15] identified 126 studies which mention scalability in iStar models. Thus, this is one more evidence about scalability problems in iStar models.
The evolution in the knowledge level of the participant is shown in Figure 3. The modelling increased the participants' level of knowledge in most cases, but it was more effective in knowledge about the context/problem in which 9 of the participants indicated some level of knowledge evolution, of which 4 had a difference in knowledge level between before and after modelling more than 3 points. Regarding the knowledge level of customizations, 2 participants reported no difference in evolution, 3 participants showed an evolution of up to 3 points and 5 participants evolved more than 3 points in this type of knowledge.
We recognize some threats to validity. The participants and the researcher who applied the questionnaire are members of the same project. This fact could inhibit the responses of the participants. We mitigated this threat by informing about the anonymous participation. Another threat is that we performed only one pilot. We tried to mitigate it by telling the participants to report any problems to understand the questionnaire. We did not receive any comments about corrections.
This paper presented an experience report about the usage of iStar in an industrial project which aims to evolve an administrative module of an e-commerce platform. The results detail the context of the project which presents an overview of the development with HCI/UX and MBE techniques and how iStar was included in this flow. We described a step-to-step about how iStar was used. Finally, results of the evaluation based on a survey were presented highlighting positive and negative points, and the evolution of the understanding. iStar modelling contributed to the comprehension of the context of the project and the new features to be included.
In order to continue this research, some suggestions for future work may be cited, such as: 1) perform a focus group to complement the evaluation analyses; 2) analyse improvements and weaknesses identified and adapt the steps followed to future projects; 3) replicate this study to other industrial projects, analyse the resulting effects and compare with this one; and 4) analyse the use of iStar extensions [4] based on PRISE [5] [6] in future industrial projects.