ISBUS Assigment Submission Complicite 05112010

8/8/2019 ISBUS Assigment Submission Complicite 05112010

1/31

Information System and Business Processes

(Group: Complicite)

Course Title: Information System and Business Processes

Instructor Name: Peter Rittgen

Team Structure

Student ID Name

S101315 Gaurav Mehendiratta

S101251 Sikandar Iqbal


2/31

Reflections on the modelling process

The process to make models didnt begin with the search of languages but with the

purpose of why and what kind of model we need to make for the given situation and what

parts should we abstract from reality. The process really started from defining and

categorizing the core purposes of the hospital case and also finding out which parts should

be included and which parts should be left out. The next major criteria is to make a choice of

the modelling process in such a manner that it describes reality and should assist in quickdecision making of the core processes and should not act as an hurdle for the next stage of

development i.e., from the stage of model to its development into an artefact. In other

words ideally it ought to be independent of the choices of computer programming

languages so that it is easy to put into practice. However it is to be noted that it is only a

modelling language used for analysing system design and not a method. The next part was

to determine if actually the model behaves in a similar way as the real system does. The

relation of system with influence and its behaviour has a parallel in the model in the form of

inputs and outputs or if there are dependencies that are being missed out in the

construction of the model. Important considerations for the same included to determine the

various states (snapshots) of the core determined processes and finding out the main

participants (actors/even resources) involved for the same. The approach used for building

the model is primarily taken from the so called first five steps of Quality Based Modelling

which are to first determine the purpose followed by describing the system followed by

identification of problems and their relations and then to identify Goals and their structure

with the step of building the model.

1.) Determine the purpose: The purpose was identified as stated in the very problem itselfi.e., to streamline their business processes in an attempt to provide better care, to

reduce the workload of the staff and to make better use of resources with a key focus

on the four core processes of admission of patients, patient care, discharge of patients

and patient transfer.


3/31

2.) Describing the system: The system was first described using a flow diagram and definingthe main participants involved in the various processes. This included identification of

important sub processes, identifying main participants & their attributes and also

identifying the non human entities and key deliverables coming out or getting updated

in each process.

a.) Admission of patientsSub Processes: Transport to hospital, assigning bed, filling admission

documents, recording time of admission, examination by physician.

Key Participants: Patient, General Practitioner, Male Nurse, Admission Clerk,

Physician, Time, PMS

Deliverables: Admission documents, ward books, suspension folder, PC,

anamnesis forms, test request forms, diagnosis form.

b.)Patient CareSub Processes: Conducting ward rounds, medical and general care, test

requests, diagnosis, therapy.Key Participants: Patient, Nurse, Physician, Pharmacy

Deliverables: Lab tests, diet orders, medical record, patient record.

c.) Patient DischargeKey Participants: Patient, Physician, Nurse.

Deliverables: Discharge documents, occupancy list, patient record.

d.)Patient TransferSub Processes: Preparing discharge documents & collecting them together,

store in computer, updating PMS, bed register,

Key participants: Physician, Nurse, Secretary, PMS, Patient Transport.

Deliverables: Doctors transfer report, nurse transfer report, discharge

documents, diagnostic findings, x-ray reports.


4/31

3.) Identification of problems and their relations: The part of identification of problemswas to list out all the ambiguities present in the processes as per the provided project

description and the assumptions made for the same. These were discovered as follows

and have been categorized according to their respective process.

a.) Admission of Patients

a.1.)There is no clear description of the employment status and more importantly

physical location of the nurse who transports the patient. The overall process can

look different if the nurse is employed by the general practitioner and works at GPs

location or if he is employed by the hospital and works in the hospital or is a person

who independent of employer works from a field location like an ambulance driver.

For our case it is assumed that he is employed with the GP.

a.2.) The description of the processes that follow after putting the documents in

the filing basket is not described clearly.

a.3.) The need for ward book updating is not clear especially when there is already

an existence of patient Management System. The capabilities of PMS are also not

described clearly which makes it difficult to judge if at all there is a need of ward

book or not. It is thus taken into consideration at the time of reengineering that

majority of the tasks like ward book updations, suspension folder, creation of

transfer reports etc can be taken care by existing PMS or by improving it. This can

lead to a great improvement in reduction of the business processes wastes like

rework and maintaining inventory. (Sarkar, 2009)

a.4.) The description has nowhere mentioned if the patients previous records are

taken into account while admitting him or more importantly during the stage of

patient care. There is a very high need that before conducting even any of the

diagnostic tests the patients history is retrieved and all the diagnosis which may be

can be made redundant with the help of these old records is actually not done forthe faster processing and treatment of the patient.


5/31

b.)Patient Careb.1.)The description states that the whole care cycle gets repeated if patient is not

recovered even at the stage of discharge. It is incorrect or ambiguous as never do we

find the whole cycle getting repeated from the start as many a times certain steps of

the cycle might not be required at all like preparing the test forms etc. There should

be a clearer description of what steps in the care cycle are compulsory every time

and what are optional or dependent on the status quo of the patient.

c.) Patient Dischargec.1.) There is no clear description if the short doctors note is of a standard format

and if it can be automated to a great degree or not or is it always necessary to

describe all by the doctor every time. Also there is no clear description if the tasks

performed by physician and nurse demand both of them to be physically present

together at the time of discharge or if they can work independently from different

physical locations. In simpler terms it is not clear if the doctor is required for all

administrative formalities. Therefore it is assumed at the time of re-engineering that

the doctor is not required to be present in person for tasks that doesnt forms hiskey areas of responsibilities and thus these independent tasks of nurse and physician

can be done in parallel as against the sequential approach being mentioned in the

given scenario. Also as subject matter expert like a physician is surely paid highly and

therefore shouldnt be involved in administrative tasks like updating the occupancy

list etc.

c.2.) It isnt clear if the doctor makes use of the documentation done by nurse in

the discharge process. Therefore following the content of the case provided we

consider that the doctors note and his involvement in the process of discharge is

dependent only on the medical & patient records thereby allowing parallel

completion of their respective tasks.

d.)Patient Transferd.1) It is not clear if the doctors transfer report dictated by the physician is of a

specific format and thus if we can have ready templates for it incorporated within PMS


6/31


7/31

Reflections on the Modelling Languages

To find out the best suited language a comparative analysis was done, which is discussed

in the next section, of the four options (Petri Nets, Unified Modelling language, Event-

driven process chain and Interaction & Process diagrams/ DEMO) to arrive at the

commonalities offered by them and the points where these languages are different from

each other.

Unified Modelling Language (UML)

The first and the foremost choice for the selection of the language showed up with

UML primarily because of many reasons like our already existing object oriented

understanding of it and the way it has emerged as the modelling standard for both in the

software industry and business industry prompted us to choose it as the first language. The

key fact that UML is more of a computer language independent modelling technique (as

long as it is OOP) made this a further suitable choice. The next important aspect that UML

does offers is the various types of diagrams it has to represent the behaviour of the system

of and how the system behaves under different influences can be presented using it.

Though on a structural side UML offers various diagrammatic representation we chose to go

ahead only with defining classes (objects) and their attributes and operations, and preferred

to focus completely on the behavioural diagrams namely activity diagrams and use case

diagrams that reflects more on the business process activities, especially activity diagrams

play a vital role in showing parallel behaviour and to visualize how different use cases

interact with the wide array options of decision paths, swim lanes, synchronization bars

reflecting the parallel paths and sub activity states.

The biggest challenge with UML was defining what process is a function and what

process isnt a function. It got pretty messed up the first time we considered every process

to be a function. Thus it is of imperative importance to categorize the main system into sub

systems, and then group together certain tasks, and during the process of making use case


8/31

diagram to clearly distinguish and ascribe correct relations amongst use cases (extends,

uses).

The greatest set of advantages that came with use cases diagrams is that it went

hands in hand with the initially defined steps of quality based modelling and provided a

scope of decomposing system scope into more manageable pieces capturing the functional

requirements which in fact was somewhat already done in case description by defining four

core processed differently and independently.

EPC (Event Driven Process Chains)

The next choice of the language was Petri nets as it can be used to model any

discrete behaviour of the system but every time there was too much of difficulties in making

a decision of choice between decision paths and parallel processes as an example during the

stage of going back from patient discharge back to the stage of patient care in a situation

when physician determines the patients condition has gone worse. Furthermore Petri nets

caused the diagrams to look more and more complicated with an effort to show different

states especially when the increasing degrees of livenesss is something which is not required

in our hospital case. It further looked that Petri nets will suit more with discrete

environments like vending machines or stochastic processes involving complications like

deadlocks etc, and since ours (hospital case) is not a very discrete system with various

transition states and is more of a deterministic system its visualization is much simpler in

other languages (especially UML use cases) than in the structures of Petri Nets.

The difficulties with DEMO were its lack of implementation related details and due to

the fact that specific notation of DEMO it becomes hard to be understood by those that are

unfamiliar with the notation.

The choice of EPC was eventually the second choice of the language taken into work

for modelling the task. EPC started from the point where UML left off at the stage of use

cases, i.e., modelling the event. In this respect the activity diagrams could be seen

somewhat complimentary to the EPC models. The prime focus of EPC is that in its controlview the business processes play the prime role.


9/31

Comparison of the Languages

The modelling in these two languages is mainly done with a reductionist view by

abstracting a part of the reality and presenting it as a simplified representation of a system

that illustrates certain aspects of the system which are relevant to the purpose of the

model. These reduced pieces are then collected to visualize a larger picture of the system. In

a business scenario it should focus on visualizing the business process and its connected set

of activities (sequential or parallel) that carries out various business functions. The basic set

of requirements that we focused to reflect in our models independent of the choice of

language was to clearly depict the starting point, key deliverables of each functions, main

participants involved at different stages, triggers and deadlocks (if any), distinction between

parallel and sequential activities. The next set of requirements that are desired form the

model is if it can reflect upon the efficiency criteria of the four main core processes defined

in our case especially the constituents of the resource efficiency (), reusable resources and

process efficiency. The questions to be answered really are if our choice of languages helps

us in finding solutions to have optimal use of reusable resources, minimum idle time of

resources (people or machines) and how can it reflect upon visualizing the optimal

alignment of processes with the goals of the company with minimal waiting times and high

output. So the real question to be addressed is the original purpose described to streamline

their business processes in an attempt to provide better care, to reduce the workload of the

staff and to make better use of resources.

Keeping the business view at the core along with the technical aspects following

comparison is drawn between the two languages.

UML Vs EPC

UML and EPC both clearly depict the dependencies amongst the processes showingwhich process relies on which other process with UML even having clear relations of


10/31

inheritance and extends. It is easy to make out just by a glimpse to see the positions

pf all process in the hierarchical order.

UML and EPC miss the time aspects though the use case diagram does shows time asan actor but it doesnt clearly shows its role. The aspect of time on which they miss

out is the reflection on the duration of a function. They do not show if a given

process takes more time or less time as compared to the other processed drawn in

the diagrams.

Activity in UML is active element while an event is not active element. Therefore theevents are not explicitly declared. This transition in UML implies that as soon as an

activity finishes, it does not waits and immediately triggers the next activity.

EPC could be very effective in cases that include a large number of actors andprocesses

UML use case diagrams do not cater easily to the cases where two actors of thesame type are required simultaneously for processes like the situation in the end of

the case (Patient Transfer) where in one nurse updates the bed register and the

other updates the PMS. These two actors in UML use cases despite being of same

type are shown as two different actors attached to two different processes. Even

more is the case when the multiple actors of the same type are required

simultaneously for a single task. Such was not the situation which arise in hospital

case ! However EPC does handles such situations in a much simpler manner. In EPC

each node actor is connected to an activity showing the responsibility for the

actions. In the given case if there were two nurses for same task working together it

could be handled with the simple addition of another nurse, pointing to the same

process as the other nurse.

Notational Parallels between the two languages

The swim lanes in UML activity diagrams are same as the organizational units inEvent driven process chains. They are attached with functions that are responsible

for the various business processes. However in a function in EPC there can always be

more than one unit attached making it easier in the case when the organization hasmany business activities that are being executed by more than one actor, whereas in


11/31

UML swim lanes at a time can belong only to one actor. Swim lanes groups activities

that belong to the same actor in a certain process thus making it easy to see and

visualize the tasks associated with a specific actor. Thus EPC is very useful in the

situation that includes a large number of actors and processes despite being dense.

However as the number of actors increases it becomes increasingly difficult to

depict them using the swim lanes of UML as it caters to each actor separately. Also in

EPC each function is followed by an event thus making it more comprehendable to

understand the complex business processes whereas in UML though possible it is

very difficult to portray it, i.e., though swim lanes illustrate each actors set of

responsibilities for activities but it fails completely to address the complexity in the

system. Such though wasnt the situation in the given hospital case as neither the

number of business processes associated with an actor, nor the very number of

actors involved in different stages of core processes was never high to get to the

level where the weaknesses or strengths of the two language could be reflected or

be judged upon.

The branching and merging of control flows in the EPC is represented using thelogical XOR connector plus the events following it. The same mechanism in UML is

carried out using the decision diamond symbol and transition labels. (Ferdian, 2001)

The control flow in the EPC is same as the transitions in UML. (Ferdian, 2001) By comparing the syntax, EPC has OR connector but it does not work efficiently, but

UML lacks this feature. The OR connector in EPCs can cause some inconsistency and

ambiguous situations logically. (Ferdian, 2001)

Parallel processes require a solution of couple of models with XOR redundantmodeling.

Logical connector plays a very vital role. They can split control flow in the EPC andtransitions in UML.In bith of these the diagrams are somewhat constructed in a

similar way with options of branch/merge. The branching and merging in the EPC is

acheieved by making use of the logical XOR connector along with the events

following it. The same aspect of branching and merging in UML is achieved by using

the decision diamond symbol and transition labels. The same is shown as follows :


12/31

Fig 1.: Decision diamond in UML and Branching and merging using XOR in EPC

Both EPC and UML support the notion of parallelism known as fork/join. The forkingand joining in the EPC is shown using the logical AND connector while in UML

activity diagrams it is shown using the synchronization bar. However, EPC supports

OR connector while there is no notation in UML to denote the OR connector. The

parallel languages support. Forking and assembly is used in both languages. The

same is shown as follows :

Fig 2: Fork/ Join in UML and OR connector in EPC

One visulaiztion factor where EPC takes advantag over UML in readability is theusage of different colours for different aspects in EPC diagram thus making it visible

even with a glance to clearly follow the map and search for the exact organizational

unit, event etc.

There is no parallel of events in UML activity diagrams. These events in EPC are like apassive element which triggers of a function and in itself is a result of another

function.

UML activity diagrams are a small part of all the different types of models in UMLand are often dependent on the class diagrams and use case diagram thus making it

work as there is always another model to adapt to the currents, which in our case is

the business model. When it comes to EPC it is not a collection of lot of models but is

only single type of model only which could act as a hurdle as there could be no

means to convert the same into a programming language easily. The object oriented

approach of UML, thus have this as a major advantage.


13/31

Thus EPC and UML have their own strengths and weaknesses and the choice of using

them should be more and more dependent on the process under consideration. It is this

variety of differences and commonalities described above that led to the choices of the

two languages coming fruitful. Given the notational rules of EPC it occupies a lot of

space and are often much more dense than the UML diagrams but its sequential nature

and display of functions & respective organizational unit etc makes it pretty easy to be

followed by the persons who have no knowledge of modelling or more so of the object

oriented approaches. The same set of rules which makes EPC diagrams to be very dense

have an advantage that they make models to be described verbally in a very simple way.

When it comes to UML it doesnt describes the results/key deliverables of a process or

the process happening inside the case making it difficult to understand for those not

acquainted with the language. UML also to a great degree demands the understanding

of object oriented approach amongst its user as both use case diagrams and activity

diagrams discussed here do refer to the class diagrams. Also activity diagrams gets

detailed by the use case diagrams thus making it imperative to have use cases ready to

really understand the activity diagrams closely. This can be potential hurdle in

understanding of UML diagrams to those who are not acquainted with it.

The advantages offered by use case diagrams of UML is very important which is not

offered by EPC as they present a quick overview of the core functionalities that

constitute the system and sub systems clearly depicting the actors involved in each of

the use cases. Since in hospital case there were never many actors involved and there

was a clear distinction between the four core processes the UML case did reflected a

good graphical picture of the reality. However EPC doesnt offers similar structures like

use cases which can present the overview in a simplified manner. The large quantities of

entities involved in the construction of EPC diagrams makes it a not so preferred choice

against activity diagrams from UML as the time to build these models end up being quite

large.


14/31

Comparison of Models

We begin by comparing the Use case from UML with EPC diagram. This is followed

by comparing EPC diagrams with activity diagrams from UML from where a lot of parallels

can be drawn. Though as described earlier the real equivalence of EPC with UML is in

activity diagram, we do this comparison with use case diagrams with an aim to discover if

the actors used in the use case diagrams look similar to the organizational units of EPC and

what differences comes in the modelling under the two processes.

Since they have the same role in modelling they seems to be same in both the

models as shown below. However when we refer as an example to the discharge patient

process we observe the point of differences between the two set of models.

Actor (Use case) Organizational Unit (EPC)

Pre Requisites: With use cases diagram it is difficult to judge at all the necessarypreconditions of an event though in some cases it can be shown with the help of

relation but that is not the case every time. The same lacks in the

forward direction as well as it becomes difficult to find out the events that follow

after given event.

Decision Paths: Use Case Diagram doesnt reflects upon the decision making processat all whereas using the same actors and organizational unit in EPC it is clearly

depicted.


15/31

Parallel Processing: As a consequence of its inability to show pre-requisites andconsequential events that precede/follow a given event, the use case diagrams do

not clearly mark the events/processes that run in parallel to each other.

Activity Diagrams and EPC

As discussed earlier this is where a lot of parallels could be drawn between the UML

activity diagrams and he EPC model. However it is of great importance how the two

differentiate from each other with key points of differences. Actually if we look at it that if

both were to be more or same then we would have been doing a redundant work of doing

the modelling exercise in these two different languages or in other words would have made

the wrong selection of the languages. However being complimentary to each other it is

these differences that make the selection of modelling languages appropriate.

Apart from use case diagrams and class diagrams, swim lane activity diagrams are

other types of UML diagrams that are used in effort to model the business. It is important to

observe that they refer to class diagrams and their actual underlying attempt is to detail the

work done in the use case diagrams. To make a comparison lets reflect upon the medical

care in the two set of diagrams (refer appendix).

These diagrams clearly shows the similarities and differences in a swim-lane activity

diagrams and EPC models. As an example decision stages are shown as XOR operation in

EPC diagrams and the same is modelled with an aid of a decision diamond. The

organizational units in EPC diagram is modeled in swim lane title. Now what makes EPC

further special yet complicated is the elements and absence of which makes the activity

diagrams makes it look simple but thus it loses out on the purpose of having it.

Thus though UML depicts business process more easily, it does misses out on aspects

like having no notation to show the OR connector, causing difficulties to do modeling

arising because of an ambiguity caused by notation. In the process of patient transfer before

a nurse copies the transfer documents, she has to wait for the completion of the other

processes which cant be implemeted at the same time especially when they belong to two

different organizational units causing a time delay for which there is no clear notation in


16/31

activity diagrams thus making EPC more flexible and adequate or defining such business

processes that have dependencies.

The main difference that showed up in two languages during the process of

modelling lies in their respective core aims of theirs. UML being an object oriented approach

keeps a focus on the discrete and differentiable objects inside the system and it is the

system which is viewed upon as a collection of objects and not the other way around. While

when it comes down to EPC its main focus is on the processes happening inside the system

which further consists of sequences of events triggering activities/functions. All the events

somewhere have the origin in the starting events. Thus EPC offers with logical operators, an

event-driven control structure to clearly show complex control flow pointing out relevant

decisions and concurrencies of the processes.

UML activity diagrams are good in showing parallel process with the element tube.

The fork can run parallel flows with two or more streams together again somewhere later

with a range header. However with EPC the parallel flow paths with two elements can work

well but if it comes down to more than two then there would be an imperative need ofadding more and more connectors thereby making the EPC diagram more and more dense

and complex.

Though not reflected in the hospital case, a point of consideration is that UML

doesnt shows the format of the data sources where as he same can be shown in EPC like

digital formats, paper formats etc. EPC with its dense models shows more precisely the

complete aspects of organization unit connected to a process clearly showing the system.


17/31

Business process reengineering

Business Process Reengineering also referred to as Business Transformation or

Business Process Change Management Business is a management methodology based out

with an approach aiming at the fundamental rethinking and radical redesign of business

processes to achieve dramatic improvements in critical contemporary measures of

performance, such as cost, quality, service, and speed (Hammer & Champy)

In this we section we consider the important areas where we worked with the

reengineering concepts to improve on the overall process to solve out the existingambiguities. The following five parts of immediate importance were discovered during the

process of modelling that needs reengineering (refer appendix for diagrams).

a.) The majority of the of the tasks like ward book updations, suspension folder,creation of transfer reports etc can be taken care by existing PMS or by

improving it. These tasks presently been done by the nurse both in the computer

and register is causing delicacy of work which can be handled simple by the PMS.

Making PMS online and accessible according to rights and privileges can

automate a lot of more tasks like writing of the doctors note in the discharge

documents.

b.) As mentioned in the first step it is taken into account that the dischargedocuments can surely have fixed template formats with a space for doctors

comments which can be taken either by dictation or the physician can type themfrom his place in the PMS itself as there is no need for doctor to be present

physically during the discharge process for long. The idea if PMS is made

accessible to physician can reduce the workload and help in streamlining and

faster execution of processes like these.

c.) It is not clear if the secretary comes to take the signature for discharges in bulkor comes each and every time for every patient being discharged. It is important


18/31

to know if the discharges happen in a specific time window during the day or

they keep on happening at regular intervals throughout the day. In the former

case the secretary can take the bulk dictations in one go and take the bulk

signatures also in one go else in the latter case it would be go on in an

impromptu manner. In reengineering phase it is considered that it can be done

(repeated) in bulk at specific timings of the day. However the important aspect to

be noted here again is that if a more efficient PMS can be developed then that

could remove the role of secretary as the key task performed by secretary is to

take dictations and if that goes off then any available staff like a peon or nurse

that is employed at a lower cost can perform the task of collecting signed

documents.

d.) Checking of patient records at the time of patient care in the diagnosis part. Thisis an important point which is presently being left out as this can result not only

in some cases reduction of unnecessary performing of tasks like test reports etc,

but it can also help in a more accurate diagnosis which can further result in a

better care process. The same is reflected in the below shown diagrams.


19/31


20/31

e.) It is not clear if the doctor is required for all administrative formalities. Thereforeit is taken into consideration that doctor cant be required to be present in

person for tasks that doesnt forms his key areas of responsibilities and thus the

independent tasks of nurse and physician can be done in parallel as against the

sequential approach being mentioned in the given scenario at the time of patient

discharge. It is important to reduce cost as subject matter expert like a physician

is surely paid highly and therefore shouldnt be involved in administrative tasks

like updating the occupancy list etc. The same is reflected in the diagrams below:


21/31


22/31

Bibliography

Ferdian. (2001). A Comparison of Event-driven Process Chains and UML Activity Diagram for

Denoting Business Processes.

Hammer, M., & Champy, J. Reengineering the Corporation.

Sarkar, D. (2009, June 04). Eight Wastes of Lean in a Services Context. Six Sigma and Process

Excellence. Retrieved 11 01, 2010, from Lean for Services:

http://www.sixsigmaiq.com/columnarticle.cfm?externalid=753&columnid=15


23/31

Appendix

UML Use Case Diagrams

Hospital Case Diagram

Admission

Patient Care

Discharge

Patient Transfer

Admission Clerk

Male Nurse

Physician

Patient Transport

General Practitioner

Nurse

Lab

Secretary


24/31


25/31

Patient CareLab Request

Ward Round

Therapy

Patient Check up

Follow Medical Care

Patient Care

Diet Order

Pharmacy Order

Update Report Storage Room Order

Follow Therapy

NursePhysician

extends

extends

extends


26/31

Patient Discharge

Physician

Nurse

Order to Discharge

Patient

Dr short Note

PMS

Dischage Patient

Dischage Ducomentsextends

Update Medical

Record

Update Patient

Record

extends

extends


27/31

Patient Transfer

Physician

Nurse

Secretary

Patient Transfer

Dr.Report

Archive Report

Soft Report

Save Report

extends

extends

Nurse Report

Copy Report

Gather all Reports

Call PatientTransfer

Transfer Patient


28/31

Sample EPC Diagrams


29/31

Sample UML Activity iagrams


30/31

AdmistrationPhysicianNurseGeneral Practioner

Hospital Care

Not Admitted

Transer to Hospital

Admission Slip Assign Bed

Forward Slip

Ward Update

Update Admission RegUpdate Registration

Process Admission

Ducoments Slip Receive

Register Patients

Need Admission

Hospital Case Activity

Diagram


31/31

Patient Transfer

ISBUS Assigment Submission Complicite 05112010

Documents