modelling ideasveryard projects > modelling
|how we can help
|education, training and skills
information and advice on methods and tools
supporting materials - including patterns
|Models provide a basis for assessment, analysis, planning,
design and implementation.
We can model many different things, separately or together.
|Workshop: Modelling for SOA
Models and Monsters - The Exception "Proves" the Rule
Modelling Materialveryard projects > modelling > materials
|systems engineering for
business process change
|Data and Information Modelling
Object and Component Modelling
Process Model (pdf)
Principles of Modellingveryard projects > modelling > principles
|A model is a communication of structure and properties. It usually presents itself as representing something, either in the 'real' world, or in the intentions of people (managers or engineers, planners or designers). Sometimes a model merely represents itself.
|A model always has a scope, purpose and perspective. Sometimes these are stated explicitly. often they are implicit or assumed.
|Any model is an abstraction; that is, it ignores certain state variables of the system being modelled and represents other state variables. The criterion for deciding which state variables to represent is the perspective. Thus if a person wishes to use the model rather than the reality in order to ask questions concerning some property (or for some purpose) P because with respect to that property (or for that purpose) the model is as good as the reality, then P is the perspective of the model. Of course, this may be redefined and renegotiated during the project. Identification and confirmation of stakeholders is one important task.
|Formal models are expressed in a strict modelling language or notation. The vocabulary and grammar of this modelling language may themselves be expressed as a model, which software engineers usually call a metamodel. Such models are used for building support tools, such as diagramming tools and repositories.
|For many purposes, informal models are as good as formal models - indeed, sometimes better.
|All models leave things out. This is precisely what makes them useful - as long as you leave out the right things.
Modelling Purposeveryard projects > modelling > purpose
|We are modelling because we enjoy modelling, and because that's what we're good at.
|'We are modelling because we want to alter cultural attitudes.
When people see our models, their eyes will be opened. Thus the models
will themselves trigger change.'
(In other words, the existence of the model itself changes the situation, by altering attitudes or surfacing anxieties/assumptions.)
|'We are modelling because we want to add to the stock of generalized
and reusable knowledge.'
(This motivation has three possible perspectives: an organizational perspective, an industry perspective or an academic perspective.)
|'We are modelling because we want to take informed action. We intend to use these models to support design decisions, investment and procurement decisions, planning decisions.
Fuirthermore, the modelling process may have some beneficial features.
|Where different stakeholders have different views of a situation, these differences can be represented and discussed.
|Including something in a public model legitimizes it as a topic of discussion - the model itself 'contains' the anxiety of discussing taboo subjects.
|Modelling is a way of exploring what the requirements might be, and whether such generated requirements fall within the scope of the system (as currently defined) or whether the scope has to be changed in order to encompass them.
|The model supports or stimulates organizational learning, and also allows the participants/observers to develop knowledge that may be applicable elsewhere.
Modelling Qualityveryard projects > modelling > quality
|Accurately representing the enterprise, to the satisfaction of all
(This implies it is comprehensible to all interested parties.)
|Completely describing the enterprise, covering all required functionality
|No missing cross-references, no unused objects, etc.
(Some aspects of this can be automatically checked by an appropriate modelling tool.)
|Adequate and meaningful descriptions of all objects
|Only representing each fact/requirement once, without unjustified duplication or overlap between objects
|Consistent with architectures and policies, and with an appropriate level of consistency with other related models
|Capable of absorbing minor future changes to the enterprise without major changes to the model. (This characteristic is also known as resilience or robustness.)
|Ease of agreement by users of the model
|Ease of agreement by users of the design implications of the model
|Minimum 'thrashing' - i.e. going round in circles before agreement can be reached
|Minimum discovery of additional requirements or constraints when model is used. Few surprises during implementation
|Low maintenance costs of system (owing to changes in model)
|Maximum learning for participants and entire organization
|Efficient & effective - i.e. achieving a good result with a reasonable expenditure of time and energy
Our Modelling Servicesveryard projects > modelling > services
|Advanced training for people who want to go beyond the basic notations and techniques.
|Independent assessment of models with an expert eye.
|Supporting the transition to a new style of modelling. Taking on new notations, new modelling tools, new ways of thinking. Converting or bridging old models into new forms, where appropriate.
Copyright © 1999-2001 Veryard Projects Ltd