The course exercises will form part of a mini-project on e.g. how to efficiently collect and make experiences re-usable from the semester 7 building site project.

A major problem today is to efficiently use experiences gathered during a project. Knowledge is stored in persons heads and re-used as these persons are involved in new projects. IT gives us opportunities to create meta knowledge (knowledge about knowledge, who knows what about what?) and also make computer stored knowledge easier accessible. We see everyday examples on mistakes and faults which could have been avoided especially if you are given some hints about where we problems could be expected.

During the NN building project the group will capture problems and their solutions. This information shall be captured and stored by means of IT support. A similar project, SERFIN, regarding handling of technical building maintenance information is found at http://it.civil.auc.dk/it/reports/r_serfin2_5_1999.doc. See also the knowledge acquisiton and quality marking process at serfin_process

We could call the mini-project MEXIN2000, management experience on Internet.

MEXIN2000 should be available from an optional website through a conventional HTML browser. The following activites will contribute to the buiding-up of MEXIN2000

• Listing and structuring of building project and building process concepts which can classify possible knowledge domains such as geometric product model descriptions, documents, design process, construction process, building maintenance process, IT tools, etc. (exercise during the 'Application Information Models' session)
• Listing of data used in the proposed system
• categorization of actors in the experience capture process (user idenfication)
• conceptual layout of a MEXIN2000 functionality (which aspects of users work will be supported)
• Work Flow models to describe the actors/roles in the application and what type of messages that are are exchanged.
• Sequence Models describing how sequnces of actions are performed for the studied case.
• Artefact Models to which describe artefacts that can/is used (forms, databases, communication spaces, etc.)
• choose of knowledge representations (in this case hypertext and optionaly relational database)
• continous implementation of a demonstrator

Group discussion 4010a, 15.11.2000

The group presents a conceptual layout of a form for accessing data stored in a database. The form is the starting point for a discussion and modeling of the underlying data structure. Previous discussions have revealed the group aims at an ASP/HTML access database implementation. Work flow, sequence models, and use cases has been described before

The Customer, C, reports a problem to a Case Handler, CH. CH discusses the problem withh C and fills at the same time in a form. The form should be handled from the web client and information stored in a database.

The form has the following structure

• General information (context, date, C, CH, ….)
• Fault report (pre defined values in product group, material, fault, activity and descriptive data in fault description, cause, comments [proposals for new product group definition, similar fault in other case,…]).
• Repair (price, action, who pays, payment type)

• FAULT: fault id, material,, tytpe, ….,…,
• REPAIR: fault id, see above with additional repair id for later use if new repair method will arise for this type of fault
• GENERAL: nr (id), CH, date,..,,.. fault id,
• CUSTOMER:
• CASE_HANDLER: including competence profile for later knowledge extraction and analyses.

Click on the image to enlarge

The next steps will be

1. redesign the conceptual layout of the form
2. draw the database structure
3. implement the data structure in Access (with a few sample data)
4. Define a few typical questions that can be put to the database in a real use case
5. Make tests direct in Access with simple questions (no complicated forms)
6. Install the Internet Information Server with links to the database (Windows environment)
7. Write a simple ASP/HTML file containing one or two coded SELECT clauses. Test.
8. Design the question form according to test cases with appropriate input values placed in the SELECT, WHERE clauses together with coded values.
9. Test the ASP/HTML form.

Group discussion 4010a, 15.11.2000

• work flow models (representing communication and co-ordination necessary to do the work) messages sent between different persons/roles
• Sequence models showing the detailed work steps necessary to achieve an intent

Work flow model in the group 4010B mini-project involves the following roles.

• brugere (user), B
• byggeledere (project leader), P
• under entreprenør (sub-contractor), S

Click on the image to enlarge

B then has the possibilities to choose between alternative modifications (alterations) within the flat, e.g. opening between kitchen and living room. The communication between Band P is through P's 'digital agent' to ease the burden on P. (This communication will take place on the WWW through forms and DB accesses).
When the alterations are fixed P puts them in the PRM database.

B also negotiates kitchen layout and installations with a Kitchen deliverer (vendor), K.
Part of B's final choice is send to P who puts it in the PRM database (for later access during e.g. sub-contractor work). The rest of the kitchen specification is stored by B (may be this could be developed to a separate storage service that P and the building owner should provide as a separate service).

In the workflow models the 'total' functionality is sketched,but not all is implemented, e.g. it is shown that P negotiate prices with sub contractors). The artefact models in the mini project mainly consists of the web communication interfaces and PRM. The PRM has the following parts

• Flat description (type, B specific alterations, and general part of kitchen)
• Drawings and descriptions of flat types
• Flat alteration specifications (type, text description, and price level)
• Not possible alteration alternatives (wall w1, wall w3, …etc.)

1. document the conceptual models (workflow, sequence , and product models)
2. structure the database (data model and normalisation)
3. implement the database (in Microsoft Access)
4. test the db off line (i.e. direct on the workstation with simple questionnaires). Define typical test cases first (get inspiration from the sequence models)
5. write an ASP file with a typical SELECT specification hard coded in the file.
6. expand the ASP file with a simple form
7. make the final ASP files. One for selecting alternatives, one for sending the final choice to P (in the latter case the final choice is sent to P as an email from the form and P has to manually put the result in the database).