System Integration |
Dedicated to the dissemination of System Integration information |
Generic Description of S.I. |
If you can describe System Integration (S.I.) at a high level, i.e. in a more generic manner, this will enable you to learn lessons from other S.I. processes you have taken part in and also from other processes in general.
If you were to touch the engine block of a car that is running you would get burnt, from this you learn that touching the engine block of a car that is running burns you; you may also have learnt that touching anything under the bonnet of a car, whilst it is running, may burn you. You may also learn that touching a component that heats up, e.g. a cooker element, whilst it is turned on, can burn you.
Initially you learnt about the engine block, you then abstracted this lesson to learn about anything under the bonnet, you then abstracted the lesson further to learn about a completely unrelated system - the cooker.
The vast majority of people know how an hotel works, it has a main entrance, somewhere near the main entrance will be reception. If you are going to use an hotel you know to use the main entrance, look around for reception, then go to the reception desk and give the receptionist your details so you can be allocated a room.
If someone said they would meet you at the reception of an hotel you wouldn’t go to the third floor and start looking for reception, you would start your search at the ground floor.
If you are now going to use a specific hotel you use the above generic model of an hotel, i.e. you go to the main entrance and look around for the reception. You see that it is on the right hand side of the main entrance, you proceed to the reception desk.
The next day, when you are coming back to the hotel, you now enter the main entrance and go to the right. This is case of applying a generic model of a hotel, the reception is somewhere near the entrance, to a specific situation, the reception is on the right hand side. You have slightly adjusted the generic model of a hotel to a specific situation.
Some time ago you had a problem with your meal at a restaurant, you became abusive to the waiter, one thing lead to another and you eventually got thrown out of the restaurant.
You have now booked into the hotel and learn that the room does not have a sea view, which you have paid for, but looks out over the kitchens at the rear of the hotel. You learnt, from the restaurant, that being abusive doesn’t work so you politely state the problem to the hotel manager. You state your case in a logical manner and ask the manager to resolve the problem. This is an example of learning something about one situation, the hotel, from another, the restaurant.
In all of the above cases you learnt the lesson by looking at the situation and generalizing the lessons learnt, you then applied the lessons learnt to a specific situation. You also used a generic model of a situation, the hotel, and applied it to a specific instance of an hotel.
The same needs to be done with S.I. My generic description of S.I. is: -
1. You assemble the sub-systems, plug then together, and check that the system as a whole, works. 2. You put the system into specific situations and ensure that the system works in the specific situations, if it doesn’t you take a ‘snapshot’ of the system and analyze this snapshot. 3. You do formal testing according to a document that is derived fro the system requirements. 4. You prove to the customer that the system works.
|
|