Specific Projects

ATM:

Air Traffic Management: Wedn.9:30-10:10

• Team:
  • Jacob Andersen: jacob222@pop.k-net.dk
  • Morten Peter Lindegaard: c948403@student.dtu.dk
  • Daria Rytter: daria@fuw.edu.pl
  • Peter Viuf: c948688@student.dtu.dk
• Contacts: PDC (Prolog Devt. Center), SAS, SLV, KLH
• Scope & Span:
  • Domains:
    • Air Traffic: cf. models of air traffic -- What is air traffic: airspace (airports, airdomes, air corridors, etc.); time-tables; flights as functions of time in airspaces and related to timetables.
      See chapter 8 for details.
    • Airport: What is an airport: from check-in to gates and from gates to customs; check-in counter, gate, luggage conveyor belt, luggage truck, fuel truck, etc.; assignments and staffing.
      Models of airport (i) runways, taxi-ways, tarmac and gates; (ii) the aircraft parking places to ``virtual gates'': passenger gates (direct (``finger connected''), or on-field: by bus), baggage'' gates'' (departure, resp. arrival) and baggage conveyor belt distribution system; (iii) fuel ``gates'' (depots) [fuel distribution sub-system]; (iv) catering ``gates''; (v) mechanics ``gates''; etc. Models of passenger in and out flows: departure, resp. arrival (check-in, security clearance, passport, miscellaneous [departure, resp. transit lounges, shopping malls, etc.], baggegae claim, customs, etc.
    • Airline: What is an airline: Reservations, check-in, on-board service; resource allocation and scheduling (aircrafts, staff, maintenance, etc.); etc. Only as seen relative to the above two other air traffic sub-systems.
  • Requirements: An integrated, distributed system linking air traffic control to airport and airline operations and management.
    As air traffic becomes increasingly congested and monitoring & control moves away from ground centers to satellites and cockpits, as airlines enter into geographically wider and operationally closer `partnerships' and `alliances', and as airports become increasingly congested, immigration and customs disappear and passengers demand much faster ``curb-side'' to ``flight-seat'' (and reverse) departure (resp. arrival and transit), air traffic, airlines and airports need have their operations planned and executed with highest degree of computer & communications facilitated monitoring and control of these operations.
  • Software Design:

Demo:

A TripTych Demo: Wedn.14:00-14:40

• Team:
  • Morten Borges: c958164@student.dtu.dk
  • Jakob Braad: c958165@student.dtu.dk
  • Jon Un Chul Fuglsang: c958249@student.dtu.dk
  • Karin Stella Mogensen: ksm@kampsax.dtu.dk
  • Ulrik Svanlundh: us@kampsax.dtu.dk
• Scope & Span:
  • Domain: Browsing, visualising, animating, building and abstract interpretation of development document concepts; semi-automatic generation of development specific demos for domains, requirements and software designs; etc.
  • Requirements:
  • Software Design:

FiSiCS:

Financial Service Industries (Computing System): Thu.10:00-10:40

• Team:
  • Bjarke Wegge Andersen, c948016@student.dtu.dk: Securities Trading
  • Thomas Andersen, c938030@student.dtu.dk: Banking
  • Lars Jensen, c948294@student.dtu.dk: Life/Pension Insurance
  • Jon Lee Kierkegaard, jlk@imm.dtu.dk: Clearing and Electronic Securities
• Contacts: IBM, Den Danske Bank, Danish Stock Exchange, Danica Insurance, Danske Kapitalanlæg, etc.
• Scope & Span:
  • Domain: A financial services industry consists of a number of diverse enterprises: Banks, insurance companies, securities traders (brokers, stock exchanges), portofolio managers, securities instrument clearing houses, etc.
    Stake-holders include enterprise clients, owners, management and workers and regulatory agencies.
    Clients open and close accounts, deposit, transfer and withdraw money and securities instruments; establish, obtain, repay, forfeit and pay-up on loans; establish insurance policies (life, health, accident, burglary, risk, etc.), pay premiums, claim payments, etc.; buy, transfer and sell securities; etc.
    Enterprises merge, diversify, offer combinations of financial services and compete.
    See chapter 8 for details.
  • Requirements: ``The Financial Smart Card''
    Whereas the current ideas of ``electronic wallets'' are mere electronic versions of todays physical leather gadgets, we foresee a ``Financial Smart Card'' on which not only all data stroage but also most computing takes place -- within and across the spectrum of financial services grossly outlined above. We refer to a MSc Thesis (Crilles Jansen, 1998) in which such a ``smart banking card'' architecture was developed.
  • Software Design:

LiMaCS:

Library Monitoring and Control System: Wedn.13:00-13:40
cum: Electronic Trade !

• Team:
  • Erik Husmark: c938271@student.dtu.dk
  • Mads Kristian Kiilerich: mads@kiilerich.com
  • Steen Sannung: sjs@logosdesign.dk
• Contacts: PF Library, DTV
• Scope & Span:
  • Domain: What is a Library System? Libraries, borrowers and publishers (library document providers). Library functions: Acquisition, catalogueing, lending, circulation, internal resource management, etc. Borrower functions: Inquiring, borrowing, returning, failining to do so, etc. Publisher functions: Advertisiing, responding to inquieries, selling, invoicing, etc.
    • Relation (?) to Electronic Trade:
      Trade is characterised by consumers and suppliers, producers and traders. Besides these four ``players'' there are products, product catalogues (prices, terms-of-delivery, etc.), product descriptions, production plans, and production. Consumers inquire, order, receive, accept and pay. Suppliers stock-up, respond to inquieries, accept and deliver orders, send invoices, and receive payments and rejects. Producers develop (design) and produce products (in responce to orders) and otherwise interface to suppliers. Traders act as negotiators between consumers and suppliers, suppliers and producers, producers, and suppliers: pairs of ``opposites'' as well as groups of ``likes''. Any one enterprise may in any project be two or more, incl. all of consumers, suppliers, producers and traders.
  • Requirements: Internet libraries, borrowers and publishers -- library system traders linking these three categories together.
    • Relation (?) to Electronic Trade:
      
    • ``Agile Production''
      A consumer places a tender-for-bid for the acquisition and delivery of a large-scale product (a large cement factory, or 100.000 units of mechanical ``gear'', etc.). One or more traders negotiate, each between two or more suppliers and producers, for the bidding, production and delivery of the announced product. We foresee a net-based, semi to almost fully automatic information ``search'', gathering and evaluation mechanism monitored by the trader -- a software support which significantly extends current catalogueing, product tendering and bidding software.
  • Software Design: ...

MaTraS:

Macro Trading System -- See above: Relation to Electronic Trade / LiMaCS

• Team:
  • Peter Buch peb@dfu.min.dk
• Scope & Span: Suppliers and Consumers, Producers and Traders
  • Domain: Interaction, in general, between suppliers and consumers, producers and traders
  • Requirements: Support mechanisms for electronic business transactions: inquieries/requests/orders and production/deliver/invoicing.
  • Software Design: A distributed architecture and a secure, accessible and available program organisation.

MiTraS:

Metropolitan Transportation System: Mon.13:00-13:40

• Team:
  • Asger Eir: c928276@student.dtu.dk, ae@cadpoint.dk
  • Jesper Saxtorph: c918814@student.dtu.dk
• Contacts: HT, DSB, DNRA, PDC
• Scope & Span:
  • Domain: Local, regional, national and international trucks and busses, trains (incl. metros), ships and flights; passengers and freight; scheduled and on-hire transport; routes, stops, connections, transfers, tracing, ticketing, information, etc.
    Focus, as an example, on the Øresund region!
    Detailed Domain Synopsis:
    In transport there are the ``things'' (usually people and freight) transported, the mode of transport (the vehicles [taxis, busses, metros, trains, ships, aircraft, etc.]), the route of transport (roads, rails, ship lanes, air corridors, etc.), the moving force (incl. the ancillary resources otherwise needed (drivers, ticketing agents, etc.)), and the time or frequency time-tables.
    We propose an individual and comparative study of the route nets of transport: Stops, transfers, connections, etc.; of time and frequency time-tables (design [based on prognoses], scheduling and rescheduling); of traffic (despatch, monitoring and control); of passengers (inqueries, ticketing, flow, etc.); and of other resources (staff and equipment allocation and scheduling, etc.); etc. Emphasis is suggested put on traffic co-ordination.
  • Requirements:
    ``An Integrated Øresund Region Transport System
    -- and its `Transport Smart Card' ''
    We propose to instantiate the normative domain of metropolitan transport to the instance of the Øresund Region, and suggest that a ``Transport Smart Card'' be a main means of information, of fare computation and collection, of the gathering of metropolitan transport statistics, and much else .The current `Smart Card' initiatives, it is believed, fall far short of what can really be achieved in ``inverting'' computations and data storage.
  • Software Design: ...

PIMaCS:

Project Information and Monitoring (Computing System):

• Team:
  • Joannes Gullaksen: Wedn. 15:00-15:40: c972466@student.dtu.dk
  • Allan With Sørensen: Monday 11:00-11:40: with@a-vip.com
• Contacts: PPU Maconomy, Damgaard Data, Navision
• Scope & Span:
  • Domain:
    Generally:
    What is a project -- from earliest conception based on marketing, sales and service reports, via planning, design, production, orders, sales, etc., including warehousing, procurement, etc.; the monitoring and control of resources (monies, staff, materials).
    Production projects produce deliverables according to generic and instantiated project plans. Project plans describe flow and control of resources, their deployment and consumption. Project plans thus denote production. Production proceed in the manner of work flows with atomic and composite, serially deployable as well as concurrently executing tasks. Tasks are committed, begun and complete. Some tasks are aborted (and thus ``back-out'').
    Specifically:
    • Joannes Gullaksen:
      Study the SAP product and DB's Work Flow System Model.
      ...
    • Allan With Sørensen:
      Study PPU Maconomy, Navision and Concorde products.
      Isolate across all three product descriptions all those terms that reveal an understanding of the domain. ``Unify'' them, note differences in meaning of terms, and ``create'' a description, seen from the point of view of these three products, of what we refer to above as `General'! Thus this domain description is normative, but ``restricted'' to these three products -- and thus we could think of constructing instantiated domain descriptions. This will be done in the requirements description phase.
  • Requirements:
    In general:
    ``Autonomous Project Information, Monitoring & Control''
    Current Danish project support software products: Concorde XAL, Xapta, Navision and PPU Maconomy form part of a spectrum of products where the German SAP R/3 form a current ``high-end'' product.
    To help support these three Danish companies in further improving their products and in conceiving next-generation ``follow-ons'', the PiMaCS project proposal suggests that net-based, thus world-wide distributed projects be monitored and controlled using sophisticated operations research techniques of prediction, allocation, scheduling and rescheduling.
    We thus suggest to ``impose'' a view of strategic, tactical and operational resource management with clear borderlines between algorithmic and decision supported ``computations''.
    • Joannes Gullaksen: Recreate the SAP R/3 product requirements.
    • Allan With Sørensen:
      For each of the three products ``re-create'' ``the'' requirements that ``lie behind'' these individual products. Thus the domain requirements each have an instantiation component which amount to an instantiated domain description. Identify, for each, projection, instaitiation and extension.
  • Software Design:
    • Joannes Gullaksen:
      
    • Allan With Sørensen:
      Describe, grossly, and for each product, most important software (architecture) features informally and suggest a ``grand state'' definition.

HeCS:

Health Care Systems: Thu.11:00-11:40

• Team:
  • Steen Nikolaj Oldager: c938577@student.dtu.dk
• Contacts: Copenhagen Province Hospital IT, Greater Copenhagen Hospitals (HS) IT, Kommunedata, Hvidovre Hospital, etc.
• Scope & Span:
  • Domain: A country's health care system as seen from the perpectives of:
    • Healthy and sick people (through the patient medical record (PMR)),
    • the staff (nurses, paramedics, medical doctors) of rural clinics, town physicians and clinical test laboratories, local and national hospitals,
    • the staff of health insurance companies, and
    • the staff of ministries of health.
  • Requirements: ...
  • Software Design: ...
  • Problem Formulation:
    • Reasonably ``detailed'' domain models of: (70%)
      • Healthy and sick people (PMR)
      • Physicians
      • Clinical test laboratories
      • Hospitals
      It is currently (11.2.1999) believed that each of the above models are CSP-like models with an elaborated state, and that the four models ``communicate'' with each other and with such external, here undefined processes as the ministry of health, with insurance companies, etc.!
      Alternative Domain Synopsis:
      People are born, healthy or sick (incl. with disabilities), people live, and are alternatively healthy or sick, and illnesses accumulate. Over a life-time a ``record'' (collection of information) can be gathered concerning one person's state of health: time-stamped simple measurements, symptoms, diagnoses and treatments (in and out of hospitals, under the family physicians' or local, community nurse's care), etc. Let us refer to this `record' as the PHR (personal health record); it can be considered an extension and an aggregation of PMRs (patient medical records).
      Rural community paramedics, local physicians, clinical test laboratories and hospitals receive, diagnose, treat and release patients. The PHRs are augmented accordingly. These service (etc.) institutions otherwise allocate, schedule and deploy resources, and additionally interface with pharmacies, medical drug, instrument and equipment providers, pharmaceutical industries, health insurance companies and state and local health authorities (incl. monitoring and regulatory agencies).
    • Draft requirements (10%)
      ``A Life-long Personal Health Record & Patient Process Planning System''
      Routine treatment of ``standard'' diseases and bodily injuries need be vastly ``streamlined'' to cut down health-care costs. At the same time citizens need be far better informed about their state-of-health, the treatments planned for them, how these are progressing, possibly upcoming epidemics, etc. Tax-payers need be better informed about health care resource consumption and costs.
      We foresee a longer range project, HeCS, where rather comprehensive models of the domain as well as of a variety of cross-cutting and -relating software requirements are established for a ``Health Care Smart Card''.
    • Draft software architecture (10%)
    • Draft program organisation (10%)