Difference between revisions of "System Overview Diagram"
| Line 31: | Line 31: | ||
Often the developers "thinks" in isolated "boxes" that has related functionality abstracting the environment that the system-to-be interacts with. In software development these boxes are often called classes. In hardware development the boxes are block of related components forming an unambiguous function. | Often the developers "thinks" in isolated "boxes" that has related functionality abstracting the environment that the system-to-be interacts with. In software development these boxes are often called classes. In hardware development the boxes are block of related components forming an unambiguous function. | ||
| − | In the very early phases of a development project a diagram with boxes can be used to model the system-to-be in overall terms. Early in the development process there is no decision about how the functionality should be implemented, but only that the functionality is needed. Engineers tends to immediately to go into "implementation mode", that is to immediately determine how a give functionality can be implemented. | + | In the very early phases of a development project a diagram with boxes can be used to model the system-to-be in overall terms. Early in the development process there is no decision about how the functionality should be implemented, but only that the functionality is needed. Engineers tends to immediately to go into "implementation mode", that is to immediately determine how a give functionality can be implemented. This is not a recommended way to go, because one tends to overlook obvious or simple solutions or even change the requirements away from what the customer expects, because the developer is locked on a specific solution that is well-known on beforehand. |
| + | |||
| + | Later in the process the System Overview Diagram will be more detailed and probably split into a hardware block diagram and a class diagram for the software part. But the decision about what should be implemented in hardware and which parts in software should be made on an enlightened base, when all requirements has been analysed in detail. | ||
== Example == | == Example == | ||
An example will be presented later. Please return to this page later. | An example will be presented later. Please return to this page later. | ||
Revision as of 11:58, 11 August 2010
What
A overview in blocks of the system-to-be.
How
The dish
A diagram showing the system at-a-glance.
Ingredients
Process
The Rich Picture shows basically the environment that system-to-be should operate within and the system-to-be is not a part of the Rich Picture.
In order to make the first overview of the system-to-be the interfaces that the system needs can be found in the Rich Picture.
From the System Definition the functionality can be determined.
Compose a diagram using squares to indicate a block that isolates related functionality. Do not at all think how the functionality can be implemented. Decisions about how to implement a specific functionality will be made later when considerations about the technical platform are done.
Use simple lines or arrowed lines to indicate connections between the blocks. The arrows can indicate information flow direction. Descriptions or names can indicate the type of information flowing in the connection. Do not consider number of wires, bits or the like at this point.
Why
Often the developers "thinks" in isolated "boxes" that has related functionality abstracting the environment that the system-to-be interacts with. In software development these boxes are often called classes. In hardware development the boxes are block of related components forming an unambiguous function.
In the very early phases of a development project a diagram with boxes can be used to model the system-to-be in overall terms. Early in the development process there is no decision about how the functionality should be implemented, but only that the functionality is needed. Engineers tends to immediately to go into "implementation mode", that is to immediately determine how a give functionality can be implemented. This is not a recommended way to go, because one tends to overlook obvious or simple solutions or even change the requirements away from what the customer expects, because the developer is locked on a specific solution that is well-known on beforehand.
Later in the process the System Overview Diagram will be more detailed and probably split into a hardware block diagram and a class diagram for the software part. But the decision about what should be implemented in hardware and which parts in software should be made on an enlightened base, when all requirements has been analysed in detail.
Example
An example will be presented later. Please return to this page later.
