Universidad Nacional de San Luis Argentina



Descargar 21,02 Kb.
Fecha de conversión02.03.2017
Tamaño21,02 Kb.

Universidad Nacional de San Luis - Argentina

  • Main research activities

Second Talk Agenda

  • Main research activities in the context of project: “Software Engineering: Concepts and Tools” and also related with M.Sc. Program in Software Engineering
  • Project tracks
  • Project activities
  • Project structure
  • Project results
  • Examples of project activities
  • Summary

Project tracks

  • With special emphasis in E-Business and E-Government applications, the Universidad Nacional de San Luis Project includes, as elements to improve Software Process:
      • Formalisms
      • Meta-Environments for Software Production
      • Techniques and Tools for Knowledge-Based Requirements Engineering
      • Safety-Critical Software
      • Trends in Formal Specification of Real-Time Systems
      • Internet Repository Services
      • Measurement Support in Software Engineering Environments
      • Software Productivity Tools
      • Software Projects Management
      • Software Project Budgeting

Project activities motivation

  • Internet applications permeate both almost every aspects of business and important areas of government. E Business and E Government are environments of special interest in our project context. Both business manager and government official job increasingly depend on an Internet critical application. They also increasingly expect it to be available, reliable, safe, secure, and usable, despite our their mobility, unpredictability, and changing needs.
  • The development of such software poses increasing challenges for software engineering teams, who are themselves distributed, perhaps mobile, have varied skills, and often speak varied languages. Software engineering must address these challenges through the development and refinement of new techniques, practices, and tools included in general engineering principles. We point that a software engineering team must think of software not only as an algorithm description or a product, but also as a service, a commodity, or even as a user experience.

Project structure

  • Line 1: Software Engineering: E- Business / E- Government fundamentals (Arístides Dasso):
    • Formalisms
    • Software production meta-environments
    • Requierent engineering knowledge based techniques and tools
    • Software confidence
    • Real time system formal specification
    • Data and objects persistence
  • Line 2: Software Engineering: E- Business / E- Government projects (Germán Montejano)
    • Architectures
    • Software metrics
    • Software productivity tools
    • Software project management
    • Software project estimations

Project current results

  • Six MSc Thesis on Software Engineering presented in the last two years. MSc Thesis authors are now PhD candidates and members of our team.
  • More than fifty paper presented and published internationaly during the last five years
  • Member of our team have been invited as Key Note Speakers at international Software Engineering Conferences
  • An important knowledge transfer process to social and productive environment have been executed.

Example of project activities

  • As examples of our project activities we shall describe, briefly:
    • Formal methods (RAISE) used in very sensitive applications specification phase
    • Petri Nets used in OLAP - OLTP levels interaction modelling (time constrains)

Formal Methods: RAISE

  • RAISE stands for Rigorous Approach to Industrial Software Engineering. RAISE emphasizes the use of formal (mathematical) techniques in the development of software: in requirements analysis and formulation, specification, design and development.
  • RAISE offers the RAISE Specification Language (RSL) and the RAISE method.

Formal Methods: RAISE

  • RAISE was initially developed in the European ESPRIT Project RAISE, from 1985 to 1990, with the aim of providing a unifying improvement over formal methods such as VDM, Z, CSP, CCS, Larch and OBJ. It was later further developed in the ESPRIT Project LaCoS (Large scale Correct Systems using formal methods), from 1990 to 1995.
  • UNU is currently improving RAISE and RSL

Formal Methods: RAISE

  • RSL provides a rich, mathematically based notation in which requirements, specifications and steps of design of software may be formulated and reasoned about. RSL is a wide-spectrum language: it facilitates abstract, axiomatic styles of description as well as concrete, operational styles. It may be used from initial domain and requirements analysis through design to a level at which it may be translated into code.

Formal Methods: RAISE

  • The RAISE method provides a set of techniques and recommendations about RSL use in several life-cycle phases of software development, as well as techniques for verifying properties of specifications, implementations and their relationships, formally, rigorously or informally.

BP - OLTP and OLAP general scheme

  • Finance Management
  • Information System
  • Human Resources
  • Information System
  • Logistic
  • Information System
  • Manufacture
  • Information System
  • Datawarehouse
  • Business (or governmental) Processes (BP)
  • Demand
  • Components
  • EIS (BSC)
  • Cuadro de Mando
  • Integral (BSC)
  • Datawarehouse (ROLAP-RDBMS)
  • (Base de Datos Concentradora)
  • Información en
  • Project (Web)
  • Información en BdeD
  • RDBMS (OLTP)
  • Información en
  • Excel (Web)
  • Información en
  • Auto CAD (Web)
  • InformaciónDigital
  • en Base de Datos Documental (Web)
  • La confiabilidad y el nivel de actualización de la información operativa son esenciales
  • Información para el Control de Gestión

Balanced Scorecard concept

  • Balanced Scorecard is for organizations the same thing that fly instrumental for airplanes

Ratios and Perspectives into BSC

  • If we are using Kaplan and Norton point of view, it is also convenient to use the "Critical Success Factors" approach to define the ratios for the four BSC perspectives (classic point of view). These classic or standard BSC perspectives are:
      • Financial perspective (how do we perceive our shareholders?)
      • Customer perspective (how do we perceive our customers?)
      • Process perspective (in what processes should we excel to succeed?)
      • Learning and innovation perspective (how will we sustain our ability to change and improve?)

A “canonic” BSC

Indicators and Ratios

BSC Indicator displayed

BSC General Architecture

  • Frequently we have noted that the technical excellence of an EIS has an inverse relationship with effectiveness. Systems that are technical masterpieces tend to be inflexible, and thus discourage innovation, experimentation and mental model development.
  • EIS must be included in a general five layers architecture:
      • Business (or Governmental) Process Layer
      • Transactional (OLTP) Systems Layer
      • Datawarehouse Layer
      • EIS specific Software Tool Layer
      • Conceptual contents Layer (in this layer Kaplan & Norton BSC concept is used)

Real world BSC example

BSC Strategic Mapping Scheme

BSC automatic generation from Strategic Mapping (tools developed by our team)

BSC specifications with RAISE

  • A scheme called STAKEHOLDERS is defined as a semantic unit, we mean a first specification module that will be reused in next definitions of Balanced Scorecard elements.
  •  scheme STAKEHOLDERS =
  • type
  • Main_Stakeholder =
  • { | s:Stakeholder  is_Main_Stakeholder(s) | },
    • Client = { | s:Stakeholder  is_Client(s) | },
    • Employee= { | s:Stakeholder  is_Employee(s) | },
    • Shareholder = { | s:Stakeholder is_Shareholder(s) | },
    • -- -- main stakeholdes

BSC specifications with RAISE

  • Stakeholders (second level):
  • Secondary_Stakeholder =
  • { |s:Stakeholder  is_Secondary_Stakeholder(s) |},
  •   Supplier = { | s:Stakeholder  is_Supplier(s) | },
  •   Community = {| s:Stakeholder  is_Community(s) |}
  •   -- -- stakeholdes secundarios

BSC specifications with RAISE

  • RSL type used to define Stakeholder is under specified. Further stakeholders will be define as sub types using functions that point the elements belonging to each stakeholder category.
  • Predicates that check stakeholder categories
  • value
  • is_Client : Stakeholder  Bool,
  • is_Employee : Stakeholder  Bool,
  • is_Shareholder : Stakeholder  Bool,
  • is_Supplier : Stakeholder  Bool,
  • is_Community : Stakeholder  Bool,

BSC specifications with RAISE

  • Who are main stakeholders?
  •  
  • is_Main_Stakeholder : Stakeholder  Bool
  • is_Main_Stakeholder(s) 
  • is_Client(s)  is_Employee(s)  is_Shareholder(s),
  • In a similar way, predicate and conditions to determine who are second level stakeholders.
  •  
  • is_Secondary_Stakeholder : Stakeholder  Bool
  • is_Secondary_Stakeholder(s) 
  • is_Supplier(s)  is_Community(s)

BSC specifications with RAISE

  • There are axioms that, from a semantic point of view, define some actors characteristics
  • As an example, following axiom is used to represent absence of compatibility between rolls played by people into organizations modeled using BSC approach.
  • axiom
  •  s : Stakeholder 
  • is_Shareholder(s) 
  • ~is_Client(s) ~is_Supplier(s),

BSC specifications with RAISE

  • “Hierarchical”structure of strategy:
  • scheme STRATEGIC_STRUCTURE =
  • extend STAKEHOLDERS with
  • class
  • type
  • Mission,
  • Fundamental_Values,
  • Vision,
  • Strategy,
  • Integral_BSC,
  • Strategic_Initiatives,
  • Personal_Objectives,
  • Goal,
  • Time,

BSC specifications with RAISE

  • Indicators have a fundamental importance in the BSC approach. Here we have an indicator definition using RSL.
  • Value = Real,
  • Deviation = { | d : Real  d  -100.0  d  100.0 | },
  • Indicator = { | (g, v, t, ld, rd) :
  • (Goal x Value x Time x Deviation x Deviation) 
  • is_Indicator(g, v, t, ld, rd) | },

BSC specifications with RAISE

  • Indicators have a fundamental importance in the BSC approach. Here we have an indicator definition using RSL (continuation).
  • Actual_Indicator = Indicator,
  • Management_Indicator = Indicator,
  • Final_Indicator = Indicator,
  • Result_Indicator = Indicator,

BSC specifications with RAISE

  • Performance and result indicators predicates
  • Is_Actual_Indicator :
  • Goal x Value x Time x Deviation x Deviation  Bool,
  • Is_Management_Indicator :
  • Goal x Value x Time x Deviation x Deviation  Bool,
  • Is_Final_Indicator :
  • Goal x Value x Time x Deviation x Deviation  Bool,
  • Is_Result_Indicator :
  • Goal x Value x Time x Deviation x Deviation  Bool,
  • is_Indicator :
  • Goal x Value x Time x Deviation x Deviation  Bool,
  • is_Indicator(g, v, t, ld, rd) 
  • is_Management_Indicator(g, v, t, ld, rd) 
  • is_Result_Indicator(g, v, t, ld, rd) 
  • is_Actual_Indicator(g, v, t, ld, rd) 
  • is_Final_Indicator(g, v, t, ld, rd),

Modeling with Petri Nets

  • p1
  • p2
  • t2
  • t1
  • p3
  • p4
  • p5
  • p1
  • p2
  • t2
  • t1
  • p3
  • p4
  • p5
  • t1
  • p1
  • p2
  • t2
  • p3
  • p4
  • p5
  • m0 = (1 1 0 1 0)
  • m1 = (0 0 1 1 0)
  • m2 = (0 0 0 0 1)

Businees Process Workflow

  • Order register
  • Add to order
  • Check order line
  • Stop order
  • Credit check
  • Ship
  • * for each order line
  • OK
  • not
  • OK
  • Credit manager
  • Order manager
  • Task
  • Resource
  • Selection
  • (OR split)
  • Parallelism
  • (AND split)

Business Process as Petri Nets

  • Demand
  • Demand segments

A Producer - Consumer System (PN)

Alternative P-C System representation

Taking into account ...

  • Finance Management
  • Information System
  • Human Resources
  • Information System
  • Logistic
  • Information System
  • Manufacture
  • Information System
  • Business (or governmental) Processes
  • Demand
  • Components

We could combine Petri Nets ...

Business Process and OLTP Data Bases

  • OLTP Data Bases modeled as Petri Net Producer Consumer Systems

Now we are considering ...

  • Finance Management
  • Information System
  • Human Resources
  • Information System
  • Logistic
  • Information System
  • Manufacture
  • Information System
  • Datawarehouse

OLTP - OLAP levels interaction

  • OLTP Data Bases modeled as Petri Net Producer Consumer Systems
  • Datawarehouse Datamarts also modeled as Petri Net Producer Consumer Systems

Datawarehouse and Balanced Scorecard

  • Datawarehouse Datamarts modeled as Petri Net Producer Consumer Systems
  • Balanced Scorecard Indicators modeled as Petri Net Producer Consumer Systems

BSC Strategic Map brief example

  • Mistakes
  • (re process)
  • Customers
  • Satisfaction
  • Employees
  • suggestions
  • Employees
  • Suggestions
  • Training
  • Learning and
  • Development
  • Process
  • Customers
  • (-)
  • (+)
  • (+)
  • (+)
  • Receivable
  • accounts
  • Return on
  • Investment
  • Costs
  • Finance
  • (-)
  • (-)
  • (+)
  • (+)
  • The importance of time constrains!

Relationships between Indicators

  • Process Perspective Indicator
  • Customer Perspective Indicator
  • Financial Perspective Indicator
  • There are
  • hard time
  • restrictions!
  • Time consistency
  • is a challenge!
  • Indicator are f(t)
  • Relations between
  • indicator are also f(t)
  • Finance Management
  • Information System
  • Human Resources
  • Information System
  • Logistic
  • Information System
  • Manufacture
  • Information System
  • Datawarehouse
  • Business (or governmental) Processes
  • Demand
  • Components
  • EIS (BSC)
  • A prototype of OLTP / OLAP
  • interaction modelling

An alternative prototype

Summary

  • Our main research activities include e business and e government workflow software support and the interaction between OLTP and OLAP levels
  • Project tracks: Fundamentals and project management
  • Project structure
  • Expected project results in the near future: Project team capabilities development. Interaction with European Universities will help us to improve our team Human Resources.


La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal