Content deleted Content added
Radagast83 (talk | contribs) mNo edit summary |
KaiserbBot (talk | contribs) m clean up using AWB |
||
Line 8:
In Figure 2 2 an example from practice is illustrated. The example is taken from the requirements capturing workflow in UML-based Web Engineering. The main activity, user & ___domain modeling, consists of three activities that need to be carried out in a predefined order.
====Unordered activities====
Line 17 ⟶ 16:
In some specific cases an activity exists of sequential and unordered activities. The solution to this modeling issue is to divide the main activity in different parts. In Figure 2-4 an example is illustrated, which clarifies the necessity to be able to model unordered activities. The example is taken from the requirements analysis workflow of the Unified Process. The main activity, “describe candidate requirements”, is divided into two parts. The first part is a sequential activity. The second part consists of four activities that do not need any sequence in order to be carried out correctly.
====Concurrent activities====
Activities can occur concurrently. This is handled with forking and joining. By drawing the activities parallel in the diagram, connected with a synchronization bar, one can fork several activities. Later on these concurrent activities can join again by using the same synchronization bar. Both activities and sub-activities van occur concurrently. In the example of Figure 2-5, Activity 2 and Activity 3 are concurrent activities.
[[Image:Mm25.gif|frame|left|Figure 2-5: Concurrent activities]]
Line 27 ⟶ 24:
In Figure 2-6, a fragment of a requirements capturing process is depicted. Two activities, defining the actors and defining the use cases, are carried out concurrently. The reason for carrying out these activities concurrently is that defining the actors and the use cases influences each other to a high extend.
====Conditional activities====
Line 40 ⟶ 36:
The meta-data side of the diagram consists of a concept diagram. This is basically an adjusted class diagram as described Booch, Rumbaugh and Jacobson (1999). Important notions are concept, generalization, association, multiplicity and aggregation.
====Concepts====
Line 58 ⟶ 53:
In Figure 3-2 all three concept types are exemplified. Part of the process-data diagram of the requirements workflow in the Unified Process is illustrated. The USE CASE MODEL is an open concept and consists of one or more ACTORS and one or more USE CASES. ACTOR is a standard concept, it contains no further sub-concepts. USE CASE, however, is a closed concept. A USE CASE consists of a description, a flow of events, conditions, special requirements, etc. Because in this case it is unnecessary to reveal that information, the USE CASE is illustrated with a closed concept.
====Generalization====
Line 67 ⟶ 61:
In Figure 3-4 generalization is exemplified by showing the relationships between the different concepts described in the preceding paragraph. STANDARD CONCEPT and COMPLEX CONCEPT are both a specific kind of CONCEPT. Subsequently, a COMPLEX CONCEPT can be specified into an OPEN CONCEPT and a CLOSED CONCEPT.
====Association====
Line 76 ⟶ 69:
In Figure 3-6 an example of association is illustrated. The example is a fragment of the process-data diagram of the requirements analysis in the Unified Process. Because both concepts are not expanded any further, although several sub concepts exist, the concepts are illustrated as closed concepts. The figure reads as “SURVEY DESCRIPTION describes USE CASE MODEL”.
====Multiplicity====
Line 85 ⟶ 77:
An example of multiplicity is represented in Figure 3-8. It is the same example as in Figure 3-6, only the multiplicity values are added. The figure reads as ‘exactly one SURVEY DESCRIPTION describes exactly one USE CASE MODEL’. This implies that a SURVEY DESCRIPTION cannot describe zero or more than one USE CASE MODEL and a USE CASE MODEL cannot be described by zero or more than one SURVEY DESCRIPTIONS.
====Aggregation====
Line 94 ⟶ 85:
In Figure 3-10 aggregation is exemplified by a fragment of the requirements capture workflow in UML-Based Web Engineering. A USE CASE MODEL consists of one or more ACTORS and USE CASES.
====Properties====
Line 106 ⟶ 96:
In Table 3-1 a list presented Each CONCEPT requires a proper definition which is preferably copied from a standard glossary. All CONCEPT names in the text are with capital characters.
{| class="wikitable"
|- bgcolor="#ccccff"
Line 112 ⟶ 102:
|'''Definition'''
|-
|
|This is a definition of CONCEPT A
|-
|
|This is a definition of CONCEPT B
|-
Line 128 ⟶ 118:
In Table 4-1 a generic table is presented with the description of activities, sub-activities and their relations to the concepts. In section 5 examples are given of both process-data diagram and activity table.
{| class="wikitable"
|- bgcolor="#ccccff"
Line 135 ⟶ 125:
|'''Description'''
|-
|
|Sub-activity 4
|Sub-activity 4 results in a STANDARD CONCEPT
Line 151 ⟶ 141:
In Table 5-1 the activities and sub-activities, and relation to the concepts are described.
{| class="wikitable"
|- bgcolor="#ccccff"
Line 158 ⟶ 148:
|'''Description'''
|-valign="top"
|
|
|Describing the project is done in terms of participants, targets, products, scope and assumptions. This information is derived from the proposal, but with more emphasis on the project management issues. The activity end in a project DESCRIPTION.
|-valign="top"
|
|Describe project phases
|The PLANNING is divided into five PROJECT PHASES, which should be shortly described.
|-valign="top"
|
|Describe activities
|The project ACTIVITIES are described and grouped into PROJECT PHASES.
|-valign="top"
|
|Describe deliverables
|The DELIVERABLES that result from the project ACTIVITIES are described.
|-valign="top"
|
|Set up schedule
|For every DELIVERABLE a DATE is set and for each ACTIVITY a TIME SLOT is estimated.
|-valign="top"
|
|
|Controlling the project results in a CONTROL MANAGEMENT artifact. This artifact is not further explained here, since it concerns regular project management issues, like communication management, progress management, change management and problem management that lie outside the scope of this research.
|-valign="top"
|
|Identify risks
|Identifying risks can be done by using standard checklists or organizing risk workshops. The RISKS are included in the PROJECT PLAN.
|-valign="top"
|
|Evaluate risks
|Every RISK is provided with an EVALUATION; a description and estimation about the complexity or uncertainty of a project is given.
|-valign="top"
|
|Analyze impact
|Analyzing the impact of a risk handles about the IMPACT, a risk has on the success of a project. The evaluation and risk values are indicated by selecting a value: low, moderate or high.
|-valign="top"
|
|Prioritize risks
|Prioritizing the risks is done by combining IMPACT and EVALUATION in a table. High priority is then given to RISKS with the highest scores.
|-valign="top"
|
|
|Risk strategy actions can be obtained from experience or from relevant literature. The project manager adapts the actions to the project in the ACTION LIST FOR RISK STRATEGY. RISKS with the highest priority are on top of the list and need to be handled first.
| |||