Workpackage Structure

We now have the first draft of a DFD describing inter-package dependencies as elements of the architecture. Some links are still missing, you are welcome to contribute to this. Please have a look at the SystemArchitecture page.

Please note WP contents are now in separate files since I noticed corruption between edits. Please try to do the edits with Firefox not Explorer. If you would like to print out an "all-in-one" version of the WP descriptions, please navigate to version 21 of this page - correct as of 19th April 2007 at 14:30 CET. NM

NOTE. WP3 and WP4 have been exchanged for nore natural flow (2007-04-13)

WorkPackage1: Project Management ( PF)


Guarantee the successful realisation and conclusion of the project. Implement and maintain an effective administrative and management infrastructure throughout all phases, including effective internal procedures, communication, reporting and meetings. Management of the project by objectives successfully in regards to time, quality, budget, legal and contractual issues. Efficient risk- and quality management.

WorkPackage2: Requirement specification and analysis ( PF, SAP, US)

Objectives: Development environments designed for end users have to bridge the gap between the technical layer of services and the layer of appropriate user interfaces. On the technical level, services are described by speficications of their interfaces and functionality which imposes constraints for possible topologies for assemblies. On the UI level, these technical aspects have to be represented in a waxy appropriate for end users, i.e., taking into account domain specific mental models. This work package will derive empirically grounded requirements for domain-oriented development environments (DODEs) from both layers. Implications for the design of DODE will be analysed.

potential pitfall:
  • avoid impression that project is too vague, don't just say "formulate requirements" but "identify detailed requirements and working practices of industrial partners in relation to the proposal objectives". This would include work on identifying metaphors and representations used by end users.

T2.1: Technology driven requirements ( SAP, VA, PF)

T2.2: Scenario-driven requirements ( US, UM, PF, VA, PM, SAP)

WorkPackage3: Use of Architectural (Design) Information for Service Discovery and Assembly ( PM)

  • General goal: to generate an executable process from a service assembly defined in the end user design environment
  • Generate an abstract and annotated process description as an enhanced service specification from a service assembly, taking into consideration: user characteristics and non functional requirements (context)
  • Retrieve concrete services able to fulfill the requirements of enhanced service specification from the advanced service registry
  • Service procurement allows negotiating QoS and price for selected services
  • Formal verification…
  • Service composition creates an executable process with Optimization, interface mediation, SLA (interacting with procurement), contract generation

T3.1. Develop Assembly Description Language ( UM, PM);

T3.2. Service specification meta-data ( US, UM, PF, PM)

T3.3. Translation mechanism ( PM, UM)

T3.4. Formal Verification Mechanism ( PM, UM)

T3.5 Service Composition and Procurement ( PM, ??)

WorkPackage4: Domain-independent Designs for End User Service Assembly Environments ( UM)

  • Definition of integrated appropriation support mechanisms for DoDEs
  • Formalise appropriate problem-solving models and patterns
  • Develop conceptual models of design assistance
  • Specify assistive mechanisms and techniques
  • Discover commonalities in design patterns and models across the different user scenarios
  • Compare with Domain Theory findings to formulate core knowledge structures
  • Design the Reuseable Designs Catalogue
  • Design a Generic Visual Editor and integrate with Designer's Assistant blueprints
  • Design generic infrastructure designs for service procurement, composition and monitoring
  • Design generic collaborative infrastructure
  • Provide methodological guidance about how to customise the generic design blueprints into domain-specific environments

To solve the conflicts of WP4 and WP5 we should develop all domain-independent parts of the system in WP4 - for me this is basically a generic platform, containing mechanisms for service discovery and assembly, etc. In WP5 we should focus on the domain-dependent parts of the system, basically user interfaces with domain-specific methaphors, etc. Finally we get a system with multiple, plugable user interfaces for different domains. WP6 should be parallel to WP5 and WP6 to ensure a continous integration, like AH sugessted yesterday. Makes that sense? - CD

T4.1. Define appropriation support mechanisms for service composions ( US)

T4.2. Assistive mechanisms for user-driven design of service assemblies ( UM, CMU, US, PF, PM)

T4.3. Knowledge structures reuse ( UM)

T4.4. Generic Infrastructure Design ( UM)

T4.5. Develop Environment Customisation Method ( UM)

WorkPackage5: Design of a Domain-oriented design environment for service assembly ( US)

  • Analyse findings from scenario-driven requirements and user feedback to mock-ups
  • Integrate with existing findings on "natural programming"
  • Develop domain-specific representations and metaphors
  • Develop domain-speific assistive mechanisms
  • implement the domain customisation guidance of D.4.5 to systematically construct domain-specific designs for a DoDE.
  • whilst at stage of design, consider what would be connections to legacy systems to make the prototype useful within a company

tasks: (each task may be repeated for the two application domains)

T5.1. Domain-specific Representations and Assistive mechanisms (was "Natural Programming") ( CMU, UM, US, SAP)

T5.2. Customise framework to a specific user case ( SAP, PF, UM, US)

T5.3. Domain Specific Appropriation Support (was Integration with legacy systems) ( ??. PF, UM, US)

WorkPackage6: Integrated prototype development ( SAP, PF)

WorkPackage7: Prototype validation activities ( VA, US, UM)


T7.1 Early useability validation - lab-based useability of prototype ( UM, US)

Start date: ???

  • ???

Description of work ???

  • ???

T7.2. Validation with end users - did the prototype meet their requirements - ( End Users, PF, US)

Start date: ???

  • ???

Description of work ???

  • ???

T7.3. Reflection and Lesson Learnt ( End Users, UM, US)

Start date: ???

  • ???

Description of work ???

  • ???

WorkPackage8: Dissemination and Exploitation ( SAP)


Dissemination and exploitation are recognized as the key enabler for the success of the U-SAY project. Hence all partners are committed to the dissemination of research results and the exploitation of project results to create added value for the Europe's economy and ciizens.

T8.1: Exploitation ( SAP, VA)

T8.2: Dissemination ( UM)

T8.3: Integration with EU research activities ( PF?)

-- NikolayMehandjiev - 28 Mar 2007

This topic: Adesa > WebHome > NextSteps > WpStructure
Topic revision: 27 Apr 2007, ChristianDoerner
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback