1. Software engineering for supply chains:
Professor Aditya Ghose
Director
Decision Systems Lab
University of Wollongong
University of
Wollongong
Decision Systems
Laboratory

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

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

4. 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

5. 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

6. 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?”

7. 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

8. Augmenting supply chain modeling
Agent-Oriented Conceptual Modeling

10. 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

11. 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

12. 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

13. 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.

14. Notation

15. 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).

16. A Strategic Dependency model for computer based training system

17. 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.

18. Strategic Rationale model for computer based training system

19. Supply chain configuration

20. 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