KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
3posters from i starshowcase v5 posters
1. Modelling Requirements for an Integrated
Management System for Civil Construction
FINEP Fernanda Alencar1, Jaelson Castro2, José R R Menezes3, José J R Silva3, Emanuel Santos2
1 Dep. Eletrônica e Sistemas, 2 Centro de Informática, 3 Dep. Engenharia Civil,
Laboratório de
Engenharia de
Requisitos
www.cin.ufpe.br/~ler
Universidade Federal de Pernambuco - UFPE, Brazil
fernanda.ralencar@ufpe.br, {jbc, ebs}@cin.ufpe.br, {jmenezes, jjrs}@ufpe.br, {jbc, ebs}@cin.ufpe.br
Introduction
Motivation
Environmental Management System (ISO 14001)
The IMS Project Occupational Health and Safety Assessment Services (OHSAS 18001)
Quality Management (ISO 9001)
Environmental Occupational Health
Management and Safety Proposal
System Assessment Services The “Integrated Management System for Civil Construction – IMS” project
(ISO 14001) (OHSAS 18001)
Compute the results of the internal inspection
Detect non-conformities to the standards
Quality Management Reduce small errors related to incorrect filling of auditing forms
ISO 9001)
Partners
Civil Engineering Industry, academic and Brazilian government
Objective
The development of the Integrated Management System (IMS), in order to support for integrated management of civil construction
organizations aiming at their sustainability
The Approach
Elicit stakeholders Consider current i* (iStar) Crash Construct i* Validate i* Propose initial
needs Information course * Models models architecture of the
(Imeetings) Systems IMS
The Proposal
1a. The Strategic Dependency Model of the IMS 1b. The Strategic Rationale Model of the IMS 2. Initial architecture of the IMS
Lessons Learned Conclusions and Future Works
Conceptual model of integrated management system in
Elicitation with i* place, with certification in two construction companies.
Excellent mechanism for elicitation of stakeholders needs, Seven (07) construction companies have benefited directly
intentions and desires from the activities of this project, participating in courses and
Help to keep focus during discussions with our partners seminars
Reasoning with i* Fifty (50) companies had direct access to project results
Civil engineers exposed to i* Future works
Requirements Engineering is not common in civil Complete the IMS development
construction Validate IMS
High learning curve Further case studies
Dealing with complexity and scalability
iStar Showcase 2011 59
2. Managing
Requirements Knowledge –
A Case Study on Control Systems
Dominik Schmitz1, Matthias Jarke1,2, Hans W. Nissen3, Thomas Rose2
1 RWTH Aachen University, 2 Fraunhofer FIT, 3 Cologne University of Applied Sciences
1 Problems 2 Solution
Innovations in Control System Engineering Start
St t keyword based
• Model based capture of
Model-based
shared history
requirements with i*
Innovations in cars nowadays with same customer
Choose • Domain models to
domain model
are mainly driven by software, add another
represent particular
domain refinement
but control systems and model extension
knowledge/experiences
software engineering clean up (tool
supported) • A situational method
Project-specific
currently do not interact requirements
model engineering approach to
⇒ methodological comple- manual, in-depth similarity search support the development
investigation
mentarity is hindered process
Identify related
Application domain: combustion engine controller historic projects • A similarity search for
decide on reuse add, refine
projects at the level of
model-based
transformation
First system design
requirements
Specific Characteristics of Small- and & cost calculation
• Continuous model-based
Medium-Sized Enterprises (SMEs) Detailed design
Feedback via development, esp.
[Details omitted] domain model
• Dominate in individual control systems engineering Implementation
updates
model transformation
• Profound knowledge in a particular, narrow field as [Details • Support for evolving
omitted]
itt d]
the core asset of the enterprise
Finalize project/
reflect domain knowledge
• High frequency of innovations – knowledge, Stop completeness
strategy
Start
Stop
experiences evolve quickly Choose
completeness strategy
Explicit decision to
domain model
• Focus on specific customer issues with very individual
domain model base update domain model(s)
Technologies remove add
problems and solutions ⇒ no opportunities for
Project-specific
requirements
model manual inspection
manual inspection & consolidation
• i* for modeling Identify related Identify candidates Identify candidates
planned product families historic
projects
for deletions for extensions
• Telos/ConceptBase for Detailed design
suitably frequent,
above threshold
suitably frequent,
above threshold
Identify project-
model management specific
deletions
Relate recurring extensions
among several projects
Need for an integrated approach to Implementation
investigate
recent project structural
anchor object
based
• Eclipse platform
text-based similarity
similarity
Start similarity
investigate
Finalize project/ project Extract project-
manage requirements knowledge
recent project
reflect base specific extensions
• Java-based Stop Decouple via databases
Concerns a single project Concerns all (recent) historic projects
3 Application Details
Pre-defined queries Ad-hoc, user-
referring to the domain model defined queries
Domain models
• Common starting point
Query
• Accelerate modelingg weights,
g , Overall
sum up ranking
• Tailoring/update possible to 1
IN ACCORDANCE: diesel
MISSING: gas
Step 1: Take design decisions
Earlier projects Objects from current project
stored in the database that occur also in the earlier project
Step 2: Core mapping
requirements model
(PIM)
Similarity search
manual, refined model
(PIM)
& new anchor object-
support for Step 3: Incorporate
checking readiness
hardware based similarity measure
details
automated
Matlab/Simulink
M tl b/Si li k model
d l
Model (PSM – Matlab)
(PIM – RCP)
transformation interactive,
add RCP platform
specific libraries specific libraries considered
(PSM – RCP)
Evolution (over t)
Project Partners and Industry Involvement
iStar Showcase 2011 60
3. Designing the Trentino Innovation Network:
Applying Tropos to TasLab
Fabiano Dalpiaz, Paolo Giorgini – University of Trento, Italy
Valentina Ferrari, Stefano Tinella – Informatica Trentina, Italy
Context: the TasLab initiative From goals to services
1. Represent stakeholders’ needs via Tropos goal models
TasLab (Trentino as a Lab)
An innovation network for the ICT sector
Trentino Province, Italy
Focus on innovation for the public administration
Why such initiative?
Trentino is a research-intensive territory (+1000 researchers in the ICT
area, population ½ million)
Autonomous governance allows for experimenting innovation in the
public sector
Implementation facilities for research: +700 SME in the ICT sector
Innovative Lead User: local public administration
The TasLab cornerstone: the Innovation tripole
The synergy between research, industry, and users creates innovation
2. Cluster goals according to
macro-categories:
3. Link goals to TasLab
Towards TasLab: a set of coordinated initiatives
We consider a project concerning the organizational design of the
services
Introduce TasLab as
TasLab innovation network1
system-to-be
Services are tasks
Link via means-end
The Alignment Problem relation
The project included several concurrent activities
Top-down: interviews to elicit stakehoders’s needs and constraints from
4. Check alignment
the TasLab vision
Most goals supported by
R1. TasLab has to be a legal
R1. TasLab shall innovate services
entity
ICT services via industry- Some goals will be
Province of R2. Researchers involved in
research cooperation
Trento (PAT) R2. …
strategic decisions supported by adopting
Researchers R3. … best practices
A few goals not supported
Industries • e.g. feedback on
R1. Companies shall play a more project proposals and
important role in ICT innovation
… completed projects
R2. …
Bottom-up: organizational design of the innovation network
Services to offer to participants (e.g. scouting, funding, dissemination, …)
Business processes to support these services Benefits Lessons Learned
A problem of alignment! Effective communication to × Users understand a subset of
Are the needs and constraints supported by organizational design? people with different profiles the language concepts
Are there services/processes stakeholders do not need? Managers
Researchers × Input data heterogeneity makes
System analysts modelling hard
Our Approach Developers Different levels of abstraction
(strategic vs. operational)
Social dependencies useful to Different vocabularies
We conducted a top-down analysis relate the interests of multiple
1. Analyse the interviews and the vision documents stakeholders × Some requirements types are
2. Use Tropos to model stakeholders’ needs not supported
3. Cluster goals according to macro-categories (TasLab services are Loose coupling between e.g. Needs vs. constraints
grouped in these categories) language and methodology
4. Introduce TasLab actor as system-to-be and assign it leaf goals from × Actor-based modularity is not
allowed mapping stakeholders’
other actors enough
goals to organizational design Category-based modularity
5. Link goals to services via means-end relation
6. Check alignment (do services support stakeholders’ needs?)
7. Provide recommendations to organizational designers
References
Spiral approach to iteratively refine the analysis Bresciani, P., Perini, A., Giorgini, P., Giunchiglia, F., Mylopoulos, J.: Tropos:
• Due to the evolution of needs and organizational design An agent-oriented software development methodology. Autonomous Agents
and Multi-Agent Systems (3) (2004) pp. 203–236
1Project "Knowledge and know-how transfer among research centers and enterprises, including
also the mobility of researchers and technicians", the operation implemented has been selected
under an operational programme co-financed by the ESF, Operative Programme 2007-2013 of the
Autonomous Province of Trento (act n. 1637 (30.06.2008))
iStar Showcase 2011 61