Next: Project Generalities
Up: Projects and Teams
Previous: Projects and Teams
- 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%)
Next: Project Generalities
Up: Projects and Teams
Previous: Projects and Teams
Dines Bjorner
4/14/1999