Download - Istar14 jpc-xf-pres
Group of Software EngineeringU N I V E R S I D A D D E C U E N C A , E C U A D O R
Lessons Learned on the use of i*by Non‐Technical Users
3
Motivation (1/2)• Early phases of the enterprise engineering process are oriented to model the enterprise context
• Enterprise context models include environmental actors and their relationships. Help understanding: the purpose of enterprises in their environment what is required from them how they generate value
Enterprise context models may be difficult to build:• communicational gaps among technical and administrative personnel
• limited knowledge of the enterprise structure, operations and strategy
4
Motivation (2/2)To deal with these problems, we have used i* as:• communicational means between stakeholders• framework to discover business architectures• language to define enterprise context patterns
In this paper, we focus on the first aspect
5
Purpose of this workWe planned and conducted an empirical validation case:• intended to measure the ability of non‐technical stakeholders to learn and use the i* notation in an industrial setting
6
Background – DHARMA method4‐phase method for constructing EAs with i*
DD
1. Enterprise context
model (CM)
2. Introdu‐cing thesystem
3. Impactanalysis
4. Architec‐ting a solution
7
The case study• Medium size (10K students) private Ecuadorian univ. DHARMA method used to define the IT strategic plan and project portfolio
• First step was the construction of the i*‐based CM. 13 Organizational Areas (OA) contributed All stakeholders from them were non‐technical:
• operational, mid‐management and management staff
• lawyers, business administrators, psychologists, librarians, economists, accountants and communicators
9
Lessons learnedCategorized in three phases:
Induction(3 lessons)
Execution(5 lessons)
Consolidation(2 lessons)
10
Lessons learned: Induction (1/3)
Provide a road-map to perform the work
Provide a road-map to perform the work
Provide basic training1
22
Provide guide-lines to improve quality
Provide guide-lines to improve quality33
Focused sessionsNot too ambitious
11
Lessons learned: Induction (2/3)Provide a road-map to perform the work2Provide basic
trainingProvide basic training11
Clear outcomesPrecise timeline
12
Lessons learned: Induction (3/3)Provide basic trainingProvide basic training11 Provide guide-
lines to improve quality
3Provide a road-map to perform the work
Provide a road-map to perform the work22
methodology
execution notation
13
Lessons learned: Execution (1/5)Help users to manage size4
Break the modelAllow non-graphical representations
14
Lessons learned: Execution (2/5)Avoid the use of specialized tools
Help users to manage sizeHelp users to manage size44 5
Time-consuming and rewardlessLet them draw and excel-ise!
ActorDependency
TypeDependency Direction
Goal Agreements signed →Resource Agreement Documents ←Goal Technical formation provided ←Resource Teachers ←Resource Infrastructure ←Goal Syllabus Prepared ←Resource Curricula & Contents ←Goal Curricula Approved →Goal Contents Approved →Goal Grades and assistance registered →Resource Grades and assistance records →Resource Grades and assistance formats →Goal Enrollment/Inscription recorded →Goal Admission exams taken →Resource Regulations and Certificates →
01.03 Institutes
15
Lessons learned: Execution (3/5)Help users to manage sizeHelp users to manage size44 55 Do not over-
constrain user’s imagination6Avoid the use
of specialized tools
Avoid the use of specialized tools
Methods, notation, …
16
Lessons learned: Execution (4/5)55 Do not over-
constrain user’s imagination
Do not over-constrain user’s imagination66 Do not expect
excellence7Avoid the use of specialized tools
Avoid the use of specialized tools
Help users to manage sizeHelp users to manage size44
1
They have not become experts!Flaws are easy to identify and correct
17
Lessons learned: Execution (5/5)55 Do not over-
constrain user’s imagination
Do not over-constrain user’s imagination66
Avoid the use of specialized tools
Avoid the use of specialized tools
Help users to manage sizeHelp users to manage size44 Do not expect
excellenceDo not expect excellence77
1
8Review & pro-vide feedback continuosly
Stakeholders will require continuous but decreasing feedback. Operational profiles require less corrections than managerial
Dependencies Operational Area (OA) Nb. of Participants Job Position
Nb. Correct26 30%Treasury 1 Operational 91 28%Research Deanship 1 Operational 52 27%Libraries 1 Operational
39 26%Administrative Coordination 1 Mid-manager
184 20%Faculties 6 Mid-manager
94 15%Communications Department 2 Manager / operational
84 14%Students Welfare 3 Manager / operational56 13%Financial Direction 1 Manager68 12%Graduate school 1 Mid-manager
54 6%Professional / ContinuingEducation 1 Manager
18
Lessons learned: Consolidation (1/2)Plan for validation activities9
Reconcile different styles i*-compliantManage large scale
External
(ECA
)
Internal
(ICA)
Total
Goal
Soft‐Goal
Task
Resources
800 550 61 22 167Type 179 155 3 6 15Description 448 372 19 8 49Direction 217 155 17 7 38Deleted 20 13 1 3 3
Correct 221 90 35 6 90239 65 45 15 114
Area
Actors Dependencies
Included in CMs by
Total 69 53
Incuded in non‐technical stakeholders CMs
Incorrect
Added by consultant
19
Lessons learned: Consolidation (2/2)Be aware of consolidation activities10Plan for
validation activities
Plan for validation activities99
Putting together 13 different models
20
Conclusions
Positive side:• Set of lessons learned identified• Stakeholders agreed that the actions described in this work helped in the successful conduction of the case
Negative side:• Still the use of i* without an i* expert remains a challenge