lecture #8 (f8) 16 march 2006 - universitetet i oslo...1 based on material developed in athena...

1

Based on material developed in ATHENA (IST-507849), INTEROP (IST-508011) and MODELWARE (IST-511731)

Lecture #8 (F8)16 March 2006

COMET and Enterprise/BusinessModeling

Arne-Jørgen Berre, SINTEF ICT [email protected]

Based on material developed in ATHENA (IST-507849 ), INTEROP (IST-508011) and MODELWARE (IST-511731) 2

Structure

• COMET methodology• COMET support in RSM 6.0• Enterprise architecture• Enterprise modeling• POP* metamodels• Zachman Framework• Enterprise Unified Process• COMET Business modeling

2


COMET methodologyCOMponent-based development METhodology

SINTEF/UiO, 2002-2006

.. evolving into MODIA, including support for interoperable SOA-based systems


COMET

• Full methodology• Service- and component-oriented for

distributed information systems• UML-based• Model-driven• Architecture-centric (reference architecture)• Handbook• Medium-sized methodology

3


COMET• Model-based

– models expressed in the Unified Modelling Language (UML 1.x, 2.0)

• Architecture– the fundamental organisation of a system (...) [IEEE 1471]

• description Framework– principles and guidelines

• for technical InfoStructures– technical information systems and information infrastructure

=> A framework for how to describe the architecture of a technical InfoStructure in terms of UML models, more specifically– a Business Model;– a Requirements Model;– a Component Model; and– a Platform Model

Architectural Description of theArchitecture of the technical IS.


PlatformModel

Component implementationmodel

Bus

ines

s D

omai

nSy

stem

Dom

ain

Model world Real world

Concepts& Artifacts

Processes

Actors

Business (Context)Model Goal Model

ComponentModel

Visionfor change

Context statement

Risk analysis

Business Process & RoleModel -> WARM

Business Resource Model

Deployment

User ServiceTierUser ResourceService Tier LS

Legacy

BusinessServiceTier

ResourceServiceTier

Presentation Tier

UserDialog Tier Com

ponent Infrastructure &W

orkflow Engine (M

icroworkflow )

UserServiceD

omain

Business Service

Dom

ain

UserInterfaceTier

RARA

LA

Workflow Service Domain

Component structure

Interface and interaction specification

Busines domain to system domainmapping

•Work element analysis•Use case refinement and BCE

Work Element Analysis Model

Use case model

RequirementsModel

Use case Scenario Model

PrototypeSystem Boundary

*BCE Model

COMET

4


COMET background

RUP

CatalysisOOram

COMBINE

OBOE Daim

Magma

Commercial projects• Telenor• EDB Telesciences• WesternGeco• ...

Select Perspective

OpenProcess

Methodologyframeworks

Experience

COMETKOBRA

ACE-GIS

ATHENA


COMET software development

Problem domain

Model

Solution domain ?

Process

Model the problem domain – and then map to solution domain!

Teamwork-based• Communication & feedback-based learningVisibility• SW is “invisible”, want to make it visible• Models, prototype & iteration

Creativity ?

Control ?

Notation• Common syntax• Reduce impedance mismatch between problem domain & solution domainService- and component-oriented• Interface specification

5


COMET roles & responsibilities

Problem to be solved

User

Manager

Developer

1. Understand & model2. Map the problem domain

model to the solutiondomain

1. Influence systemfunctionality

2. Test quality

1. Manage risk- Right product- Right technique- Right cost & time

2. Efficient use of people


COMET process

• Iterative– split the development into many iterations.

Each iteration produces a usable system, which is experimented with and reworked and improved in the next iteration

– Keep on until an acceptable system emerges • Incremental

– Incremental process models split the system into components and then implement and integrate component by component

6


ResourceServiceTier

BusinessServiceTier

UserServiceTier

UserInterfaceTier

LS

RARA

LA

Concepts & Artifacts

Processes

Actors Bus

ines

sdo

mai

n

“Real world”Model world

Web Servicesmodel

Web Servicesimplementationmodel

Web Services profilemodel

Businessmodel

Domain model

Riskanalysis

Product vision& product desc.

Requirementsmodel

boundarySystemboundarymodel

Use caseScenario model

OtherrequirementsPrototype

BCE model

Service-Oriented Architecturemodel

Componentstructure model

Serviceinteractionmodel

Serviceinterfacemodel.

Tech

nica

l dom

ain

COMET model architecture


Phases - organisation along time

Iterations:

Requirements Model

Architecture Model

Platform specific Model

Elaboration Specification&ConstructionInception Transition

iter .#1

iter#2

iter#n

iter#n+1

iter#n+2

preliminaryiteration(s)

iter#m

iter#m+1

Business Model

Models

Supporting activitiesProject managementWork productmanagement

Review milestones:

Ince

ptio

n R

evie

w

Prod

uct L

aunc

h

Tech

nica

l Aud

it

Dem

onst

rato

rIte

ratio

n La

unch

Dem

o / D

eliv

ery

Bet

a Te

st L

aunc

h

Acc

ept M

eetin

g

Dem

onst

rato

rIte

ratio

n La

unch

Prot

otyp

eIte

ratio

n La

unch

Test

COMET process architecture

7


Process phase goals and rationale

• Inception– Reduce Business risk!– Question?

• Is there a business potential for this idea?– Describe what and why

• Elaboration– Reduce technical risk!– Question?

• Is there a viable technical solution with a reasonable price and time delivery?– Describe how

• Specification & Construction– Develop the right system!– Question?

• Does the system satisfy the requirements?– Risk driven development - Iterative & Incremental

• Transition– Smoothly deploy a robust system


Baseline methodology

System BoundaryModel

System BoundarySystem BoundaryModelModel

Use case scenarioModel

Use case scenarioUse case scenarioModelModel

MonitoringSeismic Acquisiti on

•Sales &

•Plann ing•Reportin g &

•Monitoring

•Vessel Op eratio n

•Exec. •Op. Mgr

•Vessel Sched ule

•W ork Order

•Prod. stat ist ics

•Do wnt im e stat.

•NCR

• Support

• Engineering

ContextstatementContextContext

statementstatement

BusinessResource

model

BusinessBusinessResourceResource

modelmodel

Businessprocessmodel

BusinessBusinessprocessprocessmodelmodel

: SecretariatApplication

: ClubRegister: Registrator

registerClub

clubExists

registerClub

Iterative&

Incremental

IterativeIterative&&

IncrementalIncremental

Applications

BusinesscomponentsGeneralcomponentsOSHW Component

ImplementationComponentComponent

ImplementationImplementation

Business Model (What and why)

Requirements Model(What)

Platform Model (Implementation)Problem domain

Solution domain

Non-functionalrequirements

Non-functionalNon-functionalrequirementsrequirements

PrototypesPrototypesPrototypesArnorer en kul typeDette er etforsøk påå fylle dennekommentenmed text

Platform profile model

Platform profile Platform profile modelmodel

ObtainClubI nfoand de live r tor egister ingProcessor

Registr ator Secr etar ia t applic ation ClubRe gist er

Chec k if Club exists

Club re gist ration I nf or ma tion

AskClubRegisterto chec kif Club a lr eady ex ists

ExistingClubI nfo

Ask to edit and conf ir m existingClubI nfoExistingClubInf o

Edit and a c cept e xistingclubInfoAsk to r egi ster Cl ub

Add Club

[Club Exist s]

[Club do not Exists]

Workflowanalysis

refinementmodel

WorkflowWorkflowanalysisanalysis

refinementrefinementmodelmodel

Component Model (How)


ComponentComponentstructure modelstructure model

Interface/information model

Interface/information Interface/information model model

Componentinteraction

model

ComponentComponentinteractioninteraction

modelmodel

: SecretariatApplication: ClubRegister: Registrator

registerClub

clubExists

registerClub

ObtainClubI nfoand de live r tore gisteringProc ess or

Re gistrator Secr etar iat applic ationClubRe gist er


Club r egist ration I nf or ma tion

AskClubRegisterto c hec kif Club a lr e ady ex ists

ExistingClubI nfo

Ask to ed it a nd confirm e xistingClubInf oExistingClubI nfo

Edit and a cc ept e xistingclubI nf o Ask to re gister Cl ub Add Club

[Club Exist s]


BuiltUpAreaService

Cluster Circumscribe

BUA

BUATestClient

Basic_WFS

AggregationServiceBuildingService

System BoundaryModel

System BoundarySystem BoundaryModelModel

Use case scenarioModel

Use case scenarioUse case scenarioModelModel


•Sales &


•Monitoring


•Exec. •Op. Mgr

•Vessel Sched ule

•W ork Order



•NCR

• Support

• Engineering


•Sales &


•Monitoring


•Exec. •Op. Mgr

•Vessel Sched ule

•W ork Order



•NCR

• Support

• Engineering

ContextstatementContextContext

statementstatement

BusinessResource

model

BusinessBusinessResourceResource

modelmodel

Businessprocessmodel

BusinessBusinessprocessprocessmodelmodel

: SecretariatApplication

: ClubRegister: Registrator

registerClub

clubExists

registerClub

Iterative&

Incremental

IterativeIterative&&

IncrementalIncremental

Applications

BusinesscomponentsGeneralcomponentsOSHW

Applications

BusinesscomponentsGeneralcomponentsOSHW Component

ImplementationComponentComponent

ImplementationImplementation

Business Model (What and why)

Requirements Model(What)

Platform Model (Implementation)Problem domain

Solution domain

Non-functionalrequirements

Non-functionalNon-functionalrequirementsrequirements

PrototypesPrototypesPrototypesArnorer en kul typeDette er etforsøk påå fylle dennekommentenmed text

Arnorer en kul typeDette er etforsøk påå fylle dennekommentenmed text

Platform profile model

Platform profile Platform profile modelmodel

ObtainClubI nfoand de live r tor egister ingProcessor

Registr ator Secr etar ia t applic ation ClubRe gist er


Club re gist ration I nf or ma tion

AskClubRegisterto chec kif Club a lr eady ex ists

ExistingClubI nfo

Ask to edit and conf ir m existingClubI nfoExistingClubInf o

Edit and a c cept e xistingclubInfoAsk to r egi ster Cl ub

Add Club

[Club Exist s]

[Club do not Exists][Club do not Exists]

Workflowanalysis

refinementmodel

WorkflowWorkflowanalysisanalysis

refinementrefinementmodelmodel

Component Model (How)


ComponentComponentstructure modelstructure model

Interface/information model

Interface/information Interface/information model model

Componentinteraction

model

ComponentComponentinteractioninteraction

modelmodel


registerClub

clubExists

registerClub


registerClub

clubExists

registerClub

ObtainClubI nfoand de live r tore gisteringProc ess or

Re gistrator Secr etar iat applic ationClubRe gist er


Club r egist ration I nf or ma tion

AskClubRegisterto c hec kif Club a lr e ady ex ists

ExistingClubI nfo

Ask to ed it a nd confirm e xistingClubInf oExistingClubI nfo

Edit and a cc ept e xistingclubI nf o Ask to re gister Cl ub Add Club

[Club Exist s]


BuiltUpAreaService


BUA

BUATestClient

Basic_WFS


[Club Exist s]

[Club do not Exists][Club do not Exists]

BuiltUpAreaService


BUA

BUATestClient

Basic_WFS


BuiltUpAreaService


BUA

BUATestClient

Basic_WFS


8


Baseline methodology

• Business Model– Includes the informal context statement, and the more formal business process

and business information models.• Requirements Model

– Use case diagrams are associated with both the system boundary model and the use case scenario model. UML sequence diagrams or activity graphs are used for detailing the use case scenarios.

• Component Model– The component structure model uses the package concept of UML and UML class

diagram. The Component Interaction Model defines the component interaction using UML sequence diagram and/or UML collaboration diagram. The interface model specifies the interface signatures, pre and post conditions for the operations and the information model represented by the interface, i.e. the system information model.

• Platform Model– Represents the mapping of the component model towards the implementation

platform. It identifies and defines properties that are pertinent for a specific platform (e.g. a particular middleware technology and programming language).


Inception Phase:Goal Reduce business risks!Question Is there a business potential for this idea?• Vision statement (Text document)• Risk analysis (Text document)• Domain model (Rich picture (free format), Domain processes (UML activity diagram), Domain Objects (Class diagram)• High level use-case model ( Actors first and then use-cases per actor (Use-Case diagram))

Elaboration phase:Goal Reduce technical risk!Question Is there a viable technical solution within

reasonable price and time frame?• Use case scneario analysis. Fill in Use-Case template for a few important use- cases.• Analysis model ( BCE stereotype class diagram)• Sub-system architecture (packages diagram)• Prototyping

Specification&Construction phase: Goal Develop the right system within the right time and cost!Question Does the system satisfy the requirements?• Complete Use case scenario analysis • Derive architecture

• Component structure (class diagram)• Service interfaces (class diagram)• Service interaction (sequense diagram)

• Implement

Transition phase: Goal Ensure user satisfaction!Question Is the system ready for commercialisation?• Beta test• Deployment (deployment diagram)

Use-Case template• Use-case name and id• Priority• Goal• Pre condition• Scenario description• Post condition• Facade interface• Quality requirements

Risk (external)• Market and market trends • Competition• Technology dependencies• Legacy system interaction• Time frame• Number of users• Availability• Number of transactions• Expected duration of some functionality

Risk (internal)• User acceptance• Fast enough to market• Team not experienced

Test all the way through!(functional, QoS, robustness)

CO

MET

coo

kboo

k

9


COMET support in RSM 6.0


Annexes, Templates & Profiles• COMET Annexes

– UML 2.0 revisions to the COMET Business Model• COMET_Method_v2-5_Annex1_BM.pdf

– UML 2.0 revisions to the COMET Requirements Model• COMET_Method_v2-5_Annex2_RM.pdf

– UML 2.0 revisions to the COMET (Service) Architecture Model• COMET_Method_v2-5_Annex3_SAM.pdf

• UML profiles for RSM– UML Profile for Business Modelling

• COMET Business Profile.epx– UML Profile for Requirements Modelling

• COMET Requirements Profile.epx– UML Profile for (Service) Architecture Modelling

• COMET Service Architecture Profile.epx• Model templates for RSM

– Template for Business Model• COMET Business Template.emx

– Template for Requirements Model• COMET Requirements Template.emx

– Template for (Service) Architecture Model• COMET Service Architecture Template.emx

10


Business UML profile andmodel template


Requirements UML profile andmodel template

11


Service architecture UML profileand model template


Enterprise Architectures –

Concepts, Principles and Approaches

12


Enterprise Modeling

1. What is Enterprise Modelling?2. Enterprise Modelling in the Context of Collaborative Enterprises3. Enterprise Modelling Application Domains

3.1 Enterprise engineering and reengineering3.2 Product life cycle management3.3 Choice and implementation of IT systems and solution3.4 General enterprise architecture and operations support

4. Some definitions5. Introduction to POP*

5.0 POP* Dimensions5.1 General Concepts5.2 Process dimension5.3 Organisation dimension5.4 Product dimension5.5 Decision dimension5.6 Infrastructure dimension


Enterprise Modeling (2)

6. Enterprise Model Example (IEM / MO²GO)6.1 IEM Modelling elements6.2 Process Hierarchies6.3 IEM Illustration of a Process 6.4 Supplier Process Model6.5 Supplier Process Model - Development Function6.6 OEM Process Model

13


Why Enterprise Architecture?

??

??

How can Iinvolve my peoplein improving theperformance of thebusiness

How can I use best

practices to ensure the success of the business?

How can I ensure that the IS

technologyhelps the work of

my people?

??


Business Architecture Metamodels

Process

Business Strategy

Components

Information

Business ContextOrganization

Operational

…linked with relevant technical metamodels e.g. UML, CWM

14


What is Enterprise Architecture

• Enterprise Architecture (EA) is a generic, abstracted and aggregated representation of the core structures and competences of an enterprise.

• EA supports laying out the main characteristics of the enterprise to be analysed and agreed before detailed technical design is started.

• It is shared and discussed enterprise-wide between all stakeholders as a common description forms, functions and features, components, properties and relationships.


What is Enterprise Modelling?

Enterprise Modelling (EM) is a capability for externalising, making and sharing enterprise knowledge.

Enterprise Modelling happens when knowledge workers apply their knowledge and software tools in a creative and purposeful process.

EM tools can either be: - used stand-alone to produce various kinds

of model views, - integrated as front-ends to other systems, - part of an environment providing a

contextual user-environment.

15


Enterprise Modelling in the Context of Collaborative Enterprises

A Collaborative Enterprise is an enterprise where teams work together across boundaries (e.g. life-cycle phases), sharing results and knowledge to improve common understanding and enable better performance and quality results.

“Collaborative Enterprises will be supported seamlessly by EM during all life-cycles“.

OEM

VTargetSetting

Sourcing

Partial Process Model(OEM View)

ARIS Model

Partial Process Model (Supplier View)

IEM Model

Changes (external/ internal)

Concrete Product

idea

Customer Order

accepted

Change accepted

Design order accepted

Product Life Cycle

pre-developmentTechnology

Market trends

InnovationAcquisition

and offer generation

Different aspects of the same process from different perspectives


Enterprise Modelling Application Domains

16


Enterprise Engineering and Reengineering

Enterprise Engineering and Reengineeringactivities include the design of the business processes, their continuous improvement and also the control and operation of common functioning procedures and services.

EM provides a common language that is understandable by all participants.

If the models are formalised enough, Enterprise Engineering and Reengineering activities can be mapped directly onto the business process execution.

Extensive change management is also dependent on creating an integrated modelling and execution platform, and on being able to analyse impacts of the proposed change.

Enterprise engineeringand reengineering

Enterprise engineeringand reengineering


Product Life Cycle Management

The objective of the Product Life Cycle Management is to take care that a product reaches the mature stage as fast as possible and stays there as long as possible.

EM can be a common language for the participants that work along the product life cycle (in one or several of the stages).

EM allows the specification and sharing of new approaches for product development and delivery.

EM improves the flexibility in the relationships with the customers in the product production and delivery stages.

17


Choice and Implementation of IT Systems and Solution

EM supports the different activities related to the Choice and Implementation of IT Systems and Solutions .

EM defines the functionality of enterprise systems and solutions with respect to enterprise operations when interoperating with others.

The links and traceability between the enterprise model and the IT-systems architecture are clearly modelled. It facilitates a consistent evolution of IT systems when the enterprise makes a business decision that impacts on the enterprise model.

Choice and implementation ofIT systems and solution

Choice and implementation ofIT systems and solution


General Enterprise Architecture and Operations Support

General Enterprise Architecture and Operations Support includes disciplines such as strategy definition and decision making, knowledge management, quality management, etc.

EM can support this application domain by delivering suitable models for the different disciplines.

The holistic approach to EM provides different views on the same model, allowing the enterprise to specify each discipline independently while automatically reflecting the impact of decisions in the other views.

Wertschöpfende

anwenden

verteilen speichern

Wissensziele Identifizieren

Geschäftsprozesse

erzeugen

General Enterprise architectureand operations support

General Enterprise architectureand operations support

18


Some definitions

DimensionViewDiagramHolistic aspectModelMetamodelArchitectureInfrastructureWorkplace

(Click the term to see its definition)


Some definitions

DimensionA dimension is a factor used to characterize a term. In this context it refers to "modelling dimensions", which characterize one aspect of a model element. A dimension has a name, and is implemented in the overall model as a sub-model. There is no overlap between two dimensions.

ViewA view is a representation of an excerpt of a larger information base. In this context, View refers to "model views" where the information base is an enterprise model and the representation most often is visual.A view is created according to rules and conventions defined in a viewpoint. A viewpoint is defined as “a specification of the conventions for constructing and using a view” (IEEE 1471).

DiagramA diagram is an artefact to graphically/visually represent part of a view or of a model. It may require several diagrams to completely represent a view. A diagram is a kind of view where model elements are represented by visual elements, whose positioning is user controlled, though consistent with the model syntax.

ModelA model is a representation of some parts of the world, from the perspective of some actor. It is also specified as an instance of a metamodel.

MetamodelLiterally a model for (applied to) a model. In our case it is a model which defines the language for constructing other models. Metamodels are called “reflective” if they are capable of defining themselves.

19


Some definitions

Holistic aspectA systems perspective where primary importance is assigned to the system as a whole rather than to its structure or parts. Holism holds that anything depends on everything else. It is thus the opposite of reductionist approaches to engineering, which holds that a system may be decomposed, and all interdependencies may be captured by predefined interfaces between components. Consequently, holism sees all systems as open, with an incompletely known boundary. Holism is also opposite to positivist scientific approaches, in that causal relations are not regarded as linear and unidirectional, but non-linear and mutual (anything may influence everything else in any number of ways - which we can never know completely - and everything else may also influence the object we are focusing on). This leads to interpretive research methods.

ArchitectureThe fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution (IEEE 1471).

InfrastructureInfrastructure is a set of hardware and software elements that provide common services useful for all processes and operations of the enterprise.

WorkplaceWorkplace is an environment where information is processed and decisions are made in interactions with other related workplaces to achieve business objectives and missions.


Introduction to POP*

Collaboration between enterprises often involves sharing or exchanging each others models.

By creating mappings from individual Enterprise Modelling Languages to a common format, enterprises will be able to exchange models. The POP* Methodology aims to provide a mechanism that allows the exchange of different enterprise models without loss of information .

Presently, five dimensions are included in POP*, namely the Process, Organisation, Product, Decision and Infrastructure dimensions, in addition to a set of general concepts applicable by all dimensions.

20


POP* Dimensions

The Process Dimension includes constructs related to activities, tasks and processes going on in the enterprise or between enterprises.

The Organisation Dimension focuses on organisational structures, as well as members and positions thereof. Also, focus is set on interaction between structures, both as a whole and between members.

The Product Dimension is used to model product architectures or product structures, for the purpose of design, development and engineering or product data management.

The Decision Dimension is concerned with the collection of concepts and constructs that allow describing the decision-making structure in terms of decision centres and decision activities.

The purpose of the Infrastructure Dimensionis to support modelling of infrastructures and the services they provide.


Metamodel: General Concepts

The General Concepts package includes concepts and relationships that are applicable for use in any dimension.

An Enterprise Object may represent anything or anybody that performs work, makes something happen or is just part of some activity in the enterprise.

An Enterprise Object takes part in the enterprise through playing roles

Enterprise Objects may have certain capabilities, and may have a location.

21


Metamodel: Process Dimension

The Process Dimension includes constructs related to activities, tasks and processes going on in the enterprise or between enterprises.

Decision Point is a generic concept representing anything which – when interconnected by Flows – defines the overall process sequence.

Process is used to represent processes, tasks and activities of any kind.

Gateways are Decision Points owned by a Process.

Process Roles, in addition to being Decision Points may have Enterprise Objects attached to them via the “plays role” relationship.

A Flow is a relationship between two Decision Points; Process Roles (input, output, control, or resource) or Gateways in a process.


Metamodel: Organisation Dimension

The Organisation Dimension focuses on organisational structures, as well as members and positions thereof. Also, focus is set on interaction between structures, both as a whole and between members.

Organisation Unit is a specialisation of Enterprise Object used to represent organisations and parts of organisations of any kind. Organisation Role is a subtype of Role which is defined in the context of an organisation. Examples are: President, General manager, Department manager, Front desk clerk, etc.

A Person designates an individual human being.

22


Metamodel: Product Dimension

The Product dimension is used to model product architectures or product structures, for the purpose of design, development and engineering, or product data management.

A Product Concept is a specialisation of Enterprise Object, and represents an idea or a notion of a product, including the characteristics and features of the product.

Product Element is a specialisation of Enterprise Object, and designates objects used to build typical product structures.

Product Function represents part of an answer to a question about why a product evolved or was designed to achieve some goal.


Metamodel: Decision Dimension

The Decision Dimension is concerned with the collection of concepts and constructs that allow describing the decision-making structure in terms of decision centres and decision activities.

Decision Activity is a specialisation of Process and aims at making a choice, more specifically choosing between different courses of action.

Decision Centres are ‘places’ where decisions are taken according to objectives and under constraints.

Decision Structure is defined in terms of decision centres and decision links as well as information links between decision centres.

23


Technology Component

Logical Architecture

0..*

0..*

is part of

0..*

0..*

Logical Architecture Element

0..*

0..*

0..*

0..*

consists of

0..*

0..*

0..*

0..*

is part of

0..*

0..*

0..*

0..*

connected to

Application

0..*

0..*

uses

0..*

0..*

IT Infrastructure 0..*0..*has architecture

IT Service

0..*

0..*

provides

IT Component

0..*

0..*

corresponds to

0..*

0..*

0..*

0..*

is part of

0..*

0..*

0..*

0..*

encapsulates

IT Component Function

0..*

0..*

0..*

0..*

performs

0..*

0..*

is part of

0..*

0..*

0..*

0..*

0..*

0..*

0..*0..*

Metamodel: Infrastructure Dimension

The purpose of the Infrastructure Dimensionis to support modelling of infrastructures and the services they provide.

IT Infrastructure represents the set of interconnected components that provide the services required to support IT activities.

Logical Architecture represents a structure of logical components combined to serve a specific purpose.

An IT Service is the non-material equivalent of a good.


Enterprise Model Example (IEM / MO²GO)

Process modelOrder

(State n)Order

(State n+1)

Product(State n)

Product(State n+1)

Resource(State n)

Resource(State n+1)

Action

Action

Action

Businessprocess

InheritanceInheritance

Process Chain

Process Chain

Products Orders Resources

Information model

Object Class

Structure

Object Class

Structure

(green)(blue)(red)

24


IEM Modelling elements

Basic Elements

Action

OrderProduct Resource

Description of object states

Process description

X = 1

X = 0

X = 0

X = 1

Connection between actions and objects or betweenactions.

Split: both processes run In parallel.

Decision: the process sequencedepends on the object states following the decision element

Join: different sequences are joining to one sequence

Loop: several iterationsof process steps

Connection Elements

Basic Structure of the Process model

control

supporttransformation

“Generic Activity Model“


Process Hierarchies

Level 2 Check the incoming order

Level 1Zielverein-barungs-verfahren

StrategischePlanung

Customer order processing

Check the storage level of the ordered product

Abs

trac

tion

Det

ailin

g

SteuerungRepression

Informations- sammlung u.Problemanalyse

Zielverein-barungs-verfahren

StrategischePlanung

Controlling

Prävention betreiben

Level 0Business process model

25


IEM Illustration of a Process

produceproduct

Productproduced

Productdesigned

Productionorder

Leaderassembly

Procedureinstructions

Production Planning System

Organisation unit

Documentation

IT-System

change

support

control


Supplier Process Model

26


Supplier Process Model –Development Action

PortsControl Output ResourceInput


OEM Process Model

27


Representations of Architecture

ARIS ZACHMAN GERAM

EN/ISO 19439

NIST

EKA -POPSEKA -POPSEKA -POPS

Athena OEA


Based on work by John A. Zachman

VA Enterprise Architecture

DATAWhat

FUNCTI ONHow

NETW ORKWhere

PEOPLEWho

TIMEWhen

MOTIVATIONWhy

DATAWhat

FUNCTI ONHow

NETW ORKWhere

PEOPLEWho

TIMEWhen

MOTIVATIONWhy

S COPE(CONTEXTUAL)

Planner

ENTERPRIS EMODEL(CONCEPTU AL)

Owner

S YSTEM MODEL(LOGICAL)

Designer

TECHNOLOGYMODEL(PHYSICAL)

Builder

DETAILEDREPRES ENTATIONS(OUT-OF-CONTE XT)

Sub-Contractor

FUNCTIONINGENTERPRIS E

SCOPE(CONTEXTUAL)

Planner

ENTERPRIS EMODEL

(CONCEPTU AL)

Owner

SYSTEM MODEL(LOGICAL)

Designer

TECHNOLOGYMODEL

(PHYSICAL)

Builder


Sub-Contractor

FUNCTIONINGENTERPRISE

Things Important to the Business

Entity = Class of Business Thing

Processes Performed

Function = C lass of Business Process

Semantic Model

Ent = Business Entity Rel = Business Relationship

Business Process Model

Proc = Business Process I/O = Business Resources

Business LogisticsSystem

Node = Business Location Link = Business Linkage

Work Flow M odel

People = Organization Unit Work = Work Product

Master Schedule

T ime = Business Event Cycle = Business Cycle

Business Plan

End = Bus iness Objectiv e Means = Business Strategy

ImportantOrganizations

People = Major Organizations

Business locations

Node = Major Business Locations

Ev ents Significantto the Business

T ime = MajorBusiness Event

Business Goalsand Strategy

Ends/Means =Major Business Goals

Logical DataModel

Ent = Data Entity Rel = Data Relationship

Application Architec ture

Proc = Application Function I/O = User Views

Distributed SystemArchitec ture

Node = IS Function Link = Line Characteristics

Hum an InterfaceArchitecture

People = Role Work = Deliv erable

ProcessingStructure

T ime = System Event Cycle = Processing Cycle

Business RuleModel

End = Structural Assertion Means = Action Assertion

Physical DataModel

Ent = Segment/Table Rel = Pointer/Key

SystemDesign

Proc = Computer Function I/O = Data Elements /Sets

TechnologyArchitec ture

Node = Hardware/Softw are Link = Line Specifications

PresentationArchitecture

People = User Work = Screen Format

ControlStruc ture

T ime = Ex ecute Cycle = Component Cycle

RuleDesign

End = Condition Means = Action

DataDefinition

Ent = Field Rel = Address

Program

Proc = Language Statement I/O = Control Block

Netw orkArchitec ture

Node = Addresses Link = Protocols

SecurityArchitecture

People = IdentityWork = Job

T iming Definition

T ime = InterruptCycle = Machine Cycle

RuleDesign

End = Sub-Condition Means = Step

Data

Ent = Rel =

Function

Proc =I/O =

Netw ork

Node = Link =

Organization

People = Work =

Schedule

T ime = Cycle =

Strategy

End = Means =

Based on work by John A. Zachman

VA Enterprise Architecture

DATAWhat

FUNCTI ONHow

NETW ORKWhere

PEOPLEWho

TIMEWhen

MOTIVATIONWhy

DATAWhat

FUNCTI ONHow

NETW ORKWhere

PEOPLEWho

TIMEWhen

MOTIVATIONWhy

S COPE(CONTEXTUAL)

Planner

ENTERPRIS EMODEL(CONCEPTU AL)

Owner

S YSTEM MODEL(LOGICAL)

Designer

TECHNOLOGYMODEL(PHYSICAL)

Builder


Sub-Contractor

FUNCTIONINGENTERPRIS E

SCOPE(CONTEXTUAL)

Planner

ENTERPRIS EMODEL

(CONCEPTU AL)

Owner

SYSTEM MODEL(LOGICAL)

Designer

TECHNOLOGYMODEL

(PHYSICAL)

Builder


Sub-Contractor

FUNCTIONINGENTERPRISE

Things Important to the Business

Entity = Class of Business Thing

Processes Performed

Function = C lass of Business Process

Semantic Model

Ent = Business Entity Rel = Business Relationship

Business Process Model

Proc = Business Process I/O = Business Resources

Business LogisticsSystem

Node = Business Location Link = Business Linkage

Work Flow M odel

People = Organization Unit Work = Work Product

Master Schedule

T ime = Business Event Cycle = Business Cycle

Business Plan

End = Bus iness Objectiv e Means = Business Strategy

ImportantOrganizations

People = Major Organizations

Business locations

Node = Major Business Locations

Ev ents Significantto the Business

T ime = MajorBusiness Event

Business Goalsand Strategy

Ends/Means =Major Business Goals

Logical DataModel

Ent = Data Entity Rel = Data Relationship

Application Architec ture

Proc = Application Function I/O = User Views

Distributed SystemArchitec ture

Node = IS Function Link = Line Characteristics

Hum an InterfaceArchitecture

People = Role Work = Deliv erable

ProcessingStructure

T ime = System Event Cycle = Processing Cycle

Business RuleModel

End = Structural Assertion Means = Action Assertion

Physical DataModel

Ent = Segment/Table Rel = Pointer/Key

SystemDesign

Proc = Computer Function I/O = Data Elements /Sets

TechnologyArchitec ture

Node = Hardware/Softw are Link = Line Specifications

PresentationArchitecture

People = User Work = Screen Format

ControlStruc ture

T ime = Ex ecute Cycle = Component Cycle

RuleDesign

End = Condition Means = Action

DataDefinition

Ent = Field Rel = Address

Program

Proc = Language Statement I/O = Control Block

Netw orkArchitec ture

Node = Addresses Link = Protocols

SecurityArchitecture

People = IdentityWork = Job

T iming Definition

T ime = InterruptCycle = Machine Cycle

RuleDesign

End = Sub-Condition Means = Step

Data

Ent = Rel =

Function

Proc =I/O =

Netw ork

Node = Link =

Organization

People = Work =

Schedule

T ime = Cycle =

Strategy

End = Means =

Zachman Framework – for Enterprise Architecture

28


Zachman Framework

• Row 1 – ScopeExternal Requirements and DriversBusiness Function Modeling

Row 2 – Enterprise ModelBusiness Process Models

Row 3 – System ModelLogical ModelsRequirements Definition

Row 4 – Technology ModelPhysical ModelsSolution Definition and Development

Row 5 – As BuiltAs BuiltDeployment

Row 6 – Functioning EnterpriseFunctioning EnterpriseEvaluation

123456

Contextual

Conceptual

Logical

Physical

As Built

Functioning

Contextual

Conceptual

Logical

Physical

As Built

Functioning

Why

Why

Who

Who

When

When

Where

Where

What

What

How

How


Framework Rules

• Rule 1:Columns have no order

Contextual

Conceptual

Logical

Physical

As Built

Functioning

Contextual

Conceptual

Logical

Physical

As Built

Functioning

Why

Why

Who

Who

When

When

Where

Where

What

What

How

How

Rule 2:Each column has a simple, basic model

Rule 3:Basic model of each column is unique

Rule 4:Each row represents a distinct view

Rule 5:Each cell is unique

Rule 6:Combining the cells in one row forms a complete description from that view

Basic Model = Entities and Relationships

EntityRelationshipEntity

29


Enterprise Unified Process (EUP)

• The Enterprise Unified Process : Extending the Rational Unified Processby Scott W. Ambler, John Nalbone, Michael J. Vizdos

• Book published 2005


EUP Lifecycle

30


Linking the business architecture modeling capabilities of Computas Technology's Metis product line with Troux's IT Governance System, Global 2000 enterprise and government customers now have a complete information foundation for IT Governance, and a single, global provider for enterprise architecture management solutions.

EA and IT Governancesolutions

EMEA/MetisTroux Technologies+ 47 67 83 10 00EMEA SalesNORWAY

United KingdomComputas UK+44 161 703 8312UK Sales

Sweden Computas AB +46 8 740 6050SE Sales

North AmericaTroux Technologies+1 512 536 6270NA Sales

Web: www.trouxmetis.com

Metis/Troux – example of solutions

METIS:A metamodel-basedtool for Enterpriseand System modeling


31



COMET Business Modelling

with WesternGeco Survey BookingReference Example

32


Platform specificmodel

UMT Config model

Component implementationmodel

Bus

ines

s D

omai

nSy

stem

Dom

ain

Model world Real world

Concepts& Artifacts

Processes

Actors

Businessmodel Goal Model

Architecturemodel

Requirementsmodel

Use case Scenario Model

Otherrequirements

Prototype

Visionfor change

Context statement

Risk analysis

Business Process & RoleModelWARM


PIM Data Types

Context Businessmodel Goal Model

Visionfor change

Context statement

Risk analysis

Business Process & RoleModel


0,1

0,1

System Boundary

*

***

Deployment

User ServiceTierUser ResourceService Tier

LS

Legacy

BusinessServiceTier

ResourceServiceTier

Presentation Tier

User Dialog Tier

Com

ponent Infrastructure &W

orkflow Engine (

Microw

orkflow)

User

ServiceD

omain

Business Service

Dom

ain

UserInterfaceTier

RARA

LA

Workflow Service Domain

Component structureand internal design

Interface and interaction specification

Busines domain to system domainmapping

•Subsystem grouping and BCE (Combine Ref Arch)

•BM analysis

Work Element Analysis Model

BCE Model


Business Model

• The Business Model is used to express the part played by the Product (system or component) being developed in the context of the business that will fund its development (or purchase it) and use it.

• The Business Model includes goals, business processes, steps within business processes, roles and resources. The scope (or domain) of the model is any part of the world defined as interesting for a company, organisationor others, and which has some impact on the required behaviour or other characteristic of the Product.

• The business model might be broadly or narrowly scoped, e.g. describing the entire business of a company or describing the immediate environment and context of a Product under consideration.

33


Business Metamodel

Structuring Concepts Basic Business modelling concepts

Work Analysis Refinement ConceptsProfiling model


Structuring concepts

Business Process & Roles Model

Community model

Work analysis Refinement

Context Business Model

1

refines

refined by

in context ofBusiness Model

Context statement

Vision for change

Risk analysis Goal model

Scoping Statement

1

1 1

1

1

1 1 1..*

1

1..*

1

1

1


1

1..*

1

*

0..1

1

refines

context for

1

1refined by

34


Model structure for the Business model


Modelling concepts

Artifact Resource Actor Resource1..* identified by

results in

Goal

Resource in Role

Business Rule

fulfilled by

constrained by

has1..* executes

1..*

1..*

*

objective of

subgoals

Community

Resource*

has resources

constrained by1..*

*

resource in

1..*

0..1

*

*

*fulfils

constrains

modelled as

represents Business Process

Step

Enabling behaviour

1..*behaviour of

generates

modelled as

Enabled by

met by

1..*

1..* 1..*

to meet

Role

constrains

1..*

*

*

*

actor for

constrains

1

1..*

1..*

1..*

*

*

performed by

identifier for

constrained by

Event

Behavioural Policy

0..1

affected by

model of

constrained by1..*

1..*

*

0..1*

*

*

affectsis generated by

constrains

Business Message

Resource as Artefact *

*

1..*

* *

1..*1..*

*

1

*

1..*

concerns

artifact in

result of

recipient

issued to

represented information flow

subject for

artifact

resource sender

received by

35


UML profile for business modelling


Survey Booking Reference Example

• The survey-booking tool will help to administer the utilization of our vessels. It will mainly benefit three user groups; Sales, operations and marine management.

• Sales will use it to book a survey or tender onto a vessel. The survey-booking tool will give an overview over the current workload and also which vessel qualifies for the job.

• Sales will make booking suggestions to management, which then need to be confirmed by the global marine management.

• For operations the booking tool should work as a planning aid. It will automatically warn about changes and it will have detailed job information available on-line.

• Marine management will be able to use the booking tool to assess the current resource usage, confirm survey bookings and to reschedule jobs.

36


High-Level System Boundary

Sales

Marine Management

Support

Operations

Administrator

Introspection

<<description>>The sales department is responsible for costing a survey and to initially book it on a vessel or region in case of a lead. Sales account managers, sales supervisors and sales managers are members of this group.

<<description>>* Marine management will be responsible to confirm the booking of surveys onto a vessel.* Regional marine management, business managers and global marine management are part of this group.

<<description>>A support role is needed to promote the input of competitor information. This role needs to access the system to obtain status on what is being added and by who.

<<description>>* Operations will be responsible for the survey preparation and execution.* Operations managers, vessel supervisors and party chiefs are the main members of this group. * In addition there are several service groups which will also be included in this group:* Operational support (Technical services), personnel management, accounting.

<<description>>A person with administrator rights is needed to keep the system updated with regards to user names and rights and vessel names.

<<description>>* Introspection has two tasks. For the booking and booking validation process it shall inform about vessel configurations, which it can get from the vessel descriptions. * In addition the actual progress is extracted from Introspection to keep the schedule up to date.

SurveyBooking


Subsystem GroupingBookingEditor

1. Book tender/lead

2. Update booking status

7a. View local schedule

15. Import from global schedule

5. Reschedule job

16. Export to global schedule

BookingViewer

7b. View global schedule

SubscriptionEditor

12. Subscribe to notification

1. Book tender/lead

2. Update booking status

7a. View local schedule

15. Import from global schedule

7b. View global schedule

12. Subscribe to notification

16. Export to global schedule

Sales

Marine Management

Operations

GlobalScheduleService

17. Synchronize and save schedule

18. Assemble and deliver schedule

10. Add/remove users & rights

11. Add/remove vessels

SubscriptionService

19. Check for subscriptions & notify

20. Update list of available subscriptions

21. Save/remove subscriptions

17. Synchronize and save schedule

18. Assemble and deliver schedule

10. Add/remove users & rights

11. Add/remove vessels

19. Check for subscriptions & notify

20. Update list of available subscriptions

21. Save/remove subscriptions

<<include>>

5. Reschedule job

<<include>>

<<include>>

<<include>>

ActivityInfo

Administrator

Introspection

<<include>>

SubscriptionInfo

37


Component Structure – Bus Pattern

Component Infrastructure

BookingEditor BookingViewer

BookingService

ActivityInfo

SubscriptionService

SubscriptionEditor

SubscriptionInfo


Scoping statements

• The context statement, which defines the scope and positions this business model in its context.

• Vision for change, which describes what to improve, the motivation (i.e. what is wrong with the current situation), a description or indication of what the improvements might be and a gap analysis.

• Risk analysis, which identifies the business and technical risks related to a development project for the proposed Product.

38


Context statement

• Methods and Techniques– The first step in developing any business model is to identify and

record the names of all people who will have an interest in having the Product developed or in its use, the business stakeholders, together with the nature of their interest.

– The following are examples of business stakeholders who should be involved:

• people who will authorise funding for development of the Product;

• people who are responsible for design and maintenance of the business processes to be supported by the Product;

• people who will use the Product;• people who will be responsible for the acceptance of the

Product;• people who will be responsible for managing operation of the

Product.


Roles – Organisation and Process roles

Sales Support Introspection Operations Maritime Manager

Administrator ClientTechnical Manager

System Operator Reviewer

QC-RepTechnical Support

Operation ManagementData Processing Legal

Marketing Corporate ManagerOil Company

Operation Manager

SecretarySales Manager

39


Scope and stakeholders<<summary>>

* Client contacts* Marketing* Global fleet plan

Operation Management

Technical Support

<<summary>>* Liase with client* Coordinate review review* Compile tender* Monitor vesel availability* Monitor competitor activity

<<summary>>* Review work specifications* Propose technical solutions

<<summary>>* Review operational risks

<<summary>>* Liase with sales* Issues tender* Issue award/loss

Marine acquisition

<<summary>>* Review contract* Assess risk* Insurance

Maritime Manager

Oil CompanyCorporate Manager

LegalData Processing

<<summary>>* Monitor marine activity * OBP proposals

AccountManager

Marketing

<<summary>>* Optimize revenue* Position vessels* Upgrade vessels* Report

<<summary>>* Marketing

<<summary>>Produce a timeliy, quality image service to help clients find, produce and manage oil assets.


:Sales & Marine Management

PreSales

Tender Bid

<<ResourceAsArtefact>>:ITT

[qualified bid]

[won]

:Operations

Survey Preparation

Survey Execution

Survey Close

PreSales

Tender Bid

[qualified bid]

Survey Preparation

[won]

Survey Execution

Survey Close

<<ResourceAsArtefact>>:ITT

<<ResourceAsArtefact>>:SWO

[no bid]

[lost]

Tender Bid ContextDiagram

40


Vision for change

• The vision for change document is short and describes what the Product will be and why it is needed. It will consist of some or all of the following elements:– General business/product vision and goals, including

background explaining why the Product is needed;– Business opportunities and business benefits;– Product description and technical business vision –

how the Product might be deployed and used;– Presentation material summarising the above.


Vision for change (1/2)

• Beginning 2000 it was decided to phase out and replace the suite of business support tools used in the Tender bidding process in theMarine Acquisition Business segment. These tools were based on Excel technology and did not support the needs in a distributed 7by24 organization. Also after 10 years of evolution, pushing spreadsheet functionality beyond its limits, these tools were hard to maintain.

• The decision was to reengineer this tool-suite based on the Introspection business tool platform, which was based on Web andJava technology.

• The first priority was to look at “The Survey Booking Tool” and “The Survey Costing Tool”. The Survey Booking tool will help to administer the utilization of the seismic vessels and will be used to book a survey or tender onto a vessel. It will give an overview over the current workload and also which vessel qualifies for the job. The Survey Costing tool is used to calculate the cost and revenue of a potential survey.

41


Vision for change (2/2)

• The survey-booking tool is a web-based and highly automated tool to support the process around booking of vessel time for potential surveys.

• Its main task will be:– Schedule leads and surveys– Send automatic warnings on changes and

conflicts– Inform about current resource usage and

potential backlog


Goal Model

The goal model describes a loose hierarchy of goals of the business within the particular area of concern, starting with the goals of a Business Stakeholder in developing or buying the Product, and leading to the detailed business goals met by the Product or its users when using it.

• The Goal Model is discovered by a process of workshops and interviews involving all stakeholders (as identified in development of the Context Statement).

• Goals must be achievable, preferably measurable, and not self-evident, and should have clear and detailed implications. It should be reasonable (but not necessarily appropriate, and almost certainly not correct) to assert an alternative. The implications should be expressible in terms of a set of sub-goals or enabling processes.

42


Goal Model

Make a profitable bid

Optimize fleet utilizationSound cost estimates Proper technical assesmentProper legal assesment

Easy access to historical information Updated cost-models Updated own schedule Updated competitor schedule



• The Business Resource Model is an information model that identifies and defines the main things (and concepts) of the domain that are relevant to the Product.

• The Business Resource Model is generally prepared at the same time as the associated Business Process & Roles model, and methods and techniques used are similar, i.e. activities that include brain-storming sessions, structured workshops, interviews and feed-back sessions, and detailed modelling using a UML tool.

• Object flows in the activity diagrams are candidates for business resources.

43


Business Resources

Crew

Tender/Lead

LocalSchedule GlobalSchedule

Company

Vessel

Survey Phase

<<owns>>

Schedule

Booking

summary : undefined

start : undefinedend : undefinedsummary : undefined

start : undefinedend : undefined

<<located in>>

Configuration

SWO

1

1

1

1 1

*

<<shall use>>

Client

corp_code : undefined1

*

1

1

corp_code : undefined

*

CountryJob

1

1

*<<located in>>

*

1

*

Area/region

WesternGeco

1

1

*

*

*

1

*

*

Competitor

Capacity

1*


Business Process &Role Model

• Purpose– The objective of the Business Process Model is to

identify and detail all the business processes supported by the Product to the extent necessary to detail the roles of the Product (and its components, i.e. Application Components, Business Service Components and Tool Components).

• Methods and Techniques– The Business Process Model is derived through a set

of activities that encompass brain-storming sessions, structured workshops, interviews and feed-back sessions, and detailed modelling using a UML tool.

44


Work Element Analysis(WARM)

• In WARM refinement of the Business Process model, the kinds of step performed by resources in the model are further categorised as follows:– A Human Step is a step performed by a human with no

involvement of the Product being modelled.– A Tool Step is a step performed by a human user interacting with

a tool that is part of the Product. The human user will use someform of interactive device (e.g. a GUI) to interact with the Product. A Tool Step is a candidate for realisation by a Tool Component.

– An Immediate Step is a step that is required to complete as soon as possible, and whose intermediate states are of no concern to the business. It is performed autonomously, with no interventionfrom a human. An Immediate Step may be mapped to an Operation on a Business Service Component (Process) in the Architecture Model.


Tender Bid Process Overview

Receive ITT & Prepare for bidding

Make Tender

Submit Tender

[continue]

[continue]

[stop]

[stop]

45


Receive ITT & Prepare for bidding

:Oil Company

Send ITT

:AccountManager

{SurveBookin

{SurveBookin

{Othtool}

Create or update booking

Check ITTITT received

brf:BusinessReviewForm

Check Competitor Schedule

Create business review form

Make Tender

:Secretary

itt:ITT Archive ITT

:Manager

{End of survey booking}

Bid approval

[Cancel bid]

Send ITT


Create or update booking

Check Competitor Schedule

Create business review form

Make Tender

{SurveBookin

itt:ITT Archive ITT ITT received

booking:Booking

{SurveBookin

{Othtool}

Check ITT

Bid approvalbrf:BusinessReviewForm

[Cancel bid]


Make Tender :AccountManager

{SurveCostin {Oth

tool}

{SurveCostin

Survey CostingDistribute ITT for review

cpp:CostPriceProposal

Evaluate feedback

tender:Tender

Compile Tender

recalculate cost

Submit Tender

[No issues]

:Reviewer


Resolve issues

Part_of:ITT

Review ITT

Approve Tender

[decide not to send]

:Manager

Approve cost

feedback:ReviewFeedback

Survey Costing

{SurveCostin {Oth

tool}

[?cost too high]

[decide to send]

{SurveCostin

Distribute ITT for review

cpp:CostPriceProposal

Evaluate feedback

Compile Tender

recalculate cost

[?cost approved]

[Too high cost][No issues]

Approve cost

feedback:ReviewFeedback

Resolve issues

Part_of:ITT

Review ITT

[?Not approved]

[cost issues]

[cost ok]

tender:Tender

Submit Tender


Approve Tender

[decide not to send]

46


Submit Tender

:Oil Company

Review Tender

:AccountManager

Update booking status to tender sent

Update booking status to bid won or lost

:Operations

Survey Preparation

Review Tender

tender:Tender

Update booking status to tender sent

Update booking status to bid won or lost

response:BIDResponse

Survey Preparation


Process and goal structure

Tender Bid

Survey costing Tender compilation

Plan

Win profitable bidsSound cost estimates

ITT

Tender

Sales

Oil Company

<<achieves>> <<achieves>>

47


References

• Enterprise Unified Process: http://www.enterpriseunifiedprocess.info/

• SEI (CMM) etc: http://www.sei.cmu.edu/sei-home.html

• EA: http://www.enterprise-architecture.info/• Software Architecture: www.wwisa.org

lecture #8 (f8) 16 march 2006 - universitetet i oslo...1 based on material developed in athena...

Documents