Software engineering for supply chains: Professor Aditya Ghose Director Decision Systems Lab University of Wollongong aditya@uow.edu.au University of Wollongong Decision Systems Laboratory

Key steps in SE Requirements engineering Software specification Coding Verification, validation, testing Maintenance All of these questions are of interest to supply chains!

SE for SCs We will look at supply chain: Modeling Configuration Optimization Simulation Execution and monitoring

Current projects @ Decision Systems Lab, University of Wollongong Constraint-based production scheduling (steel sector) Integrated constraint-based planning and scheduling (steel sector) Constraint and market-oriented programming in scheduling (steel sector) Optimal truck dispatch systems (mining sector) Optimal manpower scheduling (with an employment agency) Enterprise modeling (with a government emergency services agency) Organization learning (defence sector) …in addition to R&D into new technologies (constraint programming, agent technologies, automated negotiation, software engineering) Current total funding: Approx. $2 million

Supply chain modeling A range of techniques, from diagrammatic, to mathematical Problems: No single notation is adequate No means of modeling stakeholder intentions (why was the supply chain configured in this way? What were the high-level stakeholder goals? What were the original intentions to achieve these?) Model revision Re-engineering Executable models Methodological questions: Modeling methodologies Model maintenance/revision/re-engineering methodologies

Intentional modelling Key challenges in modern software development: Understanding and representing the organizational context in which the target system will be situated Making explicit the intentional aspects of all artefacts developed over the software life-cycle “Why was this design decision taken?” “What were the analyst’s intentions in formulating this requirement?”

Intentional modelling:II Representing intentions and organizational context are important for several reasons: Managing change (requirements evolution, design modifications, code updates Re-engineering Notions of requirements/design rationale are well-known, yet not reflected in modelling notations

Augmenting supply chain modeling Agent-Oriented Conceptual Modeling

Why Agent-Oriented Modelling? Intentionality is an inherently anthropomorphic notion The notion of an agent buys us a repertoire of anthropomorphic (modelling) handles: beliefs, goals, plans, tasks, dependencies, optimization objectives Agent metaphor powerful in modelling organizational contexts This does not commit us to agent-oriented software development

The i* modelling framework Models built around the organizing locus of an actor/agent Social modelling via inter-agent dependencies Internal intentional aspects of actors modelled via: goals, softgoals (these are novel), goal decompositions, task decompositions. The i* modelling framework is a semi-formal notation built on agent-oriented conceptual modelling The central concept in i* is that of the intentional actor agent. Intentional properties of an agent such as goals, beliefs, abilities and commitments are used in modelling requirements. The actor or agent construct is used to identify the intentional characteristics represented as dependencies involving goals to be achieved, tasks to be performed, resources to be furnished or softgoals / desires (optimisation objectives or preferences) to be satisfied. The i* framework also supports the modelling of rationale by representing key internal intentional characteristics of actors/agents. The i* framework consists of two modelling components: Strategic Dependency (SD) Models and Strategic Rationale (SR) Models

An industry-scale application Enterprise modelling for an emergency services agency Unique IT infrastructure: normally dormant, “wakes up” for emergencies Modelling process can be slow Elicitation poses major challenges Given the relative infancy of agent-oriented conceptual modelling notations (including i*), few attempts have been made to deploy them in industry-scale settings. This paper presents some proto-methodological principles and lessons derived from a collaborative project to build a comprehensive enterprise model for an emergency services agency (this is also one of the earliest attempts at industry-scale deployment of agent-oriented conceptual modelling techniques). The emergency services agency offers some unique features, such as an infrastructure that remains dormant for long periods of time but gets activated during an emergency. These features make traditional conceptual modelling somewhat difficult to use, but renders the domain eminently suitable for the deployment of agent-oriented conceptual modelling techniques

The components of i* modelling framework The Strategic Dependency Model (SD) The Strategic Rationale Model (SR) The SD and SR models are graphical representations that describe the world in a manner closer to the users perceptions. The SD model consists of a set of nodes and links. Each node represents an “actor”, and each link between the two actors indicates that one actor depends on the other for something in order that the former may attain some goal. An SR model represents the internal intentional characteristics of each actor/agent via task decomposition links and means-end links. The task decomposition links provide details on the tasks and the (hierarchically decomposed) sub-tasks to be performed by each actor/agent while the means-end links relate goals to the resources or tasks required to achieve them. The SR model also provides constructs to model alternate ways to accomplish goals by asking why, how and how else questions.

Notation

The Strategic Dependency Models: An Example A Strategic Dependency model for computer based training system An example concerning a computer based training system (CBT) for volunteers of emergency services will be used to illustrate the Strategic Dependency (SD) Model notation (shown on the next slide). The modelling process begins with identifying the actors/agents involved with the CBT system and their mutual dependency relationships (using the taxonomy of dependency relationships described above).

A Strategic Dependency model for computer based training system

The Strategic Rationale Models: An Example Strategic Rationale model for computer based training system (Describing intentional relationships that are “internal” to actors) In the i* framework, the SR model provides a more detailed level of modelling by looking “inside” actors to model internal intentional relationships. Intentional elements (goals, tasks, resources, and softgoals) appear in the SR model not only as external dependencies, but also as internal elements linked by task-decomposition and means-ends relationships. The SR model in Figure 2 thus elaborates on the relationships between the Training Co-ordinator, TrainingSystem and Volunteer as represented in the SD model previously.

Strategic Rationale model for computer based training system

Supply chain configuration

Supply chain configuration: II We need configuration tools that: Incorporate an explicit notion of stakeholder goals and softgoals (optimization objectives/performance goals) Permit users to explore the implications of alternative configurations on stakeholder goals and softgoals Exploit the technology for executable models (discussed earlier) Incorporate existing network configuration technology Methodological questions: Procedures for articulating in detail special classes of softgoals (such as safety) Overall configuration methodology