Instances
An instance represents a phenomenon.
The name of an instance is underlined and can
contain the class of the instance.
The attributes are represented with their values.
tariff_1974:TariffSchedule
zone2price = {
{‘1’, .20},
{‘2’, .40},
{‘3’, .60}}
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
1
Associations
Associations denote relationships between classes.
The multiplicity of an association end denotes how
many objects the source object can legitimately
reference.
Has-capital
Country
name:String
Polygon
draw()
February 11, 2014
1
1
1-to-1
association
1
*
1-to-many
association
CS410 – Software Engineering
Lecture #5: Project Management
City
name:String
Point
x:Integer
y:Integer
2
Class Diagrams
Example: Class diagram for a simple watch.
SimpleWatch
1
2
PushButton
1
Display
1
1
1
2
Battery
1
Time
The numbers on the ends of associations indicate the
number of links that each object has with an object of
a given class.
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
3
Aggregation
An aggregation is a special case of association
denoting a “consists of” hierarchy.
The aggregate is the parent class, the components
are the children class.
Exhaust System
1
Muffler
February 11, 2014
0..2
Tailpipe
CS410 – Software Engineering
Lecture #5: Project Management
4
Generalization
Generalization relationships denote inheritance
between classes.
The child classes inherit the attributes and
operations of the parent class.
Generalization simplifies the model by eliminating
redundancy.
Button
CancelButton
February 11, 2014
ZoneButton
CS410 – Software Engineering
Lecture #5: Project Management
5
Class Diagram Example
MapSite
Enter()
Maze
AddRoom()
RoomNo()
February 11, 2014
Room
1..n
Wall
roomNum
Door
isOpen
SetSide()
GetSide()
CS410 – Software Engineering
Lecture #5: Project Management
6
Sequence Diagrams
Sequence diagrams show the communication among
objects.
The objects involved in a use case are called
participating objects.
A sequence diagram represents the interactions that
take place among these objects.
In a sequence diagram,
• columns represent timelines of actors and objects,
• labeled arrows represent stimuli (messages) that
are sent from an actor to an object or between
objects.
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
7
Sequence Diagrams
Example: Sequence diagram for the SetTime use case.
:SimpleWatch
:Display
:Time
:WatchUser
pressButton1()
blinkHours()
pressButton1()
blinkMinutes()
pressButton2()
incrementMinutes()
refresh()
pressButtons1And2()
commitNewTime()
stopBlinking()
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
8
Sequence Diagrams
Used during requirements analysis
• to refine use case descriptions,
• to find additional objects (“participating objects”)
Used during system design to refine subsystem
interfaces.
Classes are represented by columns
Messages are represented by arrows
Activations are represented by narrow rectangles
Lifelines are represented by dashed lines
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
9
Sequence Diagram Observations
• UML sequence diagrams represent behavior in terms
of interactions.
• Complement the class diagrams which represent
structure.
• Useful to find participating objects.
• Time consuming to build but worth the investment.
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
10
Statechart Diagrams
Statechart diagrams describe the behavior of an
individual object like a finite state automaton, that is,
• a finite number of states that the object can
assume,
• transitions between these states.
Here, a state is a particular set of values for an object.
States are represented by ovals.
A transition represents a state change that occurs
under a particular condition.
Transitions are represented by arrows that are labeled
with the corresponding condition.
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
11
Statechart Diagrams
Example: Statechart diagram for SimpleWatch.
button2Pressed
button1&2Pressed
BlinkHours
IncrementHours
button1Pressed
button2Pressed
button1&2Pressed
BlinkMinutes
button1&2Pressed
IncrementMinutes
button1Pressed
button2Pressed
StopBlinking
February 11, 2014
BlinkSeconds
CS410 – Software Engineering
Lecture #5: Project Management
IncrementSeconds
12
Activity Diagrams
An activity diagram describes a system in terms of
activities.
Activities are shown as states that represent the
execution of a set of operations.
After the completion of one or more activities, other
activities are started.
Activity diagrams are similar to flowchart diagrams.
They represent activities as ovals and transitions
between activities as arrows.
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
13
Activity Diagrams
Example: Activity diagram for incident management
Allocate
Resources
Open
Incident
Coordinate
Resources
Archive
Incident
Document
Incident
Thick bars represent the synchronization of the
control flow.
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
14
Systems, Models, and Views
A system is a structured set of interacting parts that
serve a specific purpose.
For example, a humanoid robot consists of a torso, a
head, two arms and two legs.
These parts can in turn be considered subsystems.
For instance, the robot’s head may be composed of a
metal frame, two cameras, two microphones, and a
speaker.
We can apply this decomposition recursively to
determine the hierarchy of subsystems.
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
15
Systems, Models, and Views
Modeling is a way of dealing with the high complexity
of certain systems.
Such systems are often described by multiple
models, each of them representing a particular aspect
of the system.
In general, a model focuses on particular aspects of a
system and ignores irrelevant details.
We should aim at building models that are simple
enough to be easily comprehensible by a single
person.
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
16
Systems, Models, and Views
We can use a view to visualize a subset of a model.
UMass Boston
Department of Computer Science
Department of
Psychology
Students
Classes
Faculty
Example: View of a subset of UMass Boston
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
17
Concepts and Phenomena
A phenomenon is an object of the world as it is
perceived, for example:
• Classroom M-1-409
• Professor Jun Suzuki
• September 5
A concept is an abstraction describing a set of
phenomena, for instance:
• Classrooms
• UMass professors
• Dates
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
18
Concepts and Phenomena
A concept is defined as a three-tuple:
• its name (identifying the concept),
• its purpose (the properties determining if a
phenomenon is part of the concept or not),
• its members (the set of phenomena that are part of
the concept).
Example:
• University is the name of the concept.
• Educating students is the purpose of a university.
• UMass Boston and York University are members
of the university concept.
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
19
Software Project Management
Software Project:
• All technical and managerial activities
required to deliver the deliverables to the client.
• A software project has a specific duration,
consumes resources and produces work
products.
• Management categories to complete a software
project: Tasks, Activities, Functions
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
20
Software Project Management
Software Project Management Plan (SPMP):
• The controlling document for a software project.
• Specifies the technical and managerial
approaches to develop the software product.
• Companion document to requirements analysis
document: Changes in either may imply
changes in the other document.
• SPMP may be part of project agreement.
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
21
Project Agreement
Document written for a client that defines
• the scope, duration, cost and deliverables for the
project,
• the exact items, quantities, delivery dates,
delivery location.
Can be a contract, a statement of work, a business
plan, or a project charter.
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
22
Project Agreement
Client: Individual or organization that specifies the
requirements and accepts the project
deliverables.
Deliverables (= Work Products that will be
delivered to the client):
• Documents
• Demonstrations of function
• Demonstration of nonfunctional requirements
• Demonstrations of subsystems
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
23
Project: Functions, Activities and Tasks
f1:Function
p:Project
f2:Function
a1:Activity
a2.1:Activity
t1:Task
February 11, 2014
a2:Activity
a2.2:Activity
t2:Task
t3:Task
CS410 – Software Engineering
Lecture #5: Project Management
a3:Activity
a2.3:Activity
t4:Task
24
Functions
A function is an activity or a set of activities that
span the duration of the project.
f1:Function
p:Project
f2:Function
a1:Activity
a2.1:Activity
t1:Task
February 11, 2014
a2:Activity
a2.2:Activity
t2:Task
t3:Task
CS410 – Software Engineering
Lecture #5: Project Management
a3:Activity
a2.3:Activity
t4:Task
25
Functions
Examples:
•
•
•
•
•
Project management
Configuration management
Documentation
Quality control (verification and validation)
Training
Mapping of terms: Project Functions in the IEEE
1058 standard are called Integral processes in the
IEEE 1074 standard. We call them crossdevelopment processes.
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
26
Tasks
Smallest units of work that are subject to management
f1:Function
p:Project
f2:Function
a1:Activity
a2.1:Activity
t1:Task
February 11, 2014
a2:Activity
a2.2:Activity
t2:Task
t3:Task
CS410 – Software Engineering
Lecture #5: Project Management
a3:Activity
a2.3:Activity
t4:Task
27
Tasks
Tasks are
• the smallest units of management accountability,
• atomic units of planning and tracking
They should be
• small enough for adequate planning and tracking,
• large enough to avoid micro management.
Properties of tasks:
• finite duration
• need resources
• produce tangible results (e.g., documents or code)
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
28
Tasks
Specification of a task: Work package
• name,
• description of work to be done,
• preconditions for starting,
• duration,
• required resources,
• work product to be produced and acceptance
criteria for it,
• risk involved,
• completion criteria
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
29
Task Sizes
Finding the appropriate task size is problematic,
because:
• During initial planning a task is necessarily large.
• You may not know how to decompose the
problem into tasks at first.
• Each software development activity identifies
more tasks and modifies existing ones.
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
30
Task Sizes
• Tasks must be decomposed into sizes that allow
monitoring.
• Work package usually corresponds to well
defined work assignment for one worker for a
week or a month.
• Depends on nature of work and how well task is
understood.
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
31
Examples of Tasks
•
•
•
•
•
•
•
Unit test class “Foo”
Test subsystem “Bar”
Write user manual
Write meeting minutes and post them
Write a memo on Windows 7 vs. Unix
Schedule the code review
Develop the project plan
Related tasks are grouped into hierarchical sets
of functions and activities.
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
32
Activities
Activities are major units of work with precise dates.
f1:Function
p:Project
f2:Function
a1:Activity
a2.1:Activity
t1:Task
February 11, 2014
a2:Activity
a2.2:Activity
t2:Task
t3:Task
CS410 – Software Engineering
Lecture #5: Project Management
a3:Activity
a2.3:Activity
t4:Task
33
Activities
An activity
• consists of smaller activities or tasks,
• usually culminates in a major project milestone.
A milestone is
• An internal checkpoint that should not be
externally visible,
• a scheduled event used to measure progress.
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
34
Activities
Activities may be grouped into larger activities:
• Establishes hierarchical structure for project
(phase, step, ...)
• Allows separation of concerns
• Precedence relations often exist among activities
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
35
Examples of Activities
Major activities:
• Planning
• Requirements
Elicitation
• Requirements Analysis
• System Design
• Object Design
• Implementation
• System Testing
• Delivery
February 11, 2014
Activities during
requirements analysis:
• Refine scenarios
• Define Use Case model
• Define object model
• Define dynamic model
• Design User Interface
CS410 – Software Engineering
Lecture #5: Project Management
36
Project Roles
•
•
•
•
•
•
•
•
•
•
Planner
Analyst
Designer
Programmer
Tester
Maintainer
Trainer
Document Editor
Web Master
Configuration
Manager
February 11, 2014
•
•
•
•
Group leader
Liaison
Minute Taker
Project Manager
CS410 – Software Engineering
Lecture #5: Project Management
37
Project Roles
Management roles:
• Organization and execution of the project within
constraints.
• Examples: project manager, team leader
Development roles:
• Specification, design and construction of
subsystems.
• Examples: Analyst, system architect,
implementor.
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
38
Project Roles
Cross-functional roles:
• Coordination of more than one team.
• Examples: API Engineer, configuration manager,
tester
Consultant roles:
• Support in areas where the project participants
lack expertise.
• Examples: End user, client, application domain
specialist (problem domain), technical consultant
(solution domain).
Promoter roles:
• Promote change through an organization.
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
39
Hierarchical Project Organization
Chief Executive
First Level Manager
(“Front-Line Manager”)
A
B
Project Members
A wants to talk to B: complicated information flow
A wants to make sure B does a certain change:
complicated control flow
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
40
Example: Chief Programmer Team
Chief Programmer
Assistant
Chief Programmer
Senior Programmer
Librarian
Administration
Tester
Junior Programmer
February 11, 2014
CS410 – Software Engineering
Lecture #5: Project Management
41
Another Project Organization:
Egoless Programming Team
Analyst
Tester
Programmer
Designer
February 11, 2014
Librarian
CS410 – Software Engineering
Lecture #5: Project Management
42