universidad nacional de san luis maestría en ingeniería de software proyecto: “ingeniería de...

Universidad Nacional de San LuisUniversidad Nacional de San LuisMaestría en Ingeniería de SoftwareMaestría en Ingeniería de SoftwareProyecto: “Ingeniería de Software: Conceptos y Herramientas”Proyecto: “Ingeniería de Software: Conceptos y Herramientas”

Dr. Roberto UzalDr. Roberto Uzal

Universidad Nacional de San Luis - Argentina

Main research activities

2Universidad Nacional de San LuisUniversidad Nacional de San LuisMaestría en Ingeniería de SoftwareMaestría en Ingeniería de SoftwareProyecto: “Ingeniería de Software: Conceptos y Herramientas”Proyecto: “Ingeniería de Software: Conceptos y Herramientas”


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.




• 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




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




• 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 ManagementInformation System

Human ResourcesInformation System

LogisticInformation System

ManufactureInformation System

Datawarehouse

Business (or governmental) Processes (BP)

DemandComponents

EIS (BSC)



Cuadro de Mando Integral (BSC)

Datawarehouse (ROLAP-RDBMS)(Base de Datos Concentradora)

Información enProject (Web)

Información en BdeDRDBMS (OLTP)

Información enExcel (Web)

Información enAuto CAD (Web)

InformaciónDigitalen Base de Datos

Documental (Web)

La confiabilidad y el nivel de actualización de la información operativa son esenciales

Información O

perativaInform

ación para el Control de G

estió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

-2000

-1500

-1000

-500

0

500

1000

1500

2000

2500

Discount rate (%)

NP

V (

,000s)



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




• 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




• 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 categoriesvalue 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)




• 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),




• “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,




• 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) | },




• 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

p1p1

p2p2

t2t2

t1t1

p3p3

p4p4

p5p5p1p1

p2p2

t2t2

t1t1

p3p3

p4p4

p5p5

t1t1p1p1

p2p2

t2t2p3p3

p4p4

p5p5

m0 = (1 1 0 1 0)m0 = (1 1 0 1 0)

m1 = (0 0 1 1 0)m1 = (0 0 1 1 0)

m2 = (0 0 0 0 1)m2 = (0 0 0 0 1)



Businees Process Workflow

Order register

Add to order

Check order lineStop orderCredit check

Ship

* for each order line

OK

notOK

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





Business (or governmental) Processes

DemandComponents



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





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)

CustomersSatisfaction

Employeessuggestions

Employees Suggestions

Training

Learning andDevelopment

Process

Customers

(-)

(+)(+)

(+)

Receivableaccounts

Return onInvestment

Costs

Finance

(-) (-)

(+)(+)

The importance of time constrains!



Relationships between Indicators

Innovation Perspective Indicator

Process Perspective Indicator

Customer Perspective Indicator

Financial Perspective IndicatorThere arehard time

restrictions!

Time consistencyis a challenge!

Indicator are f(t)

Relations betweenindicator are also f(t)







Datawarehouse

Business (or governmental) Processes

DemandComponents

EIS (BSC)

A prototype of OLTP / OLAPinteraction 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.

universidad nacional de san luis maestría en ingeniería de software proyecto: “ingeniería de...

Documents