Understanding Software‐centered Evolutive Ecosystems through Activity Theory

This paper proposes an interdisciplinary approach aimed to bring into practice some novel Software Engineering theoretical paradigms. The premise of these news paradigms is based on the idea of “ecologies” as realities that take place in the environment of a Software product. These “ecologies” are understood as tight but flexible interactions between the human, social, and technical components involved, where Software is just another component. However, the theoretical paradigms discussed do not offer a viable way to make sense of these ecologies into the practice of Software design and development. Thus, as a more operationalized approach, this paper proposes a framework based on Networks of Activities, a concept derived from Activity Theory, as a resource to help in the design, development, and evolution of these new emergent complex socio‐technical ecologies. This framework has been conceived as a tool for the design, capture, and, especially, to analyze the evolution of these ecologies. The concepts and notations used by the proposed approach are illustrated through a proof of concept that shows the essential ideas and their use in real scenarios. In this way, the concepts discussed contribute to the improvement of related fields like Requirements Engineering, Human‐Computer Interaction, or Software Architecture, among others.


| INTRODUCTION
The design and development of new Software-based products and services is at an interesting and critical moment.In this regard, it can be stated that it is going through a stage that challenges the capabilities of traditional Software and System Engineering methods and techniques, such as Unified Modelling Language (UML) diagrams, Data Flow Diagrams (DFDs), and Functional Flow Block Diagrams (FFBDs). 1 At the same time, the limitations of classical paradigms such as the Waterfall Model, 2 the Spiral Model, 3 the V-Model, 4 or Function-Behavior-Structure Framework, 5 to name a few, are also revealed.These challenges stimulate research and exploration of novel solutions to support problematic areas such as coevolution, [6][7][8] interface stability through time, evolution management, or user interface integration with workflow, without disregarding security and reliability concerns. 9ooking at traditional approaches, it is clear that they evoke, for recent complex developments, a closed and limited vision of situations that do not usually take place as a sequence of input, process, and output. 10Thus, these historical initiatives or even some modern approaches, such as agile development methods like Extreme Programming (XP) 11 or Scrum, 12 do not provide a realistic and effective approach capable of providing meaning to certain conflicts and evolving situations rooted in convoluted human or social behaviors (e.g., thoughts and actions) 13 and that may exert a direct effect on the processes of Software design and development. 14nsequently, a further step is needed to conceive design and development as the creation and evolution of socio-technological heterogeneous ecologies that are never "finished" and are always subject to (expected and unexpected) changes.Thus, it becomes necessary to advance in the search of a more pragmatic approach that leverages these conceptions and adjust them to achieve solutions and implementations that are methodologically affordable and understandable to Software designers and developers.
In consequence, given this situation, the main Research Question addressed in this paper is as follows: How to build approaches that address the challenges brought by the strong contextual dependency and coevolution characteristics of emergent Software-centered socio-technical ecologies, while at the same time being useful to practitioners by providing organization, visibility, and shareable artifacts?
There are proposals that try, in a pioneering way, to understand the irruption of new paradigms and to provide different visions and new mechanisms to better understand and carry out the process of related Software.In this sense, there are two prominent analyses of the subject.Firstly, the analysis carried out by Jarke et al., 15 who postulate a change in the historical approaches to the development of "systems."Secondly, this change of vision or approach lead to an interesting exposition by Ralph 16 who, through his Sensemaking-Coevolution-Implementation (SCI) paradigm, expressed ideas very close to how the interactions between tasks are carried out in reality and how products and processes coevolve until they approach a working solution, which should never be fixed, as it will always be in a state, and under a context, that are subject to continuous change.
However, the position of Jarke et al. and Ralph is, in many ways, theoretical because, although they provide quite convincing and acceptable explanations of what is going on in the professional praxis, they do not offer practical and substantial guides or advice for real-world system (or ecosystem) development.Aspects like requirements gathering, modeling, documentation, validation, however lightweight, they are not properly described from a practitioner's guideline standpoint.Additionally, there is an underlying problem related to the uniqueness in the representation of non-technological (e.g., human and social) contexts.This is a relevant matter, but in which the proposals of these authors are not particularly helpful because, although they give some clues to describe situations with a certain approximation to reality, they do not define a way to address and model them.
Thus, multidisciplinarity becomes a must to achieve this goal, given the ecological character of these developments.Under this idea, it is therefore acceptable to find inspiration in other fields, such as Psychology, which would allow to link certain proven historical developments and concepts that seem to stagnate in Software research.The reasoning for including a psychological approach over other approaches (e.g., sociological or ethnographic) is because both Psychology and Software offer complementary visions of reality, though in a different way: The vision of Psychology is pervasive by nature, whereas the vision of Software is omnipresent by choice.This ubiquitousness is a common element of both concepts.
To broaden this argument, it must be understood that Psychology tries to offer insights on functions, interactions, perception of the world, and human motivations among other topics. 17In this sense, it is pervasive because it essentially has to do with, and is implicit to, all of us as human beings, the main object of study.On the other hand, Software is omnipresent because, nowadays, it is placed everywhere.We take it with us in our pockets (by choice) and provides us with useful tools that help us in our daily efforts.
Software is "ready-to-hand," in Heideggerian terms, 18 and part of its usefulness is to compensate some basic deficiencies of the human being, especially in processing information, 19 in order to meet some inherent human needs, such as communication and social interaction.Therefore, Software is ultimately used by humans or at least must be designed with this in mind.Thus, except research entirely contained in a very specific theoretical area (e.g., mathematics, electronics, and quantum computing), Software research has been able to integrate, to a greater or lesser extent, human factors that have been also explored by Psychology as part of its topics and objectives.For example, conventional research fields such as project management, requirements gathering, collaborative development, 20 and user experience, among others, or in novel research areas such as biometric sensing 21 or cognitive processes applied to program comprehension 22 will contain in some way the application of analysis and studies previously reviewed by Psychology.
In this way, this paper proposes to address its main research question by building on a practical instrumentation approach called Activity Theory (AT), a framework developed and studied by many researchers [23][24][25] throughout a rich history in Psychology.0][31][32] The versatility of AT comes from its ability to model, represent, and analyze complex goal-oriented situations with multiple and different actors involved.For this reason, this paper discusses AT as a way to address a situation that has been described by the Evolving Ecologies of Jarke et al. 15 and the SCI paradigm of Ralph. 16us, this paper has been structured as follows.In Section 2, we begin by jointly describing the proposals of Jarke et al. and Ralph regarding their ideas and concepts, discussing also their main practical shortcomings.Later, in Section 3, the basics of AT, its historical origins, and key concepts will be briefly reviewed.In this review, an outline of the resolutive aspects of AT will be provided, which contributes to the analysis of the evolution of a Software-centered ecology, by means of an AT construction called Network of Activities (NoA).Section 4 presents a proposal for a model of integrated concepts, explaining how this model is capable of assembling and re-interpreting the evolutionary ecologies and the SCI paradigm, to finally be coupled with the elements of AT as an instrument that allows to explore, interpret, and give meaning to complex socio-technological settings.The proposal will be illustrated and reinforced in Section 5, by a practical example taken from a real-world situation, based on a scenario aimed to support and fix the central ideas.This example comes from a series of problems that took place in a Spanish start-up company in the urban delivery service (UDS) sector, whose technological growth and evolution of its smartphone-based Software have been influenced by external changes associated with the human agents that drive the commercial goals of this company.We show a situation focused on one of the operational aspects of the company directly linking the Software, human activities, and the natural evolution of solutions aimed to solve unexpected conflicts, a situation in which conventional Software Engineering (SE) approaches would experience certain limitations.Later, in Sections 6 and 7, some considerations will be given on the potential usefulness of AT and the NoAs for other endeavors related to SE, to encourage the research and use the ideas discussed here, and to validate their applicability in related areas (e.g., Project Management, Human Resource Management, HCI, Requirements Engineering, and Software Architectures).Finally, Section 8 provides some conclusions.

| APPROACHES TO THE MAIN VECTORS OF CHANGE IN CONTEMPORARY SOFTWARE DEVELOPMENT
There are several approaches aimed to make sense of highly context-aware Software products and processes.Some of those that were reviewed for this paper are the Self-Conscious Process, 33 the Theory of Distances in Software Development, 34 the Theory of Persistence and Change in Software Development, 35 or the Play-Test Boomerang. 36However, these initiatives continue to be quite "technified" and adjusted to contexts that are away from the goals of this article.
For instance, these works attempt to (1) identify and describe the underlying factors that may explain why certain practices support the  4) analyze the decomposition of a problem into sub-problems that lead to the prototyping of a solution (Self-Conscious Process).These are a wide range of interesting initiatives.However, they remain insufficient in terms of addressing structural issues that lie behind many of the novel challenges in the field and, in particular, factors related to the intertwining of the social, the human, and the technological.For these reasons, two representative proposals have been chosen and will be briefly described and discussed in this section, to explore and address some of the new challenges currently facing SE.
The selection of these proposals lies precisely in their conceptual and reformist approach towards future SE.These two proposals are (1) the idea of Jarke et al., 15 which brings attention into how the classic vision of "systems" development can and should be replaced by a new perspective based on system-environment coevolutionary "ecologies"; and (2) Ralph's SCI paradigm 16 with its focus on the deep intertwining among three key development and analysis areas: Sensemaking, Coevolution, and Implementation.
A possible connection between these two proposals also exists.The SCI paradigm is related in many ways to the analysis of Jarke et al., as its foundations can be explained as an extension of those ideas (for example, the interaction dynamics of its elements can be seen as "living" components of an ecology).A discussion of both approaches is presented next, as they form the basis of an argument that, subsequently, will lead to the actual proposal presented in this paper, based on AT. 23

| Evolving ecologies
Jarke's main argument essentially states that, to broaden the understanding of Software design and its environment, it must be interpreted as an ecosystem or ecology.It is important to note that the term ecosystem has been proposed by authors such as Nambisan, 37 as an integration perspective for components and collaboration-cooperation in Software.
The word ecology derives from the Greek word oikos (home, place to live), and in Biology, it makes reference to the relationships of a living organism with its environment (which also includes other organisms). 38The key here is the focus on relationships, more than on isolated beings.
In consequence, the term "ecology" in SE will also focus on the (desired or undesired) interactions between elements that may be human, organizational, or technical. 15Due to the prominent role of Software in these ecologies, as the main hub and enabler, sometimes it is useful to talk about Software-centered ecologies.
The interactions among components take place in a dynamic and nonlinear fashion, constantly changing and causing evolutionary processes, for good or for bad.Going again to Biology, 39 a Software-based ecology can be seen as the set of processes, dynamics, and interactions between all the components of a socio-technical system. 40Therefore, the ecological interactions that arise are characterized by the benefit of the components involved or by the damage to them, inducing harmony or disharmony, respectively.
Based on these conceptions, it is possible to better understand the design and development scenario of complex Software socio-technical systems.This encompasses greater complexity than traditional approaches, more static and delimited.Regarding the evolution, it can affect (1) Technical aspects of the Software, (2) Documentation aspects, (3) Properties of the Software, and (4) User experience/functionality. 41 general terms, this evolution is seen as a Software design problem that must be managed through methodological support. 15However, despite this novel vision and the underlying derivative efforts, there are substantive issues that have not been resolved yet as, for example: How can development activities embrace evolution more effectively (i.e., evolution awareness)?How to find the impact that coevolution (systemenvironment) exerts on the design?Similarly, regarding ecologies, there are issues that have not been analyzed yet from the perspective of its underlying nature.In this sense, studies on technological aspects, human learning, organizational synergies, change management, and the impact that regulates and generates new evolutionary directions, among others, remain to be explored especially from a practical, hands-on, standpoint.Within this context of evolving ecologies, requirements are one of the most rapidly mutating artifacts.Their constant evolution imposes fluidity in the designs, with the focus on creating easily adaptive Software that gracefully adapts over time.Successfully implementing these evolving ecologies will depend, in many ways, on the development of appropriate "architectures," as Jarke et al. propose, as the key ordering principle. 15wever, up to now, it has not been possible to evoke this concept in a practical way 42 and make it viable for Software-centered ecology engineering.Also, there are other relevant practical questions: How do environments coevolve as the technological context changes constantly and increasingly?How to understand the elements that drive, or impede, that coevolution and use them, or mitigate their consequences?How to approach a complex satisficing problem such as the design of an (evolution oriented) ecology instead of a delimited system?Moreover, if the requirements encompass the idea of an open and evolving system, how should requirements be effectively managed?How to transform those changes without radical redesigns of the overall architecture?Therefore, there is a need to interlink requirements and contexts, to evolve designs and ecologies and to manage all these elements by learning to recognize and mitigate its consequences on design complexity.As an analogy, this is close to the design concepts for "smart cities," 43 with the interconnection required to communicate services, devices, controls, access, security, availability, and so on, at heterogeneous infrastructure levels with technologically variable platforms and always in the service of the citizens, so they can adjust to social, political, economic, and even technical environments, without degrading their functioning and quality over time.These questions, then, extend an invitation to challenge some conceptions in SE, to forget monolithic perspectives and to go towards the exploration of innovative alternatives "… in the design of complex Software within a livingand therefore evolvingworld." 15 Consequently, it is necessary to expand into new directions, which is why fundamentally novel design concepts and approaches have emerged that attempt to understand these and other related theoretical propositions.A proposal, very relevant for this paper, is the SCI paradigm outlined by Ralph 16 that will be reviewed next.

| The SCI paradigm as a design and development process
Proposed by Ralph, 16 and in clear opposition to the limitations of the traditional Function-Behavior-Structure (FBS) framework, 44 SCI postulates that Software systems (operating within a context) are produced by a Design Agent, individual or team, that freely alternates between the three tasks of Sensemaking, Coevolution, and Implementation, in no particular sequence 16 (Figure 1).These three tasks will be described below.

| Sensemaking
The term Sensemaking is broad in its meaning, and this depends in many ways on the approach that the different authors give to it, based on the area of study.7][48] It also includes the framing and definition of problems 49 and finding the assumptions related to an understanding of the context.As the project environment is continually evolving, Sensemaking is a continuous and evolving process.

| Coevolution
It refers to the understanding of the links among situations in which two or more interconnected objects change over time, in such a way that changes in one of them activate changes in the other and vice versa.It is of interest the parallel evolution of the context with the design of the products that operate within that context.This is connected to the already discussed concept of ecologies and the way in which different components should coexist.Additionally, in the SCI paradigm, and in design literature more generally, Coevolution refers to the mutual exploration and refinement of the schemes devised by the Design Agent in relation to the project context and the design space of the solution. 50,51Thus, Coevolution can occur in planning meetings and design meetings, after conflict resolution or during an individual's internal reflection.This social interaction component is important because SCI postulates that the development team (Design Agent) faces a changing and ambiguous context that includes stakeholders who have different positions and values, so they may disagree with the project objectives or be unable to articulate clear objectives and or constraints.

| Implementation
Is the task concerned with the materialization of the design space through the creation and modification of artifacts?It is based on the fact that the team (or agent) has to give meaning to a problematic context (Context Schema in Figure 1) by means of instrumenting an artifact that ameliorates those perceived problems.
Putting everything together, as seen in Figure 1, through Sensemaking, the Design Agent develops an evolving Context Schema which, via Coevolution, guides the conception of a Design Space Schema, through generation and evaluation of alternative solution models.The exploration of this design space will trigger the reconceptualization of the context (since it changes the Context Schema).Meanwhile, via Implementation, the team creates and modifies the Software and related artifacts that constitute the Design Object, following the guides established in the Design Space Schema.
It is worthy of mention that, as shown empirically by Ralph, 44 in real-world developments, the Design Agents switch between Sensemaking, Coevolution, and Implementation at will, versus traditional "lifecycles" approaches 2-4 that assume a more linear, mechanical, and systematic phases-based process.

| Moving towards a practical approach of the ideas
Both the two approaches discussed, as well as other author's analysis, [32][33][34][35][36] provide a well-supported theoretical view of concepts and behaviors related to Software design and development activities for complex ecosystems.However, there is an underlying problem: Although their analysis brings a very clarificatory and decisive explanation of key issues, they neither suggest nor provide practical advice or ideas on how to carry them out or by means of which formalisms, methods, or tools.This creates a potential opportunity for research and advances in this area that could be framed as the problem of materialization the conceptual advances discovered.This is a challenge that, perhaps, has not been openly pointed out but is inherent (and continues to be) to the field, as Software emerges from a conceptual representation modeled from abstractions.Furthermore, because there is no methodological and practical uptake for these novel conceptions, there is a risk to perpetuate the use of traditional frameworks, methods, concepts, visions, and approaches in situations where they are less than adequate.
As it was shown, Jarke et al. 15 identify evolution and ecology as the framework for analyzing the complexity of contexts.For his part, Ralph 16 provides a more specific way of dealing with these elements in a more procedural form.However, these proposals leave out of their scope the articulation and understanding of the how-to regarding the interactions between design and development activities.Above all, they do not deal in detail with the nature of the social and human contexts that must be integrated into the development of a Software that moves evolutionarily within an ecology.
In this regard, as the SCI paradigm describes, there are team dynamics (social, individual) associated with the development contexts and the solution design (shown in Figure 1).3][54][55][56][57] In this scenario, there are conflicts, opposites, and inconsistencies that interrupt the workflow. 58Therefore, there is a need to address, study, and analyze these problems with different instruments that focus on the overall tasks to be carried out, to not confuse the forest with the trees.
In this sense, and as mentioned in the introductory section of this work, Psychology, and some of its instruments, such as AT, broadens the horizons of research in SE, by transferring theoretical and practical knowledge about social and human phenomena that has been historically analyzed by Psychology, but is very persistent in socio-technological contexts.Thus, this standpoint represents a real and valid option for giving a better articulated answer to the challenges that, by using the traditional techniques and methods, remain unsolvable or partially solved.
Consequently, this paper proposes AT as an approach that, conveniently adapted, is particularly relevant for obtaining and representing rich information about tool-mediated human activities and its surrounding context. 59,60AT, from its roots in Psychology, offers a universalist approach that is technologically "aseptic."The idea is to establish, by means of AT, a bridge that links the new paradigms with the needs of real industrial practice.Conceptually, this would lead to a theoretical and practical understanding of the main ideas behind those paradigms and, at the same time, facilitate the instrumentation of tools for interpreting and understanding design and development tasks for challenging Software-centered ecologies, in a way that can be leveraged, improved, and consolidated.

| AT
The immediate objective of this paper is not to discuss the theoretical or philosophical basis of AT, so this section will summarize only the most important aspects for its use in Software-centered ecology understanding, design, and evolution.Specifically, we will overview AT origins, elements, fields of application, and its use as an instrumental support and proposal to guide SCI-inspired processes in technological ecologies.For the interested reader, the following lectures are recommended: for a deep analysis of AT concepts the pioneering work by Engeström 23 and works by Kaptelinin and Nardi. 24[31]

| History and key concepts
AT is based on the works of Vygotsky and Leontiev, from their studies of historical-cultural Psychology in the 1920s. 61AT conceptually uses a human activity as the unit of analysis, in which this activity is divided into analytical components such as Subject, Tool, and Object. 62The Subject is the person who purses a particular goal.This goal is the Object of Activity and represents the prospective outcome that motivates and directs the Subject, around which the activity is coordinated and crystallized in a final form when complete. 24Objects in AT are what distinguish one activity from another.In this regard, this Object of Activity should not be understood as a physical object or a tangible "thing."The third classic element in AT, the Tool, is the mediation mechanism or device through which an action is executed in order to achieve the Object. 63entually, Engeström 23 introduced some modifications to Vygotsky's and Leontiev's original theory, providing additional units of analysis that have an implicit effect on activities.The first is the Rules or sets of conditions that help determine how and why individuals can act.Rules are the result of social elaboration and are subject to social conditioning.The second addition is the Division of Labor, which accounts for the distribution of actions and operations among a community of coworkers.These two elements have an influence on a social plane known as Community, and through it, groups of activities and teams of Subjects can be analyzed. 23Finally, there is the Outcome element that states what the activity system produces, desired or undesired, and acts as an indicator to measure the achievement or not of the Object in the activity.For example, the Object of a particular participant in a sporting activity, such as a Marathon, can be "Participate," whereas the Outcome can take the form of "Win," "Lose," "Complete the run," and so on.A generic activity system is represented in Figure 2, as a triangle of triangles. 24In this picture, the Subject, the Object, and the Community are the main core elements, shown as the center sub-triangle within the bigger triangle.The outer elements (vertexes of the big triangle) act as intermediate elements between the main core ones; these intermediates are the Tools, the Rules, and the Division of Labor.The Tools intermediate between the Subject and the Object, the Rules intermediate between a Subject and the overall Community, and finally, the Division of Labor mediates between the Community and the Object of activity.
The triangle representation (Figure 2) also allows a socially distributed view, rooted in the nature of the activities: By focusing on the base of the triangle, we find the Community, the Rules of the activity, and the Division of Labor.These elements describe the way in which work is organized towards a common Object and the Outcome generated.Another characteristic of the activity triangle is that it is not static, because the change to any element of the activity system impacts and leads to further changes in other parts of the triangle, recursively.The analysis of how activities and their contexts evolve, as proposed in this paper, will be rooted on this fact.
Based on these concepts, AT can be understood as an instrument that brings to scene the relationships between physical actions, minds, and groups, all of them interacting within a specific context. 27,64These relationships arise from exploring the links between thinking, behavior, individual human actions, and collective group practices. 65In this sense, AT can provide a technology-agnostic tool useful for diverse purposes and fields of study, as it supports the description of forms of development of thought and individual or collective actions in a specific context, including a representation of this context as well.It also supports the understanding of the underlying structures of a context, such as the procedures and the definition of related actions and tasks.This particular characteristic of the AT allows the "mapping" of situations and the description of methods and procedures in a general and flexible way, 27 facilitating the study and analysis of different contexts and promoting the search of dynamic solution spaces for the problem at hand.One aspect that the AT analysis proposes is the identification and treatment of "contradictions."This is an important topic in AT since the earlier days of the theory and is not completely unrelated to the "contradiction" as one of the key elements in Marxist thought (which is historically obvious, as the historic origins of AT are rooted in the Soviet Union). 23,24Contradictions, in Marxism, are not the same as logical contradictions, and they should be understood as "tensions" that, at the end, are the driving force behind transformations. 66In terms of AT, contradictions were defined as "a disengagement within the elements, between them, between different activities or between different phases of development of a single activity." 25In simple terms, contradictions are situations or circumstances that modify the natural interactions between the elements of an activity system (shown in Figure 2) and its orientation towards the Object, 31 producing unexpected Outcomes (positive or negative) as the result of the activity.
The important thing is that contradictions, in AT, can be leveraged as the "fuel" that drives changes.They refer essentially to anything within an activity system that is in opposition to the general motive, objective, or purpose for which Subjects strive individually or collectively.This must not be seen as a problem or a failure.On the contrary, contradictions are a positive manifestation that something must evolve and transform continuously. 32,67,68 an example, a typical contradiction in Software design (as an activity) is that the volume of the data to be processed conflicts with the speed needed for its processing.In most cases, designers do not bother to solve this contradiction and simply choose between two values, which is more suitable for them: either speed or volume.This occurs in the activity for the following reasons: (1) The processing time increases significantly if several requests for a large amount of data are needed (vs. the alternative solution, where all the data are present and processing time can be shortened); (2) the contradiction is often impossible to solve optimally; (3) even if a solution exists, it is usually difficult to find (or requires a significant amount of time, which designers simply do not have); (4) even if they have time to find a solution, it does not significantly affect the quality of the Software.Therefore, these scenarios lead to the design activity itself to advance over this contradiction and to evolve around some of the available alternative paths.This example of contradiction can be reinterpreted and analyzed in terms of AT, by means of the representation in Figure 3.In this figure, an activity system is represented where the elements or vertices (Subject, Tools, Rules, etc.) of the example have been placed according to the general schema shown in Figure 2. The straight arrows represent the natural interaction between the elements of the system; the lightning arrows highlight contradictory situations that "interrupt" the harmony.In this case, these contradictions arise from the Subject (Designer), crossing with the defined Rules (see Figure 3).Thus, the contradictions arise when the Designer, in practice, must determine which of both Rules must be deployed in the design (Fast Software or Memory-Efficient Software).Either of the two options he chooses, in this case, breaks the proposed Object that is "Design a fast and memory-efficient Software."This induces, consequently, unexpected Outcomes, that for obvious reasons do not fulfill the premises of the Object, resulting, therefore, in effects like obtaining a fast but memory-inefficient Software or an efficient but slow Software. 23

| AT as key idea for representing and evolving ecologies
The idea of using AT as a general representation of evolutionary ecologies or as a key piece in the instrumentation of paradigms such as SCI was inspired by the interdisciplinarity suggestions made by Jarke et al., 15 as an approach to research that generates answers to certain concerns of contemporary SE.In this regard, it is based on the idea that the crosspollination between disciplines, each of them contributing with their own conceptual schemes, may support a better framing of the problems and their associated research methods.
In this way, by taking the contribution made by Psychology through AT 23,61 and using it in SE as described by Jarke et al. 15 and Ralph, 16 the barriers that exist between different spheres are broken down, so they can cooperate with each other.Risks of over-specialization or falling into a kind of "sedentary" research (doing more of the same) are, then, problems that can be tackled.As a result of this collaboration between fields, studies can be extended towards novel advances and interesting solution approaches to the proposed problems.More specifically, this paper argues that, through AT as an interdisciplinary resource, it is possible to arrive to several research results that support, and contribute, to the challenges of creating Software under the new paradigm discussed.
As previously commented, AT focuses on the generalization of human actions in any context in which those humans carry out such actions.This idea is interesting because it relies on AT being "aseptic" and universal, free of specific technological implementations.This rationale allows the use of AT to provide a frame of reference for the capture and representation of different areas of the domain under study (e.g., education methods, social behaviors, individual learning, and use of technology).As described above, the unit of analysis (or activity system) of AT focuses on how Subjects use artifacts (Tools) to achieve a specific goal (Object).This dynamic, including its context, provides a platform for describing how these artifacts manifest qualities beyond their formal technical attributes like, for example, its modifiability by Subjects who use them or its adaptability to an evolving circumstance.In this way, the use of the AT framework offers a general, universal, and understandable formalism for understanding, communicating, and design.A real-world example in which a change in the context had an impact that introduced changes and evolution in the Software, even going beyond the initial purposes of its creators, is provided by social network and communication platforms such as Twitter.In this case, from an original SMS-like platform designed to create a communication system for small groups, an overload of new proposals from users reshaped the platform.Thus, new features were born like the hashtag, the retweets, the mentions with "@," as well as many other features that emerged from the audience, 69 by considering Twitter "their social network."By desiring a better support for socialization activities that closely matched the desires of the users of the platform, 70 in terms of AT, it can be said that "contradictions" in the usage were followed by "solutions."

| From activity system to NoAs
The main concepts behind SE have not evolved at a rate of change that responds to the phenomena and situations described by Jarke et al. and Ralph in the referenced studies. 15,16Those analyses point out the emergence of novel dynamics with characteristics that make them particularly difficult to study and to operationalize its ideas into mainstream industrial practice.In this sense, an activity-centered formalism like AT may help to face this challenge, as "activities are not static or rigid entities; they are in continuous change and development," 25 among other things.
Design and development takes place at two levels of an activity: (1) intellectual (when thinking) and ( 2) operational (when performing). 62tellectually, by organizing and analyzing the elements involved, it is possible to get an idea of an evolutionary development process that includes the context of the activity.In this way, all the components that are inherent to an activity can be represented and made visible and manageable.In practical terms, using AT and the components that integrate its units of analysis (activity systems), it is possible to represent in a general and practical way the contexts that the evolving ecologies paradigm and SCI have theoretically described.
Operationally, the basic premise of AT is that a Subject (a person or collective group) is driven by a motivation to act on an Object (a person, collective or thing) using historically and culturally created tools that include technological artifacts, mental aids, signs, symbols, and languages, 68 among others.Those elements act as mediators to the activities. 71Also, in the Tools set, artifacts can include instruments produced by some design and development process, like machines and computers.Therefore, the Tools allow and limit activities at the same time. 25e unit of analysis in AT is the activity system, as it links individual actions to the context (Figure 2).Actions without context (purpose) have no meaning. 29Thus, the value of the AT is derived from the analysis of the Subject, in compliance with the activity and its Object.In addition, there is an evaluation of its Tools and the mediation through the Rules, the Community, and the history of the context in which it is developed.In this way, some applications of the AT have inspired deep theoretical reflection in a variety of fields like, for example, Psychology, 59,61 Education, [72][73][74] Management, 75 HCI, 25,26 and Information Systems. 29,30veral researchers recognize that AT is holistically rich in terms of understanding how people do tasks together with the help of sophisticated tools in intricate and dynamic environments, 25,30,63,74,[76][77][78][79][80] which suggests how helpful AT may be for Software design and development.
In any case, for the purposes of this paper, there is a need to go beyond the analysis of a single activity.In this sense, the complexity and interactions between activities lead to their representation as different triangle elements that will constitute a NoA. 23,24To understand this concept of an NoA, it is useful to think, for example, in the assembly line of a car.In this assembly line, each worker contributes individually to assembly pieces that, when integrated as a whole, give final shape to the car (see Figure 4).Thus, there are workers who place doors, wheels, and engines.Each one carries out an activity trying to achieve a particular objective, has tools to do it, follows some rules, and knows the details of the specific job.The joint and collaborative work of all the workers from their individual effort (triangle) leads to the collective materialization of a car.However simplistic this example looks, the NoA concept can be applied, as shown in the works of Engeström, 23 Kaptelinin and Nardi, 24 and Mursu et al., 29 to real-world complex situations, like hospital management.
Thus, the NoA is a better model for unifying and organizing the actions, purposes, and objectives of designers, users, and stakeholders.An activity is a universal concept, represented by AT, but, in addition, the NoA approach allows to understand the activities of different groups and to carry out a multifaceted analysis of the information and the dynamics shared among activities.By using an NoA, it is possible to evaluate the contradictions that nurture the evolution of the NoA itself, leading to certain fluidity in the design of the requested artifact (Software /Hardware/ Social).Thus, as networks are built, measures are established to mediate with the current knowledge of a situation and to anticipate situations, by using the contradictions that drive the evolution of the different components (Subjects, Tools, Rules, etc.) and their interconnections.
Consequently, we propose to use NoA's to operationalize the conceptions presented by Jarke et al. 15 and Ralph, 16 by translating their ideas into more practical design and development tasks closer to real situations of use and implementation.In the next section, we will discuss how AT and the use of NoA's brings methodological and practical value for dealing with Software-centered ecologies.
F I G U R E 4 Representation of a Network of Activities (NoA) for a simplified "ecology" in a car assembly line.

| USING AT AS A CONCEPTUAL UNIFIER IN SOFTWARE-BASED ECOLOGIES DESIGN AND ANALYSIS
The concept of NoAs is derived by interconnecting the simplest units of analysis in AT: activity systems (triangles).These collaborating triangles help to understand, communicate, and model a complex ecology.In this paper, a conception will be proposed to interpret the NoA as a tool that can play the role of "missing link" between accurate but abstract paradigms, like SCI 16 or evolving ecologies, 15 and the real-world practice of contemporary SE.
Before presenting the details of this proposal, on the use of NoA for Software-centered ecologies, it is important to clarify the parallelisms between the SCI paradigm with the concepts brought in by the NoA formalism.This "mapping" is obtained essentially (1) by analyzing the three primary tasks of the SCI paradigm (Sensemaking, Coevolution, and Implementation), previously shown in Figure 1; (2) by analyzing the underlying SCI raw materials and products (Primitives, Context, Design Object, Context Schema, and Design Space Schema); (3) by decomposing them into its elementary units; and (4) by representing those units as elements in an activity system (or triangle).The result of this mapping is outlined in Figure 5.
As shown in the figure, the elements of SCI 16 are displayed as in a classic data flow system by means of process bubbles, input-output arrows and products (storages, boxes with bars), with previous elements acting as external entities (context, primitives; see Figure 1 for details).The products obtained can be represented by means of the AT triangle formalism, which acts as a lingua franca thanks to being technology aseptic.This is a fact of big consequences that will be exploited in the next subsection.The following description stems from the arguments raised by the different authors (Ralph for SCI 16 and Engeström, 23 for AT/NoA) in order to illustrate the line of reasoning we followed when developing the mapping shown in Figure 5.A comprehensive resource, the NoA-SCI model, will be shown later.The mappings provide several reinterpretations to be discussed next.

| Sensemaking reinterpreted into AT
Sensemaking is a term with a very broad meaning that depends on the circumstances and situations of use especially, in socio-technological scenarios. 45As an activity, Sensemaking directs its efforts towards understanding a changing environment.This environment is the Context, which provides meaning to the tasks at hand.On the one hand, the Context defines the real-world environment that will be interpreted by the Sensemaking tasks.The "product" obtained by this task is the Context Schema, a synthetic modeling of the relevant part of the world, as the anchor that allows keeping up with an evolving environment, due to Sensemaking working in a cyclical way (Figure 1).With more detail, the of Labor.On the other hand, the Context Schema materializes a general representation of the changing and evolving environment, with Sensemaking acting on the contradictions 31 that may emerge between the Context and the Context Schema.

| Coevolution reinterpreted into AT
The idea of Coevolution is mainly about the harmonization of the changes induced by contradictions that take place between the Context Schema and the object to be designed, represented as the Design Space Schema.This mediation is needed to detect and react to those changes, to avoid them, or to take advantage of them as further iterations in the construction of the item under development.Advancing in this task leads to a better synchronization between the understanding of the Context and the interventions on it.It is, of course, assumed that the designer tasks are not neutral to a Context, as the Context can change by itself in ways that are unpredicted by the designers.
For example, YouTube was initially a platform for the publication of videos.Subsequently, its users found ways to extract the audio from the songs in the videos and ways to upload movies and other material with protected rights, temporarily turning YouTube into a provider of music, video, and illegal content. 81,82Thus, the site was forced to coevolve, given this context, to resolve the conflicts that took place.

| Implementation reinterpreted into AT
The Implementation is focused on the "Tools" vertex of an activity system (see Figure 2 for details).Through its actions, the Design Object or "tool," built by orchestrating pre-existing Primitives (libraries, frameworks, apps, cloud environments, databases, etc.), exerts actions over the Context, which will be modified consequently.The Implementation, within an activity system, leads the evolution from an initial Design Space Schema, proposed as a candidate solution, to subsequent improved solutions, intertwining with parallel iterations through Coevolution and Sensemaking, as discussed.A practical example of this situation is provided by the continuous updates to smartphone applications for social networks (Whatsapp, Instagram, Facebook, etc.).These updates, in many cases, are driven by changing policies about security, privacy, extended features of the base platform, and so on.Each version, then, is materialized through incremental improvements to the Design Space Schema and the Design Object.

| Bringing the ideas to a synthesized model: How AT and the SCI paradigm work together
As discussed in the previous section, the SCI paradigm deals with artifacts representable in terms of AT.However, it is not enough to perform a conceptual mapping.The different aspect must be more practice oriented and operational.For these reasons, the NoA is presented in this section as a link for such association as it encapsulates the previously described aspects.An NoA, then, is the formalism for the representation of ecologies, as it has the capability to represent a multiplicity of collaborating and intertwined activity systems.In this way, an NoA acts a central repository for the representation and evolution of a particular ecology, as presented in Figure 5.
Using the NoA formalism, the ecosystem is modeled and is subject to the Sensemaking, Coevolution, and Implementation tasks, as it encapsulates the concepts described by the SCI paradigm as shown in Figure 5.This is represented in Figure 6, and therefore, it allows us to generalize the interactions shown in Figure 5 and go further, by including other conceptual elements if required (e.g., Prior Knowledge or Components) that enrich the model, complement the representation of the ecology, and facilitate the appreciation of evolutionary behaviors in it.
In this model (Figure 6), Prior Knowledge is the knowledge that the designer already has, based on his previous experience and mastery of the area of expertise.Sensemaking leverages this Prior Knowledge for the construction of an initial NoA, organizing the triangles according to the real context and creating a seed for the evolution of the ecology, with interconnected elements.Because the ecology is subject to change, a Coevolution process also starts.The process is carried out by the constant interactions between the activity systems of the NoA and its inner elements (Subject, Tools, Rules, etc.), as continuous Sensemaking is guided by the awareness of contradictions that may occur at different levels. 31us, the dynamics of change are triggered, as proposed by Ralph (Figure 1), thanks to the synergies between the elements of the NoA.There are simultaneous tasks taking place: Sensemaking induces changes; changes lead to contradictions; contradictions generate joint evolution 31 of the NoA; and so on.
Consequently, this modifies the Context Schema and perfects the Design Solution Schema within the process (Figure 1).This solution schema provides, then, the technical background for the Implementation task, allowing the construction of context-specific Software artifacts.In addition, these Artifacts can be further integrated into the model as Components, which previously existed in the form of programming languages, libraries, technologies, and so on and are adapted to complement the whole set.
The Implementation, as well as the other tasks, is not static and is constantly modified, according to the changes to the NoA or its structure.
Underneath of this, for the Subjects that play a role within the NoA (designers, teams, and stakeholders), new learning and knowledge is created because of the interactions induced in the process.In short, the NoA acts as a "core" model that allows articulating and analyzing the evolution of different situations and elements that take part in the design and development of Software-centered ecologies.In an NoA, the change on an element of any of the activity systems (triangles) spreads to the whole set, by virtue of associated stimulus in the form of contradictions.The NoA that represents an ecology, following the SCI approach, acts as a holistic process, generating a manageable, virtually endless, cycle of input, process, output, and feedback.

| SETTING IDEAS
The last section was descriptive and theoretical.In this section, however, a case study will be used as a proof of concept, to illustrate how to apply, in a real setting, all the concepts introduced.For this purpose, a UDS ecosystem is introduced, taken from a real start-up company that has been very successful recently in Spain (we will name it UDS-company for anonymity reasons).In this case study, a few specific roles are considered, to simplify the understanding of the main ideas and to show the construction of a NoA for representing the ecology, by following the SCI principles (Figure 6).The situation shown is focused on activity evolution, by way of identifying and resolving contradictions.In the end, the aim is to illustrate, in a practical way, the theoretical concepts involved, with the intention of bringing them to real practice and to show how they can be extrapolated to other Software-related contexts.

| Defining the initial context
A UDS is a smartphone-based solution in which, through a mobile application (app), customers request products (or services) from any place and receive it at an address in a matter of minutes.This service is built around a smartphone app, the main "tool" in the AT sense, and focuses on the purchase of all kinds of products and services.In practice, these deliveries are mostly related to restaurant food, clothing, books, electronics, or pharmacy products, but the list of potential uses grows each day (for instance, requests to send clothes to a dry-cleaning service and bring them back).In this type of business, there is a cooperation between users and widely diverse organizational and technological agents.However, for the purpose of this example, only these three agents will be considered: • Customers: Individuals that receive or consume products (goods or services) and can choose between different products and Partners (described below).For example: Alice is a person that requests vegetarian food from home.Thus, Alice is a potential Customer.
• Riders: Independent deliverers connected, via smartphone app to the UDS-company.They are people who possess a vehicle (usually a bicycle) and have their own smartphone.Their purpose is to get the most out of their collaboration with the service, by taking deliveries from customers in the quickest and most efficient way.If the minimum delivery rate is 5.50 Euros per order, the Rider gets 70% of the defined rate (at least 3.85 Euros).For example: Roger has a bike and want to earn some money picking orders and delivering them to people like Alice.So, Roger becomes a Rider.
• Partners: Service providers and retailers that are affiliated to the UDS-company and provide their products or services to be used through the app.For example: Bob has a food store that provides vegetarian food but lacks the infrastructure to deliver food directly to the home of the customer.In this way, Bob's restaurant becomes a Partner.For reasons of simplicity, the example will center on the described agents above (Customer, Rider, and Partner), excluding the internal management of the UDS-company.This company will be represented in our discussion by the app itself, but we will not discuss its business structure or its role in the overall ecology.Also, the flow of interactions that arise between Customer, app, Rider, and Partner are much more enriching (in social terms) and interesting (in conceptual terms) than the description and modeling of the UDS-company internals.Hence, as an aid to understanding the operation of a UDS ecology and as an introduction to the case study, Figure 7 shows, in a simplified way, its operational cycle.
The process begins when a Customer (like Alice) sends a requests through the app.Requests are collected, displayed to the available Riders (like Roger) in a specific zone located by the app, and sent to the Partners (like Bob's restaurant) via email, SMS, instant messaging, tablet, or by phone.A Rider close to the Partner and Customer zone (assigned by the app via GPS) will go to the Partner address to pick up the products requested by the Customer as soon as possible, once received the notification in the app.Partners also receive a notification of the order when the app assigns a Rider so they know they can start to prepare it for delivery.The Rider must arrive at the pick-up point within 20 min (a standard time, established by the UDS-company), and the order must be ready for pickup and delivery to the Customer.
At the Partner premises, first, the Rider will take a photo of the purchase ticket or scan the pick-up of the package to see the details of the delivery address.Next, the Rider will input the cost of the product into the app, to charge for his service.Finally, the Rider confirms the delivery at the destination, and the profit is calculated.In general, the overall process should not exceed 60 min.
The operational cycle in Figure 7 and described above shows the ideal situation that the UDS should follow under nominal conditions, according to the pre-established functional design.In this regard, it should be noted that, for task management, the app shows different functionalities and interfaces according to the profiles of each of the agents: Customer, Rider, and Partner (e.g., as it happens with the UBER app, with its two main profiles, for drivers and for passengers).In this way, the Customer will only see the functions specific to this role (order, pay, etc.) and, in a similar way, the Rider and the Partner.However, change happens, and conflicts emerge.In this example, we will examine how a change in the actions of this operational cycle takes place, and how that change can be appropriately managed and approached with the help of the conceptual resources described in this paper (AT, the SCI paradigm, the NoA, etc.).The change we are interested in is schematized in Figure 8.It emerged as a situation that was discovered by the Riders and addressed by them in an ad-hoc way: It happened that, during the application of the UDS nominal operational cycle (Figure 7), some Riders found an ingenious way to improve their revenue.They started to form groups of Riders that share the same Rider account in the app.This is a situation that was not thought of or managed by the original designers of the app and needs to be addressed.In this way, we will discuss below the use of AT to model this ecosystem and the role of contradictions as the source of evolution and changes.

| Building the NoA
To build an NoA, in accordance with the postulates of AT, involves finding the elements that structure the activity system for each of the Subjects involved.For the UDS ecosystem described, let us consider the Customer as an initial Subject.As described, the Customer (as a Subject) performs F I G U R E 7 Operational cycle of an urban delivery service (UDS)-nominal conditions.a series of tasks related to its main activity (request an order).These tasks are guided by the basic Rules that aim towards a goal (Object).For example, as a rule, it is mandatory that the Customer has a credit card.On the one hand, this Rule is required as a precondition to some tasks, also subject to subsequent Rules on how to request an order, pay the order, and pay for delivery.On the other hand, the mechanism or Tool that the activity system provides to the Customer is materialized by a Software artifact (the smartphone app), which must be complemented with other tools in place, like a network.
The role of the Customer is specific from the roles of the Rider and Partner.This specialization within their activity system, in relation to the other agents (Rider, Partner) constitutes a diversification of tasks, that is, what the Customer does is not done by the other agents.In AT language, this is defined as Division of Labor.However, although this apparent "division" seems to separate the roles of each one in terms of interaction, the Customer has a relation with the Partner (to request an order) and with the Rider (to receive the product or service) so they constitute a Community, in the sense of AT.
In this way and using the same general analysis of each participating agent, it is possible to describe the systems (triangles) and how they constitute an NoA.This NoA represents an ecology in which the different activity systems "live" and interact.The main activities for each Subject are shown in Tables 1-3; these elements will be represented later in a graphical way (Figure 9).In a graphical way, the activity triangles of the Subjects involved can be represented (simplified) as in Figure 9.In the figure, the individual activities connected constitute an initial NoA.The details of the Tools, Rules, Community, and Division of Labor are described in the previous tables (Tables 1-3) and have not been included in Figure 9 to avoid clutter.However, it must be assumed that all the elements are there and participate, in parallel and simultaneously, in other interactions and interrelations with the elements of other activity systems that take part in the ecology.
In Figure 9, the Subject and its corresponding Object have been emphasized for each activity triangle to state that they contribute to the same ecology-network, which is kept together by the app (the main "Tool" in the triangles).It should be noted that the interrelationship of the Objects of each NoA system generates a virtual Shared Object 83 that must be understood in the sense of shared objective or goal.This shared goal provides the glue that keeps the elements of the NoA together, according to the dynamic common contexts they share. 84Thus, the Shared Object acts as an indicator of harmony within the NoA.Accordingly, if there are disturbances, they prevent this common Object from being achieved.These problems turn the Shared Object into a potential seed of transformation, 85 as a driving force for the evolution of NoA itself.
As an illustration, a typical Shared Object for a business is to "Maintain a profitable operation."This normally means maintaining sustained revenues while limiting expenses.To achieve this, the different departments, and employees (activity systems) within a company (NoA), even when they try to realize their own Objects (e.g., get customers, produce more, pay workers, etc.) they must adjust their tasks to fit the Shared Object.Thus, if any of the departments "breaks" the harmony of the Shared Object (e.g., production or labor cost overruns), it will induce the rest of the ecosystem in the NoA to correct this situation and adjust accordingly (e.g., cost reduction and sales increase).
F I G U R E 8 Operational cycle of an urban delivery service (UDS)-change introduced.
In the UDS example, the Shared Object, as a general goal, has been labeled (in Figure 9) as "Achieve maximum benefit for all members," which arises from the interrelations of the Customer, Rider, and Partner Objects (Figure 9).If any of the Objects of these Subjects is not achieved in the ecosystem, or it is hampered by contradictions, then the Shared Object "Achieve maximum benefit for all members" will be affected.Thus, the analysis of the NoA through contradictions helps to find the origin of the disturbances that cause corresponding changes in the activity systems, helping traceability and calling for actions aimed to bring back harmony.

F I G U R E 9 Representative Network of Activities (NoA) for an urban delivery service (UDS).
T A B L E 1 Key activity system for the Customer Subject.For each Subject, the actions that each of them performs to achieve its Object are directed and managed through the app.In this sense, the app is the key element that helps to materialize the outcomes desired by the Subjects, such as the payment, the location of the order, and the delivery time.The app, acting as a general "Tool" for all the Subjects involved, was designed and built to meet the guidelines of the Objects established in the activity systems.In consequence, any change in the underlying network elements can potentially alter the overall ecology and, consequently, affect the evolution of the app through further releases.In AT, the reasons behind the changes to activity systems are conceptualized as contradictions, as discussed in the next section.

| Contradictions in the NoA leading to changes
Contradictions, conflicts, and inconsistencies are frequent in any human endeavor, so they have their reflection in activity systems.However, AT sees contradictions as positive events, using them as fuel to elicitate needs that lead to changes, all of them within the contexts in which the activities are being carried out.This positive conception of conflicts and inconsistencies has a long tradition in the field of Requirements Engineering. 86,87 course, these problems also emerge in the UDS example, as it has been taken from a conflictive real-world situation.In the UDS case, it did not require a lot of time for contradictions to emerge since the system was launched, especially affecting the Subjects and some of the Rules, within their respective activity triangles.However, contradictions also affect other elements such as the Division of Labor and the Tools.Table 4 organizes and expands the descriptions of the Rules that were initially established (see Tables 1-3).The information in Table 4 allows, firstly, to reconstruct the general guidelines that shape the actions of the agents involved (Customer, Rider, and Partner) and, secondly, to understand and outline how contradictions arise and act.
Using a visual representation of the rules, they can be summarized as in Figure 10.The figure shows how contradictions, displayed as lightning lines, are mainly related to the Rider's interactions with both the Partner and Customer, in relation to order management.It was established, in the context definition, that Riders that make deliveries receive their profit based on the cost of the order, the route established by the app, the delivery time, and other factors.This means that the more orders a Rider delivers to the Customers, and the less time they take, the more profitable the task will be.Here, a contradiction will emerge between the Rules R3: Pick up the order before 20 min, R4: Prepare the order before 20 min, R5: Deliver the order before 60 min, and R6: Pay delivery.
The contradiction (in Engeström's sense) emerged as follows: In practice, it is unlikely that an individual Rider will be able to cover an area of 10 km or more in radius, because while committed to deliver an order, the Rider should not accept other orders in the same zone until the requested one is delivered (the app blocks other orders in the meantime), hopefully in the minimum time (as mandated by R3: Pick up the order before 20 min, R5: Deliver the order before 60 min).The Rider, therefore, must choose between covering less area by accepting more quick orders or doing more kilometers but accepting only the most attractive (higher cost) orders.It must be pointed out that the Rider receives 70% of the rate estimated by the app for the delivery of the order (see Section 5.1: Defining the initial context, for details).Likewise, it is possible that the Rider may arrive sooner or later to pick up the order with the Partner (R4: Prepare the order before 20 min), hence wasting time and, consequently, losing potential profits (R6: Pay delivery).
T A B L E 4 Rules for the UDS case.

Rule name Description
R1: Request order Rule about the ordering of a product.Orders are performed by a Customer and trigger the process of interactions in the NoA.

R2: Pay total order
This rule takes place as soon as an order is placed, and it is required to guarantee the product ordered.It requires the Customer to have a credit card to process the payment (customer's Tool in the associate AT).

R3: Pick up the order before 20 min
The Rider must meet this standard as part of its commitment to the company that offers the UDS.It is an essential element to guarantee standards of speed and Customer satisfaction in relation to the service.
R4: Prepare the order before 20 min Like the Rider, the Partner offering the product must prepare the order and make it available in this minimum amount of time to guarantee satisfaction in the delivery to the Customer.
R5: Deliver the order before 60 min The Rider must not exceed 60 min as a maximum time to deliver an order.It is a prerequisite for quality of service and Customer satisfaction.
R6: Pay delivery Upon confirmation of delivery, the app credits the payment from the credit card of the Customer to the Rider's internal account.This rule is met as soon as the requested product is delivered by the Rider to the Customer and confirmed by the Customer.
Abbreviations: Noa, Network of Activities; UDS, urban delivery service.
The problem also affects the Objects of the Partner and the Customer: Due to the ecological character expressed by the NoA, the effect spreads in a chain so, for example, the Partner will not obtain its profit until delivering the order to the Rider, and, in turn, the Customer will not be satisfied until the Rider brings the order as quick as possible.These contradictions, therefore, remain in the ecology until someone realizes them and induces a change by, in this case, modifying the way the Rider carries out the activity, while trying to achieve the Object.
Figure 10, for simplicity, displayed an ad hoc representation to express the contradiction in the example scenario.A more formal way of representing contradictions is in the literature 23,88,89 and is exemplified in Figure 11, for the activity system (triangle) of the affected Subject (the Rider, in this case).The figure shows the triangle's problematic interactions (disruptions) within its elements and, therefore, shows how the Object of activity derives in an unwanted outcome.In this way, Figure 11 shows that Rule R3: Pick up order before 20 min, together with the division of labor, impact on the Object causing a "time wasted/money lost" outcome.
The Rider's contradiction is composed by the arrows that collide with the Object as shownin Figure 11.The contradiction interferes with the Object of the activity, but the identity of this Object remains the same, at least for now.What the situation states is that, even if the Rider and the Partner adjust or synchronize their tasks (Division of Labor) and even if the Rider can comply with the Rule R3, a conflicting scenario can emerge, which interferes with the Rider's Object.
Although the intention to achieve the Object of activity remains the same, including compliance with Rule R3, this may lead to unwanted or negative outcomes for the Rider, due to the loss of time which also represents a loss of money.Thus, these unwanted, possibly unexpected, Contradiction in the Network of Activities (NoA) for an urban delivery service (UDS)-using a Rider's activity system representation.
F I G U R E 1 0 Generic contradiction in the Network of Activities (NoA) for an urban delivery service (UDS).
outcomes, point out to a conflictive situation that, in the end, lead the riders to "hack" the activity and thus achieve the Object without interference and, in consequence, to avoid the undesired outcome, as will be explained soon.The situation described occurred in a real case of a Spanish UDS start-up, in which the working conditions offered by the company lead the Riders to look for alternative ways to make their work more profitable (see next section), even organizing strikes that paralyzed all the activity of order delivery until the company offered adjustments to the current form of operation.Although it is not the main focus of this work, it is important to provide real-life examples of contradictions and subsequent adjustments that may (or may not) lead to evolutionary changes 27 in the system and surrounding ecology.

| The Rider's "solution"
An ad hoc controversial solution that Riders in the UDS of the example came out with, to overcome the problem described, consists in creating, oblivious to the company, a new action in which groups of Riders organize among themselves to share the same account in the app.In this way, all orders in a large zone can be accepted, with each Rider covering a specific sub-zone within the larger zone, reducing the stress of going to pick up the order and making minimum delivery times.Later, the Riders share the profits outside the app, of course.Thus, by sharing the same account in the app, they can add up a considerable number of orders in few hours and then divide their income, maximizing the performance of the activity (form the Rider's point of view) without affecting the Partner's or Customer's Objects, at least apparently.
This "solution" provided by the Riders is related to space (areas of delivery), but in addition, Riders applied a similar approach with regard to time (working hours): During the day, there may be some Riders working certain hours, whereas others work at night; all of them share the same account, so "collective" accounts operate for 16, 18, or even 24 h continuously.These hours, obviously, add much more than the 4 or 6 h that a single Rider could cope with.
In theory, this way of solving the contradiction does not affect the overall activity because the Customer's and Partner's Objects are still achieved.Similarly, the UDS-company continues to make a profit, and Customers are satisfied.On the part of the Riders, by rebuilding the activity, they can make more profit than by working individually.Eventually, this situation could lead to further contradictions (for example, when the company needs to track individual responsibility for each delivery).
On the notational side, Figure 12 represents the "solution" that was engineered by the Riders.This representation is important from the notation point of view: If compared with the contradictions shown in Figure 11, the new Figure 12 expresses a solution in which there are no longer "interruptions" in the interactions of the elements that form the activity system.Thus, in this picture, some essential modifications have been introduced; the first is that there is in place a new Rule called Ra, which indicates that the Riders can create "working groups" to share zones and order routes.Similarly, the previous Rule R3 (Pick up the order before 20 min) undergoes a positive change as an extension of the new Rule Ra.This modification of R3 is now renamed as Rb and states that a collaborating Rider in a "working group" can pick up the order before 20 min.
If accepted by the company, both Rules (Ra, Rb) will affect the Division of Labor in a positive way because now, depending on the zone in which the order is placed and the proximity of the Partner, the nearest Rider receives the order to deliver.It must be pointed out that, by sharing the General representation of the "solution" to the contradiction in the Network of Activities (NoA)-using a Rider's activity system representation.
same account in the app, the app will show the proximity to the Partner within the sub-zone that the "working group" has assigned to the Rider (the app does not care, at this stage, about the same account owner being in multiple places at the same time).The Object of the activity remains (Get Revenue).However, Riders obtain other associated outcomes: more orders, better profits, fewer delivery times, less effort (collaborative work), and so on.
This activity rebuilt and redesigned by the Riders will eventually be realized by UDS-company managers, allowing them to have a bottom-up realistic vision of a problematic situation and act accordingly.The company may react (i) by accepting the change as a normalization with a positive impact on the system, which entails allowing the app to offer, as a possible feature, the creation of "working groups" for the Riders; or (ii) the company may react negatively by changing the way the activity is being carried out right now (even with negative consequences); they could, for example, cancel accounts that show a "suspicious" volume of order movements, decreasing the profit margin for collaborative Riders, and so on.Of course, this measure may create further conflict with the Riders that can lead to bigger problems in the future, including lack of commitment, high worker turnout, and even strikes.
In any case, the new formulation of the Rider's activity system within the NoA entails technical and nontechnical implications.An example of nontechnical implication may be: Is it ethical for Riders to share the same account?Technical implications are those that can be addressed in future releases of the app, driving its coevolution with the ecosystem.For instance, would it be possible to allow groups of Riders explicitly in the application?Would it be possible to improve their collective work by adapting the Software (e.g., institutionalizing the Rider's solution) to cope for their delivery activity?From another standpoint, and in relation to the physical management of orders by shared accounts, some issues may These "what if?" scenarios are offered to the reader as examples of questions that trigger reflections about possible contradictions in the NoA and, from these questions, to enact the (re)design of "solutions" that, after some time, will have to confront other new contradictions that will surely arise in the future.This is, in consequence, a Sensemaking task that stimulates the evolution in the example discussed and in other similar contexts.
In this way, the concepts of the SCI paradigm appear as relevant as tools for making sense of this, and similar, situations.Again (revisiting Figure 5), it can be noticed how a change in the Context induces Sensemaking that, in turn, transforms the Context Schema, developing (by Coevolution) new Design Space Schemas that can be materialized in an Implementation.In the example presented, we started from an initial situation that defined a Context articulated on suitable premises (Figure 7).From certain circumstances, such as contradictions (Figure 10), this Context altered its scope of operation and, consequently, the operational perception, that is, its Context Schema (Figure 8).In a similar fashion, the proposed change triggered the Sensemaking of the Riders who coevolutionarily redesigned their Context Schema to adjust it to the changes.
The Riders provide a new solution or Design Space Schema, represented by Figure 12 that can subsequently put into practice (Implementation) by extending the Tool (app) with new capabilities.Thus, the design and assembly of the presented solution (Figure 12) allows grassroots, bottom-up, philosophy, as it can incorporate design decisions emerged from the Riders activity and integrate them into the NoA ecology, coevolutionarily.

| HOW AT AND THE SCI PARADIGM WORK TOGETHER
Previously, Figure 6 presented a model for integration between the NoA and the SCI paradigm, as proposal aimed to the analysis, design, development, and evolution of socio-technical Software-based ecologies of products and services.In this section of the article, this integrative model will be used to show the correlation between the model's elements and the case study.
It will be assumed, as Ralph pointed out, 16 that the app provided by the UDS-company was built using processes similar to the SCI paradigm in its original form (Figure 1) and provides its functionality from an initial design originally planned for the context and conditions that were described at launch time.However, as it develops through time, the systems of activities in the ecology lead to contradictions, both because of the activities of the Subjects and as the context evolves by itself.Consequently, the functionalities of the app must be reoriented to sync with these changes.Considering that change is seen as the answer to contradictions, identified in the NoA (Figure 10), a model that allows the use of an NoA within the SCI paradigm can be built based on those contradictions, with the addition of some initial elements that existed before any contradiction took place, such as Prior Knowledge and Components.This is shown in Figure 13.
Starting with the elements in Figure 13, the model will be mapped to the case study.To illustrate this, the dynamics of the model have been structured according to the specific SCI tasks, as described below.The main purpose is to create a framework of ideas that leads to a practical understanding of the NoA-SCI model based on the interpretation of its elements, the interactions between them, and the people who carries them out (e.g., designers and developers).

| Sensemaking tasks
First, as shown in Figure 13, Prior Knowledge is the knowledge that is in place initially, before the app was designed, but somehow providing reasons that encourage the design of the app.Some of the knowledge items included are the future capabilities of the app, its surrounding context, the needs, and how the app will work, including any other explicit knowledge that was used at this early stage of the development.This knowledge is structured and adjusted through specific actions that include the organization and reorganization of new aspects that the NoA analysis provides.Thus, for example, it is possible to evaluate aspects that arise naturally from the use of the Software (app) that were not originally perceived by the designers but emerged later, as possible solutions to the contradictions found by analyzing the NoA.In this way, by organizing this Prior Knowledge, and by finding associations with new practical knowledge derived from the NoA, it will allow to conceptualize potential improvements that will lead to a (re)design of the Software.This is achieved by considering the changes to the overall context and, from these, building new features related to those changes.This process is rationalized and carried out in terms of the "S" of the SCI paradigm, Sensemaking.
In the example, Sensemaking is activated after detecting that the Riders can "hack" the original features of the app with a different use, to improve their ability to carry out their activity, by mutating it from an individual to a collective effort.Designers, after realizing this, may choose to react by using this new information in combination with previous beliefs (Prior Knowledge) to readjust and reorganize the app's functions.

| Coevolution tasks
A process of Sensemaking is not disconnected from the Coevolution task (Figure 13).The actions that lead the Coevolution arise from the questions raided by the contradictions detected in the NoA and from how these contradictions are dealt with, using their resolution as a reorganization mechanism.The reorganization through Sensemaking leads to a better understanding of the situation, which leads to new features for app (re)design as, for example, new user interfaces, new policies (Rules), and so on, to be implemented in subsequent releases.The redesign is synched to a modified context in a natural way.However, although this new (re)design can implement the changes derived from the resolution of the contradictions that have arisen, it may or may not have a positive interference in the systems of activities for each Subject and their Objects, within the NoA.For example, if a new design restricts the minimum number of orders that a Rider can place (to avoid multiple uses of an account), it would be unattractive for them to continue providing the service.It could also happen that the app allows the creation of groups of Riders, but, on the other hand, it increases the fees for the service provided or is otherwise charged to the Customer or Partner, discouraging them from using the service.Thus, the process of Coevolution must be consciously managed and achieved through Sensemaking actions.
F I G U R E 1 3 Network of Activities-Sensemaking-Coevolution-Implementation (NoA-SCI) model applied to the example.

| Implementation tasks
The Implementation actions consist of developing solution proposals that arise from the Sensemaking and Coevolution tasks.As shown in Figure 13, these actions are supported by the pre-existing technological Components, which act as support for the actions to be carried out, allowing their Implementation (just as the Prior Knowledge allows the Sensemaking task).Like the other components of the NoA-SCI model, Implementation actions occur in parallel with the other two.They act as soon as Sensemaking and Coevolution actions take place, in a continuous process.Thus, these Implementation actions acquire its form thanks to Sensemaking and Coevolution.Specifically, the perception of these Implementation actions for the Design Agents is given by the operations of creation and construction of the artifacts necessary for the (re)design of the Software, using previously available Components.This includes, for example, user interface development, code enhancements/extensions, algorithms, and new features.On the other hand, for users (the Subjects in the NoA), the Implementation actions will be perceived as an adaptation of the Software (app) that impacts positively or negatively on their activities and on the established collaborative ecology.
In the example presented, this Implementation is given by providing new app features, which may include (if the management considers acceptable) mechanisms for the collective work of Riders via group creation, restrictions on the number of hours a Rider can be working, new algorithms to detect simultaneous displacements of a Rider in the same zone, and so on.

| Emerging contradictions and continuity of the process
The overall process is highly dynamic and self-controlled.At the level of the NoA, even if the Objects of each Subject are achieved, the process can be completely re-fed back as soon as changes in the context occur by, for example, including other Subjects, creating other activities, adding new functions, and changing the design and objectives.
This dynamism is stimulated, essentially, by new contradictions that can be understood from the NoA, analyzing the Subjects that act in it together with their corresponding activities.Likewise, contradictions will arise in other aspects that are unrelated to the central NoA, but that may affect it collectively, such as a change in the basic technology of the Software.In this way, over time (Figure 13), the Design Agents and the NoA's participating Subjects will be in a constant production of contradictions that generate questions; these questions lead to resolutions that activate the reorganization and adjustments through Sensemaking; solution spaces will arise then through Coevolution, and these solutions will acquire a tangible form through Implementation, and so on, recreating again the whole cycle described by the NoA-SCI model.
In the proposed example, this process is repeated as context elements keep changing, and consequently, the harmony of the ecology is altered, affecting the activity systems, the NoA, and so on.For example, a future government policy that requires Riders to be formally registered and their vehicles properly licensed would automatically disrupt the whole set through new systematic contradictions; it would force to redefine all or part of the operative of the NoA (Figure 9) with implications that run from the social (communities, divisions of labor, rules) to the technical (redesign of the app).

| SUMMARIZING
As described in the previous sections, it is feasible to develop and conduct a practical design mechanism applied to SE efforts by relying on the marriage between AT concepts, the SCI paradigm, and evolving ecologies.With this purpose in mind, the initial action is to describe the context that will be analyzed, establishing the Subjects that interact in the observed context and the Objects that stimulate them to carry out their tasks.
From the identified Subjects and their corresponding Objects, their activity systems can be created as shown in Tables 1-3.In these systems of activities, the components that shape the triangle of each Subject (Tools, Rules, Community, and Division of Labor) are structured and organized.In other words, they allow the design of a generic instrument in which the activity of a Subject can be interpreted.This characterization is important since, as previously explained, from these individual systems of activities, an NoA is constructed and defined as illustrated in Figure 9.
Based on the structure of the NoA, a higher-level view is determined for looking at the context and the interactions between the elements contained; that is, an NoA acts as an instrument to map and articulate the behavior of the different actors in the ecology.This conceptualization offers a great fluidity to appreciate, for example, the versatility with which changes occur and how they can affect the dynamics of the whole.In SE terms, constructing an NoA becomes a useful tool to manage situations that involve individual and social behaviors and actions that have a direct impact on a particular Software, as in the example.
Another important aspect is that, using an NoA, we can detect contradictions that generate changes and introduce improvements or adjustments.These contradictions, once analyzed and dealt with in their situation, describe possible conflictive actions for the context, but simultaneously, they allow the creation of resolution proposals that can later assume the form of Software requirements.In combination with the SCI paradigm, the analysis of the NoA, and the associated contradictions, a proper scenario is created for the evolution of a design and the solution space for an SE effort able to accommodate and assimilate changes over time, in an evolutionary and natural way.
This opens the possibility, for example, of predicting behaviors and future trends in user behavior, by means of the analysis of contradictions in the NoA.This includes the discovery of behaviors and tendencies that break the flow and lead away from the main objective, allowing to establish action-contingency protocols and manage evolution.These approaches and conceptualizations also open the door to create tools to support and automate certain tasks of particular interest, such as NoA definition or contradiction analysis.In this sense, we can provide a preliminary procedural guide using Algorithm 1.In this representation, we try to formalize and synthesize the ideas exposed throughout this work.
However, the algorithm must be understood as a general process that synthetizes the NoA-SCI interaction process within an ecology and allows a practical and evolutionary approach, as advocated in this article.
Algorithm 1. Algorithm: Procedural Model of Interaction and Integration NoA-SCI.
The proposed process/algorithm starts by defining some general structures to describe the activities, the NoA, and so on.From this, it relies on a series of activities of interest, which will be the framework on which the phases of the NoA-SCI process will develop.Once this set of activities has been identified, an NoA is constructed, structuring the respective elements of each activity of interest.If there is a series of activities of interest, its Coevolution is reviewed from the analysis of its contradictions in the created NoA.For each of the contradictions found, a Sensemaking process is applied, which will detect changes in the context for eliciting further Implementation mechanisms, that must be reflected in an updated Design Space Schema.Through Coevolution, using the suggested context and the initial Design Space Schema, new solutions, working protocols, and so on are produced, building a new Design Space Schema that will be implemented as a Design Object.
Finally, when changes are detected in the process (after the Design Object was deployed into a context), it is evident that the initial activities of interest are modified, and these changes must be detected to create a new set of updated/evolved activities with their respective NoAs, which will be used as new "input" from which a new iteration of the whole process is performed.

| LIMITATIONS
This work attempts to provide a step forward in the development of conjectures to understand and improve the vision of the intrinsic processes of Software development and evolution.Thus, the proposal outlined is still very theoretical and covers topics "out of scope" of some technical discussions related to Software.Therefore, it has some limitations that will be pointed out.
• Tasks automation: Specific tasks, such as the drafting of NoAs or the assembly of their components, need to be automated.For example, the increase in activities, Subjects, Tools, and so on, can exceed the capacity to model and harmonize an ecosystem in an efficient way.A significant step forward will be to develop automation tools that allow the performing of these tasks.
• Analysis and solving for "batch" contradictions: This limitation is associated with the previous one.The modeling of a significant volume of contradictions generated during an analysis process may represent a challenging task.Therefore, mediation mechanisms associated with these scenarios must be developed.
• Management of changes: Changes arising from contradictions should be better described and documented.In this sense, appropriate formalization for submission, acceptance, or rejection of changes remains to be established.
• Multi-context testing and validation: While some preliminary implementation tests suggest a positive impact, more extensive testing is needed to cover different usage scenarios for the approach developed.

| CONCLUSIONS AND FURTHER WORK
This paper focused on some evidence that point to recent challenges in SE that surpass the scope and capabilities of technical and non-technical historical, traditional approaches.In trying to address the research question posed in the Introduction, the paper explored how new spaces, aimed to solve current and future issues, can and should be conquered by taking inspiration from other sciences and disciplines.In this regard, the field of Psychology provides well-tested approaches that make easy to integrate, organize, materialize, share, construct, and, in few words, bring to practice, a hands-on approach for dealing with the complexities of socio-technical ecologies and their contexts.
In this way, this paper brings a more practical orientation to novel theoretical interdisciplinary solutions aimed to deal with some of the "soft" and elusive characteristics currently emerging in contemporary SE, such as the management of design complexity and the switch from "systems" to "ecosystems."In this regard, proposals like the evolving ecologies and the SCI paradigm, developed, respectively, by Jarke et al. 15 and Ralph, 16 were summarized and explained.Although the conjectures of the cited works provide an update to classical concepts, their greatest challenge is to bring them to a practical and methodological setting.This is not trivial, due to the lack of concrete instruments and representations for capturing, managing, and communicating the details of abstract underlying concepts (like "context" and "evolution").
As a possible solution to this problem, this paper proposed the construction and use of representational artifacts based on AT, due to its capability to deal with highly dynamic and complex situations.AT uses a holistic perspective to express contexts and other scenarios, moving away from the relative inflexibility and verticality of mainstream Software and System Engineering approaches.As a resource, AT provides a useful and flexible formalism, with multiple successful applications in different fields.Therefore, it can support in many ways the interpretation and understanding of complex scenarios that include human components, actions, and tasks, using explicit components such as tools (including technological ones) or implicit ones such as motivations and other subjective factors.The potential of using AT for the approaches discussed points to the building of ecosystems represented as NoAs, with the NoA formalism.Other underlying benefits (visibility of the whole, organization, identification of contradictions, etc.) can be extended to complement other features that exist in current SE practices.
Our approach has shown that, through AT, it is feasible to address the most difficult aspects posed in the research question.For example, in agile development methods, systems of activities structured around the subjects involved (stakeholders, designers, etc.) and their complementary elements (Tools, Rules, etc.) as well as the individual Objects of each system can provide metaphors that extend the User Stories. 13,90This integration is possible since AT can operate as a high-level abstract notation (via the NoA) and is able to summarize complex contexts and individual or group interactions; thus, it can be used to complement, not substitute, approaches like UML Use Case Diagrams or User Stories.
Similarly, the use of NoA as a guide for design provides a mechanism for managing the complexity that arises in projects with multiple people, objectives, goals, and conflicts.A sense of organization comes by capturing and rationalizing ubiquitous but powerful elements (Tools, Subjects, Rules, etc.) that describe complex situations and even allows the detection of potential areas for improvement (through the contradiction mechanism).This clarifies not only the human and social aspects of the process but also provides insights into the interrelationships that reflect the ways of working of the people involved, and how they carry out their tasks operationally.
On another side, the NoA concept, by which evolving ecologies can be represented as technological contexts, provides a material basis to a paradigm such as SCI.In this sense, the NoA acts as mediating metaphor for visualizing, understanding, and managing the complex interrelations between different elements.Additionally, it provides an instrument for the materialization of concepts because, as shown by the NoA-SCI model, the malleability of AT can be directed to the development of theoretical and practical models that guide some of the processes involved in a Software development effort, such as the gathering, control, and management of versions, particularly due to the traceability related to the contradiction-guided evolutions, which must be analyzed as part of future configurations.
Some practical considerations for the use of the ideas shown here require further development.In this sense, the authors are carrying out research focused on the automation of processes to build the NoA and facilitate the analysis of the elements in each activity system.Particularly, we work on the management and treatment of the contradictions that arise because of the interactions between NoA components and how they lead to changes and evolution, by taking advantage of their interconnections.The preliminary advances are leading to the construction of a process that is expected to be part of future evaluations, tests, and result analysis, through implementation in real contexts.
In general, this process (as presented in Algorithm 1) would make easier to deal with socio-technological contexts, through the NoAs, and to deal with the contradictions that arise in situations that require the design and development of deeply integrated Software, such as in the domains of Internet of Things (IoT), Mobile Biometric Technology for access to online transactions or personal information, 91 Human Behavior Modeling for assisting customers in their purchases (by offering possibilities and different options in the products to purchase), 92 and so on.
Another potential contribution of our approach arises by leveraging some features and side effects offered by AT.For example, by creating shareable artifacts, it would be possible to use the formalism and associated notations, which are technology-agnostic, for the exchange of ideas and information between stakeholders who share a common context but with different goals (e.g., users vs. developers or different types of users like riders vs. service providers, etc.).Also, from these features, new mechanisms and techniques can be created and developed as solutions to specific problems.We can think, for example, of a series of Software requirements that could be reinterpreted as part of the set of Rules within a system of activities (or NoA).This is feasible by considering the idea that AT allows the enrichment of representational concepts, situations, and behaviors, through the characteristics present in a NoA-SCI model.
Finally, it can be concluded that it is possible to use AT (and meta-AT) instruments such as the NoA to establish, through these multidisciplinary proposals, new perspectives of solutions aimed to address particularly complex issues and to complement other analytical resources.In this sense, AT and NoA become instruments with considerable value by providing a communicable, highly flexible, useful triedand-tested resource.
alignment and coordination of Software development projects (Theory of Distances in Software Development), (2) provide an understanding of the dynamics and persistence of changes that occur during the development of Information Systems (Theory of Persistence and Change in Software Development), (3) apply in the computer game development industry components of the Agile methodology (Play-Test Boomerang), and (

F
I G U R E 3 General representation of a contradiction in an Activity System.
Sensemaking task acts by dealing with the elements that AT considers part of the context of any activity: Rules, Tools, Community, and Division F I G U R E 5 Proposed mapping of elements: Sensemaking-Coevolution-Implementation (SCI) paradigm and Network of Activities (NoA).

F I G U R E 6
Network of Activities (NoA) ecologies and dynamic interactions with the Sensemaking-Coevolution-Implementation (SCI) paradigm.
emerge that need to be addressed: What happens if a Partner exceeds the minimum order preparation time (R4)?If a Rider does not show up to pick up the order (R3), what action should the Partner take and how that affects to other Riders sharing the account?If an individual Rider fails to deliver the order within 60 min (R5), what happens to their peers?What action does the Rider take if the Customer does not accept the order (R6)?
Key activity system for the Partner Subject.Key activity system for the Rider Subject.
Partner: prepare order.Send order.Rider: receive verify and deliver the order to Customer.Customer: requests order.Pay Rider and Partner.