Project Development Guide.
1. Main tasks of the Projectwork
The main tasks in this Projectwork follows a modelling-project path, with Information gathering, Concept modelling , Model development.
Its based on the well tested methodologies like: DesignThinking, LEAN Startup and Agile Development.
The Projectwork steps are:
1. Concept development (selection)!
Concept selection identifies existing approaches, solutions and methodologies, then ana- lyzes and tests them on the problem at hand, in order to reuse best practices and gain ideas for innovation.
### Concept Development
In concept development the project team explores, discusses, and analyzes existing visual solu- tion concepts, in order to
• Better understand the business challenges faced by the organization,
• Get new ideas about how visual solutions may be applied to solve identified business
challenges,
• Improve solution quality and reduce cost by reusing existing solutions or services.
The solution concepts may come from any of the participants:
• Standard and basic solutions developed by AKM and their partners.
• Applications and methodology support solutions developed by independent solutions de- velopment consultants.
• Applications and solutions already being used by the customer company, e.g. based on spreadsheets and other documents, or simple database applications (e.g. Microsoft Access).
These steps are involved:
1. Capture the key business objectives and challenges that the solution should address.
2. Identify, select and describe the solutions concepts deemed relevant. In addition to con- cepts based on existing solutions, completely new ideas should also be represented.
3. Analyze the concepts, capture arguments pro and contra their usefulness in this case, with reference to the business objectives and challenges.
4. Select one or a combination of concepts. If a template is available for the selected solu- tion concept(s), include its tasks, views, roles, and information content in the knowledge model for you project.
The model below shows an example of a high level analysis of solution concepts. On the top, we find five business objectives, which leads to four challenges (issues) of concern to key roles in the organization. A set of solution concepts (lightbulbs) address these challenges, sometimes caus- ing new challenges that should be addressed. Objectives, arguments and data support or con- flicts with (red arrows) the various solution concepts.
---
2. Scaffolding!
Scaffolding creates an overview model of the domain in question, identifying the roles of users and stakeholders, the tasks they perform, and the information they apply or produce.
### Scaffolding
The aim of scaffolding is to get an overview of the situation, the user and stakeholders of the companies involved, their main work activities, and the core content of their work. The scaffolding model is a top-level IRTV model that provides the conceptual framework for the construction of the main solutions model. Scaffolding is also aimed at creating some coherence among the par- ticipants, a minimum of shared terminology and context understanding. The scaffolding model should be initiated as soon as the project starts, and it should be the main vehicle of analysis and communication during the first meetings in the project team.
In all, a scaffolding model that identifies the main IRTV elements and their interdependencies.
3. Scenario modeling! ()
Scenario modeling provides more rich and detailed representations of important task pat- terns. In addition to role responsibilities and detailed information flows, the model at this stage should also represent the views, with information content and services (tasks) needed for performing the work.
### Scenario Modeling
Scenario modeling creates detailed descriptions of how a visual, model-configured solution will work to solve a given problem.
Whereas the scaffolding models are built top down to get an overview of the situation, scenario models focus on the concrete details of particular situations. We typically abstract and generalize from these particulars in order to build a useful solution based on scenarios. Scenario modeling is a bottom up analysis methodology.
In this phase, you ask more detailed questions about the IRTV dimensions of the problem. We therefore need a richer and more precise modeling language for each of the dimensions and their interdependencies.
Starting from a scaffolding model, the first challenge is to select the right areas and scenarios to study in depth. Suitable scenarios typically have some of there characteristics:
- Great importance to the company, among its core competencies and processes
- Where performance problems have been recognized
- Simple enough to enable early demonstration of value, but complex enough to warrant a solution that utilizes structured visual modeling
- In an environment that changes, where each project has some degree of uniqueness
- Knowledge intensive and highly dependent on personal experience
- Areas where the information has not yet been structured, and documents is the primary means of communication
- Areas where past investments in CAD, ERP, PLM/PDM, KBE etc. have not given the ex- pected benefits.
The most important criteria, however, is the availability and dedication of people who are know- ledge in the field to participate in the scenario modeling process. The availability of a concrete, representative case is also paramount. An ongoing project is an ideal case as long as project time pressure does not come in the way of active participation in the modeling process. A pre- vious project is still far preferable to not having a concrete example at all.
The scaffolding model offers some hints about what kind of scenarios me might focus on:
- The work of a particular role, team, or group of roles
- A certain task, or related group of tasks
- The lifecycle of some information entity, such as a product design, or a view containing related information, e.g. a business case
- Or a combination of the dimensions.
It often makes sense to start the scenario modeling a new model view, bringing in just the elements that are part of the scenario.
4. Solutions modeling!()
Solutions modeling specifies how a solution should function, integrating a number of scena- rios around a purposefully designed knowledge architecture, guided by the core concepts identified in the scaffolding model.
Solution Modeling
Solution modeling brings together the top down overview created in the scaffolding phase, and the bottom-up scenario models, performing a sort of middle-in-out analysis. In this process, par- ticular scenarios are generalized and aligned to form a coherent and integrated solution. As shown in the figure above, the final important task in this phase, is the linking of IRTV model ele- ments to executable platform services for information, role, task and view management.
The execution platform that directly executes IRTV models, is the Active Knowledge Modeling (AKM) platform. The analysis leading up to the final solution configuration, covering the concept, scaffolding, scenario and early solutions modeling activities, can however be applied in more conventional software engineering projects as well. The following phases of the methodology, however, assumes that you will configure a solution in the AKM platform, utilizing the Configura- ble Visual Workplaces (CVW) interface within Metis modeling clients, supported by the Metis En- terprise repository for collaboration and data sharing.
The AKM platform comes with an initial model that specifies the core, most generic elements within each dimension, and their relationships to elements in other dimensions. The standard vis- ual workplace likewise contains generic views and services that activate these generic structures, e.g. generic views for editing the information about a product element. These workplace compo- nents can be extended and customized by providing more detailed specifications in any of the four dimensions:
• If the customer defines more specific types of information objects, relationships, proper- ties etc., the modeling and visualization services automatically adapt to include the new features.
• No view model extension is needed to accommodate new information types, but if the customer wants to override the default specifications and customize how the new ele- ments are to be displayed and manipulated, view models must be updated as well.
© Active Knowledge Modeling A.S. 32 Confidential – do not distribute
• If the customer adds new and more specific roles, new workplaces for the roles are also made available. The services and configurations defined on the generic level apply to the new roles according to the role specialization hierarchy.
• Defining new and specialized tasks is probably the most common form of detailed custo- mization and instance level adaptation, e.g. to meet the specific requirements of a partic- ular project. Some automatic tasks can be defined as a sequence or more complex process of subtasks, while others are defined as rules. The triggering and coordination of tasks can be associated with modeled sequences, or rules that react to the occurrence of different kinds of events, such as “Every second Thursday at 11:00”, or “Every time a new product variant is created”. The AKM platform as well defines a set of generic tasks that have scripted code to be executed when the task is invoked. Other tasks are imple- mented with a view, a window in the workplace with some information content and other services (tasks) available for manipulating the information.
Solutions Modeling Using the IRTV Knowledge Space
The overview below summarizes the four dimensions that we are modeling:
The AKM platform comes with an initial model that specifies the core, most generic elements within each dimension, and their relationships to elements in other dimensions. The standard vis- ual workplace likewise contains generic views and services that activate these generic structures, e.g. generic views for editing the information about a product element. These workplace components can be extended and customized by providing more detailed specifications in any of the four dimensions:
• If the customer defines more specific types of information objects, relationships, proper- ties etc., the modeling and visualization services automatically adapt to include the new features.
• No view model extension is needed to accommodate new information types, but if the customer wants to override the default specifications and customize how the new ele- ments are to be displayed and manipulated, view models must be updated as well.
### Information Modeling
The information management component of the AKM platform defines how information models are stored and manipulated. Because all elements, not just POPS and surrounding spaces, but also the other dimensions of the workspace (roles, tasks, views) can be represented as information elements, the language for information modeling should contain all that is needed for representing any kind of active knowledge model.
This information model is called the Enterprise Knowledge Architecture (EKA). It is depicted below.
All constructs are regarded as Elements. Spaces contain elements, but one element may be found in multiple spaces. Conventionally, most model elements will be Objects. All kinds of ele- ments may have Properties, and Relationships link two elements through Origin and Target Roles1. Relationships, roles and properties are also elements, so they may possess properties and have relationships to other element.
The EKA does not separate between meta-classes, classes and instances because
- One person’s roof is another one’s floor, thus an instance in one view may be a class in another.
- AKM models represent mutually reflective views. The definition of an element is not found in a single class, but through a set of reflective views.
Instead, a special relationship called Is between two objects (or relationships or properties), de- note that the origin is defined by the target, and can thus express both specialization (Student is Person) and instantiation (George is-a Person). The instantiation relationship Is-a has similar meaning as Is, but it is used to separate meta-levels (for the modeling contexts where this is re- quired). Finally, Equals is a bi-directional Is-relationship, which implies that the two elements represent the same concept, phenomenon, or entity. Equals is typically used for representing mappings between models that represent different perspectives on the same domain.
---
1 The concept ’Role’ here refers to a participant in a relationship, in general. Throughout this me- thodology description, the term ‘Role’ usually refers to ‘Actor roles’, roles of individual persons, groups, teams, organizational units etc.
---
Other relationship types include general links and associations, and decomposition with (Part) and without (Member) ownership. Note that this approach enables classification, decomposition and states of properties, relationships and views just like objects.
Aspect Modeling
The above classification of core modeling concepts is no taxonomy. The same element may be represented in different ways in different views, for instance as an object in one view, a relation- ship in another and a property in the third. How the element is presented typically depends on the level of detail needed by the particular role. Many language constructs will also be defined as member or multiple core concept classes. As an example, take the concept “state transition”, which can be a task, a relationship and possibly an event or a rule at the same time. The core concepts can thus be seen as aspects or facets that any element may include as part of their de- finition.
Multiple reflective views are captured as multiple “Is” or “Is-a” relationships from an element. This approach can also be applied to mix in new aspects locally. For instance, if a group wants to add a cost dimension to a process model, they simply add an “Is” relationship from “Object” to “Cost unit” in their model. All objects within the model will then inherit the properties and behavior of cost units.
Reflection and Metamodeling
The EKA is inherently reflective; it makes no separation between meta-levels. Objects, relation- ships and property elements can be applied at any level. Inherent reflection also makes the EKA coherent, in that users apply the same modeling constructs and operations on any meta-level. They may perform “metamodeling” operations such as adding a property in the same way on in- stances and classes, or for that matter relationship and property instances and classes. This faci- litates instance level exceptions and evolution. Similarly, users may perform modeling operations on objects representing classes, e.g. adding default parts and property values.
The Content of the Knowledge Architecture
During solutions modeling, the various information elements captured during top-down scaffolding and bottom-up scenario modeling, and as well any elements that you reuse from an applied, should be brought together into an overall architecture. This architecture should capture the con- tent of your solution in a structured way.
For configurable components, the knowledge architecture contains elements of these types:
Role Modeling
Roles represent the relationships between users and other stakeholders and the other knowledge dimensions. Specific roles are thus defined for information access and use, task responsibility and participation, and view definition and usage, respectively. Roles on information elements in- clude:
- Uses, the most generic role. The use of the specific types below is optional.
- Owner
- Editor
- Reader
Each of these relationships may yield different access rights and different information manipula- tion services made available when the user is brining up the information in a workplace.
Roles in tasks include:
- Participates
- Manages
- Customer
Roles on views include:
- Applies, the most generic role. The use of the specific types below is optional.
- Operator, the role using the view
- Definer, the role setting up the view, deciding how content and services should be made available
- Content manager, the one deciding which content should be shown
- Context manager, the one deciding which navigation links should be available
In IRTV models, these roles are represented as different relationship types between roles or actor types (person, organization etc.) and other elements (information, roles, tasks). This is illustrated in the metamodel below:
We also model task patterns as work breakdown structures using the general member and part relationships introduced for information modeling above. Events represent situations that occur, things that happen. The performance of a task is an event. Events (and therefore also tasks) trig- ger tasks. The triggers relationship is as well used for defining sequences of tasks. Decisions are a special kind of task. Often they will control what to do, e.g. which next task to trigger, or when. A rule is another special kind of task. If specified in a rule model, it can be automatically executed by the rule engine (see below). The rule language can as well be applied for defining a library of typical events that occur, such as “a change of the value of the ‘deadline’ property for elements of type ‘product component’”. Finally, the platform can be extended by scripting, defining automatic script tasks. Scripts can take input and output parameters just like other tasks, referring to them by name. This mechanism has been used for defining a library of reusable general tasks as part of the standard platform configuration. On way of linking to the platform is thus to define your lo- cal tasks as specializations of one or more of the tasks in this library, maybe customizing it slightly by binding some local parameter values, e.g. to a particular type of information being ma- nipulated. More details about this will be presented in the description of platform configuration below.
---
Rule Modeling
A rule is regarded as a kind of task. This is because we are interested in the active nature of the rule, the effect it has upon the knowledge architecture, platform, and workplaces. Rule modeling
deals with the specification of these effects. By representing rules as tasks, we also capture the rules’ effects in the history of the models, and allow users to override rules when they see that they are no longer valid, or perhaps just to explore what opportunities were to arise if we are able to find a way to work around this rule in our design. After all, rules, like all other model elements, have different degrees of certainty and precision throughout their lifecycles. By treating rules as tasks, we also ensure uniform definition and handling of parameters to rules and tasks.
Rules may help you achieve a number of useful effects:
• Capture and enforce constraints that e.g. a product structure must meet such as “maxi- mum voltage is 12V”.
• Select which elements should be related, from a set of possible choices, e.g. to automati- cally configure a product part structure by selecting the right component variants.
• Automatically derive values for parameters, such as “voltage” from the battery element to the other electrical components.
• Automatically calculate values, e.g. sum up the material costs of a complete product part structure.
Defining the Context of a Rule
The first step is to define the context in which a rule will be applied. This can be in a task pattern model, alongside interactive and manual tasks, but more commonly, rules will be associated with information elements such as product, organization, or process structures. Therefore, the rela- tionship that defines the element that a rule applies to, is the works-on relationship defined for task modeling above. The information element in question may be an object, a relationship, a property, or any kind of element.
Though a rule is connected to a given context element, it may refer to and manipulate related elements as well, including the properties of the elements, its relationships and neighbor ele- ments.
Defining the Logic of a Rule
Rules are defined in terms of three types of elements:
• Events and Triggers
• Conditions
• Actions
Events define when a task (such as a rule) is to be triggered. Conditions define situations where different actions should be performed. The meaning of a rule can thus be expressed as
When If Then
Any task can fill the role of an action in a rule. We may thus use this construct to link in sub-rules as well. An action that is part of the rule, but not guarded by a condition, will always be performed when the event is triggered. A rule can contain any number of actions, linked to at set of condi- tions using the if-then relationship type.
---
Any task can be applied as an action in a rule, so action modeling follows task modeling. The modeling of events and conditions, however, warrant closer attention.
Events
Version 2.0 of the CVW platform does not include a full event notification service, and no services have been implemented for interpreting different kinds of events. Instead, rules are triggered ac- cording to the structure (parts and sequences) of the task patterns, or interactively by the users clicking on a button or menu item linked to the rule task.
Example
The model below shows a simple rule, called “Rule step 2”. It has a main condition (“AND”), and an action. The condition has a subrule (priority = 2), while the action task has an input parameter (“Cost”) and an output parameter (“Budget”). The code of the action is
Budget = Cost
A condition object simply links the rules that decide whether the action should be performed. Its operator may be AND, OR or NOT. A condition may as well have subconditions, to create more complex logical expressions.
The action can be any kind of task, a script, or a rule.
More details about rules is found in the section on Scripting and Rule Modeling in the Platform Configuration documentation.
---
View Modeling
View models define every aspect of how the information is shown in the workplaces. The most important aspect is of course which information to show. This is defined as a visual query. A visu- al query must contain the kind of elements you want to see and work on, and it may define addi- tional search criteria, e.g. for property values, in order to filter out irrelevant content.
---
### Task Modeling
The core elements for task modeling, are depicted below. It shows that a task can work on some information element, and that a task may have parameters, information elements that provide input data values, or receive output data. A task may as well be connected to a view that is ap- plied for performing the task. In order to establish what to do in a situation where e.g. an informa- tion element is to be presented to the user in the workplace, any kind of element can have a de- fault task specified.
---
</details>
5. Platform configuration!
Platform configuration maps the conceptual information, role, task and view models to the execution platform, defining how information is stored, access control is enforced, tasks should be executed, views presented in workplaces, etc
Platform configuration adds details to the IRTV models that are specific to the execution platform. This task is typically handled by solution managers, super users and technical consultants, not ordinary end users.
Let us first look at the interplay of the IRTV dimensions during operation of the platform. A view component such as a work area or a navigation menu item most commonly represents a task. A menu item often reflect a “select” task, while a work area might represent a “view” or “update” task. The services available in a view for a task, reflect available subtasks of that task, filtered according to the role of the user. Tasks are filtered according to the same principles as informa- tion. Which tasks and information (model) elements to include in a view is defined through multi- dimensional inheritance according to the IRTV dimensions
---
6. Platform delivery!
Platform delivery involved training users, but as well integrating existing application sys- tems and databases, applying e.g. model-configured data exchange, parameterizing APIs and web services.
7. Operation and improvement!
Operation and improvement deals with the continued customization, adaptation and exten- sion of the solution to cover a wider scope, handle environmental changes, or reflect im- proved work practices.
Module 1 tips
- ...
- ...
Module 2 tips
- ...
- ...
Module 3 tips
- ...
- ...
.
## Repository structure
This Repository files and folders:
Projectwork.
1. ***README.md*** - This is the README (index) file for this Projectwork.
1. ***ProjectworkGuide.md*** - This is the Guide for the student(s), with general information about the Projectwork and the procedure for performing the Projectwork.
1. ***TheChallenge.md*** - This is where the challenge and Goals for this Courswork is given.
1. ***ProjectworkSubmission.md*** - This is the Modell(s) that answer to the goals and challenges given in this Projectwork.
1. ***CoursesAndTests.md*** - This is where links to tutorials and self-tests relevant to perform this Projectwork.
1. ***models*** - This is the folder where the you put modelfiles for the Projectwork.
1. ***doc*** - This is the folder where the teacher put additional documents for the Projectwork.
1. ***img*** - This is the folder where the teacher put images for the Projectwork.
1. ***.gitignore*** - Here you can add all files and folders that you want git to ignored and not pushed to GitHub repository.
1. ***config.yml*** Configuration file for MarkDown to HTML in GitHub-pages.
---
.
Keep striving for progress over perfection! A little progress every day will go a very long way!" :)
---