-
Notifications
You must be signed in to change notification settings - Fork 0
SwDevFitpContextModel
aka. Context Diagram.
The context model show how the work relates to its business environment.
It shows only the flows of the information not the constraints(Rob06, ch04).
In most cases, projects that restrict their study to what they think the product will contain build less useful products and often miss important functionality that could well have been included in the eventual product(Rob06, ch03).
- Identify the work(what the customer needs to do, and how the product can support that)
if you are building a product intended to automate part of some existing work, then the study context should include those parts of the existing work—human activities, together with any existing computer systems—that could potentially influence the eventual product(Rob06, ch04).
References:
- Rob06: Mastering the Requirements Process Second Edition By Suzanne Robertson, James Robertson ISBN: 0321419499 Publisher: Addison Wesley Professional, 2006.
- Wei03:
Descriptions:
- Adjacent entity: The adjacent systems supply data to the work and/or receive data from it(Rob06,ch04).
- Context diagram: The drawing with TheWork and the adjacent systems.
- Context Model: The Context diagram + descriptions?
(org: SixSigmaDmadvDefine.txt) The purpose of this ContextModel it to give a graphical presentation of what is in scope, and what is out scope.
The purpose of tools such as the context model is to foster clear and accurate communication among the project stakeholders(Wei03,56).
- The context model graphically illustrates this boundary.
- It identifies terminators outside the system that interface to it in some way, as well as data, control, and material flows between the terminators and the system.
- The context model is the top level of abstraction in a data flow diagram developed according to the principles of structured analysis (Robertson and Robertson 1994), but it's a useful model for projects that follow any development methodology(Wei03,56).
In Visio use Flowchart -> Miscellaneous flowchart shapes.
From the [SipocProcess] description/table
- Adjacent systems: In this case, the computer systems, or the parts that you are not changing, are adjacent systems(Rob06,c4,p9).
- If this is the top level Problem Frame/Context diagram, then each entity is probably a problem domain, in its own right.
- Represented as a square.
- Connector: According to Soren, in the Hatley-Pirbha Structured Analysis. All input/output must be shown on the top level(not necesarrily in detail) no new I/O is allowed at lower levels.
- Represented as a line, without arrows(since an arrow could indicate flow direction).
- The Work: Configure Machine M to produce effects R in domain D (Kov99,25).
- Do First-Cut Work Context(Rob06,c3,p11)
- The work context includes anything that you are permitted to change, and anything that you need to understand to decide what can or should be changed(Rob06,ch04).
- Represented as a circle.
graph TB;
the_work((The Work))
entity_1 -- connector text --- the_work;
entity_2 --- the_work;
entity_3 --- the_work;
entity_4 --- the_work;
(Test out the graph TD; maybe try TB or LR?)
%X% TODO V What detail level is right?/Needed? It seems to be rather important since we base rough estimates on it.
Create a table with a description of the Entities of the ContextDiagram
| Entity | Type | Description | Reference |
|---|---|---|---|
- Description: Short description of the Entity.
- Entity: Name of the entity.
- Reference: Link to a more detailed description of the the Entity.
- Type: Adjacent, Connector, TheWork.
%X% It seems like the Context model are based on building a Problem Domain Frame, See (Kov99,53)
See also [ProblemDomain]
This process expects that the [SipocProcess] has been created.
- Identify the domains of interest.
- Discovering your adjacent systems.
A domain is a subject matter area, and because it is "of interest," it is a subject matter area you need to know something about. Naturally(Rob06,ch3).
Look through the "customer" statements, paying attention to the subjects you need to know about(Rob06,ch03).
The domains of interest that you have identified act as input to discovering your adjacent systems(Rob06,ch03).
Each of these physical entities is potentially an adjacent system. We say "potentially" because we have to examine them before committing to any decisions.
For each entity, we ask if it forms part of the work or if it lies outside the project's authority and should not be considered as part of the work(Rob06,ch03).
Not all domains have a physical presence. Some domains, for example, are purely policies the work has to adopt. For example, the scheduling domain is a policy domain(Rob06,ch03).
The policies must be part of the work but does not appear as an adjacent system on the context model(Rob06,ch03).
- For each domain, ask if there are physical entities that somehow represent the domain(Rob06,ch03).
The adjacent systems are those pieces of work that supply your work with information or that receive information and services from your work. An adjacent system might be an organization, an individual, a computer system or some other piece of technology, or a combination of any of these. It is also the customer for the business use case(Rob06,ch04). Examine the adjacent system and consider what it really wants from that business use case(Rob06,ch04).
- What are the technological capabilities of the adjacent system? Is it capable of interacting with the product? Is it human? Does it have some interactive technological capability? Could it use, say, a mobile phone or a text message to initiate the business event?(Rob06,ch04)
- What is the desired outcome from the point of view of the adjacent system? What are its aspirations at the time of triggering the business event? Keep in mind that the intentions of the adjacent system may be disguised by the technological limitations of the products that are currently in use by the work(Rob06,ch04).
- What is the desired outcome from the point of view of the work? What is it that the work wishes to provide or is capable of providing? To meet this demand satisfactorily, you have to ignore the technology that the work used in the past as well as current organizational limitations(Rob06,ch04).
The easiest way to measure the size or functionality of the work area is to count the number of adjacent systems on the context model as well as the number of inputs and outputs.
While more accurate ways to measure size have been devised, counting the inputs and outputs is fast and gives you a far better idea of size than merely guessing. (Rob05, c3, p36)
If your context model has more than 30 inputs and outputs, then it falls into the “average cost per input/output” range of estimating.
A more accurate estimate comes from determining the number of business events that affect the work.
More accurate still is function point counting.
Function point counting measures the amount and the complexity of the data processed by the work—the inputs and the outputs from the context model — along with data stored within the work.