1. The Context of Software
Engineering
Definition of “Engineering”
The profession in which
a knowledge of the mathematical and natural
sciences gained by study, experience, and
practice
…...
-- Accreditation Board for Engineering and Technology
Definition of “Engineering”
The profession in which
a knowledge of the mathematical and natural
sciences gained by study, experience, and
practice
is applied with judgment
to develop ways to utilize, economically, the
materials and forces of nature for the benefit of
mankind
-- Accreditation Board for Engineering and Technology, 1996
2. The Activities of Software
Engineering
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Basic Activities of Software Engineering 1/2
 defining the software development
process to be used
 chapter 1
 managing the development project
 introduced in chapter 2; also referenced in the
remaining chapters
 describing the intended software product
 chapters 3 and 4
 designing the product
 chapters 5 and 6
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Basic Activities of Software Engineering 2/2
 implementing the product
i.e. programming it
 chapter 7
 testing the parts of the product
 chapter 8
 integrating the parts
and testing them as a whole
 chapter 9
 maintaining the product
 chapter 10
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
The Four “P’s” of Software Engineering
*
People
(by whom it is done)
* Symbology from [Ja1]; explained in chapter 1
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
The Four “P’s” of Software Engineering
Unified Process Matrix
Jacobson et al: USDP
*
Inception Elaboration
Construction
Prelim. Iter. .. Iter. Iter.
iterations #1
#n #n+1
…..
Iter.
#m
Transition
Iter. …..
#m+1
Iter.
#k
Requirements
People
Process
(by whom it is done)
(the manner
in which it is done)
Analysis
Design
Implementation
Test
* Symbology from [Ja1]; explained in chapter 1
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
The Four “P’s” of Software Engineering
Unified Process Matrix
Jacobson et al: USDP
*
Inception Elaboration
Construction
Prelim. Iter. .. Iter. Iter.
iterations #1
#n #n+1
Requirements
People
Process
(by whom it is done)
(the manner
in which it is done)
Analysis
Design
Implementation
Test
Project
(the doing of it)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
…..
Iter.
#m
Transition
Iter. …..
#m+1
Iter.
#k
The Four “P’s” of Software Engineering
Unified Process Matrix
Jacobson et al: USDP
*
Inception Elaboration
Construction
Prelim. Iter. .. Iter. Iter.
iterations #1
#n #n+1
…..
Iter.
#m
Transition
Iter. …..
#m+1
Iter.
#k
Requirements
People
Process
(by whom it is done)
(the manner
in which it is done)
Project
Product
(the doing of it)
(the application artifacts)
Analysis
Design
Implementation
Test
* Symbology from [Ja1]; explained in chapter 1
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
3. Process
Process
(chapters 1 & 2)
Set of activities carried out to
produce an application
Unified Process Matrix
Jacobson et al: USDP
Inception Elaboration
Development sequence:
Waterfall
Iterative
Construction
Prelim. Iter. .. Iter. Iter.
iterations #1
#n #n+1
Requirements
Analysis
Design
Implementation
Test
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
…..
Iter.
#m
Transition
Iter. …..
#m+1
Iter.
#k
Process
(chapters 1 & 2)
Set of activities carried out to
produce an application
Unified Process Matrix
Development sequence:
Waterfall
Iterative
Process frameworks:
Jacobson et al: USDP
Inception Elaboration
Construction
Prelim. Iter. .. Iter. Iter.
iterations #1
#n #n+1
…..
Iter.
#m
Transition
Iter. …..
#m+1
Iter.
#k
Requirements
Analysis
Design
Implementation
Test
Personal Software ProcessSM
Team Software ProcessSM
Capability Maturity ModelSM
-- for organizations
Standards:
Institute of Electrical and Electronic Engineers
International Standards Organization
...
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel.
3. Project
Project
people
Set of activities carried out
to produce an application
• OO: very useful paradigm
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
workflow
Project
people
flow of work
Set of activities carried out
to produce an application
• Object Orientation: very useful paradigm
• Unified Modeling Language: design notation
• Legacy systems: common starting point
• enhancement or usage of existing system
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
4. People
5. Product
Product -- the application and
Artifacts
associated
artifacts, including:
• Requirements (chapters 3 & 4)
• explain what product is meant to be
Software
Requirements
Specification
• Software architecture (chapter 5)
• Garland and Shaw's classification
• Detailed design (chapter 6)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Design
model
Artifacts
Product -- the application,
and associated artifacts, including:
• Requirements (chapters 3 & 4)
explain what product is meant to be
Software
Requirements
Specification
• Software architecture (chapter 5)
use Garlan and Shaw's classification
• Detailed design (chapter 6)
use the language of Design Patterns
Design
model
• Implementation (chapter 7)
emphasize standards
employ selected formal methods.
• Test artifacts (chapters 8 and 9)
Source &
object code


Test procedures; test cases
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
6. Quality
Application must satisfy predetermined standards.
Methods to attain quality goals:
Quality
• Inspection (introduced in chapter 1)
• team-oriented process for ensuring quality
• applied to all stages of the process.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Application must satisfy predetermined quality level.
Methods to attain quality level:
Quality
• Inspection (introduced in chapter 1)
• team-oriented process for ensuring quality
• applied to all stages of the process.
• Formal methods (introduced in chapter 1)
• mathematical techniques to convince ourselves and
peers that our programs do what they are meant to do
• applied selectively
• Testing
• at the unit (component) level (chapter 8)
• at the whole application level (chapter 9)
• Project control techniques (chapter 2)
• predict costs and schedule
• control artifacts (versions, scope etc.)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
7. Student Team Project
Decide Initial Team Issues
0. Set the meeting agenda and time limits.
(chapters 1 and 2 cover this is more detail)
1. Choose the team leader.
2. Decide how the team will communicate.
See figure tbd.
3. Identify the customer.
The party or parties who want this application.
4. Get an understanding of the project in
general terms.
Don’t be embarrassed if project seems too vague
to you. Probe until you are comfortable.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Set Team Expectations
1. Get everyone’s commitment to taking required time
– Define an expected average number of hours per week
– If not forthcoming:
Industrial: alert management
Academic: inform instructor; implement written mutual evaluations
– Gather dates of planned absences
2. Choose team emphasis: accomplishment / learning
– Accomplishment (capable product): get a good mix of
leadership, technical, writing, customer relations
– Learning: sacrifice accomplishment by allowing members to
experience new activities.
– Understand manager’s / instructor’s emphasis.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Specify How the Team Will Communicate
1. General policy: if in doubt, communicate. Redundancy is OK!
2. Meeting: The team will meet each Wednesday from 8 a.m. to 10 a.m. in
room 671, unless notified of a change.
3. Meeting alternative: Team members should keep Mondays 4 to 6pm open
in case an additional meeting is required.
4. Standards: The word processing used will be Ajax release 9. e-mail should
be via BestMail release 4 -- if this is not possible, the e-mail should be
verified as being compatible, especially for attachments.
5. Preferred mode of electronic communication: Unless a communication is of
very limited interest to the group, it should be posted to the group site,
www.xxx.yyy with automatic notification to every member. The “subject”
format should be Attn. <name(s)>: subject matter.
6. Alternative mode of electronic communication: For 1-1 communication of
very limited group interest, members will use e-mail and/or telephone.
7. Acknowledgement: Team members should acknowledge all electronic
communication specifically targeted to them, whether asked to
acknowledge or not. Senders should follow up on all significant
communication that is not acknowledged.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
8. Case Study Overview
Sample Encounter
Screen
kitchen
COURTYARD
living
room
dressing
room
Get status
Set qualities
Graphics reproduced with permission from Corel.
End game
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
User Interface for Setting Quality Values
Shawn
Current life points: 100.0
Choose the quality
you wish to set
Choose the value of
the quality selected
16.3
image
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Shawn
Current life points: 100.0
Choose the quality
you wish to set
Image
User Interface
for Setting
Quality Values
Choose the value of
the quality selected
16.3
Explanation
The values of the qualities not specifically chosen remain in the same
proportion to each other. Values less than 1.0 are counted as zero. E.g.,
before: strength = 10.0, endurance = 60.0, intelligence = 30.0, patience = 0.0
(current life points 10.0 + 60.0 + 30.0 + 0 = 100.0)
change: strength from 10.0 to 20.0
after:
strength = 20, endurance = 53.33, intelligence = 26.66
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
OK
Graphics reproduced with permission from Corel.
Engage Foreign Character Use Case
Details of use case
Encounter
Initialize
player
Actor
(agency
external
to the
applicati
on)
Engage
foreign
character
Name of use case
....
1. System displays the
foreign character in the
same area as the
player’s.
2. System exchanges data
between the two
characters.
3. System displays the
results of the
engagement in a
message window.
4. Player dismisses
window.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
FrameWork / Application Dependency
Role-playing game layer
Encounter video game layer
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
FrameWork / Application Dependency
Characters
GameEnvironment
RolePlayingGame
«uses»
Role-playing game layer (framework)
Encounter video game layer
«uses»*
«uses»
EncounterCast
EncounterCharacters
* by member classes implementing framework interfaces
EncounterGame
EncounterGame
EncounterEnvironment
EncounterEnvironment
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Homework
Team exercises (Title: "Communication")
For the following exercises, consider as a group how
you will perform it, check the hints below, then carry
out the assignment.
T1h Decide who your team leader(s) will be. Note that
being team leader provides you with practice that you
may otherwise be hard to get.
T2h Decide how your team will communicate, and test
your communication methods. Specify your
communication tools and methods. Be specific: you
may change the specifics later.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Team exercises (Title: "Communication") ctd.
T2h Decide how your team will communicate, and test
your communication methods. Specify your
communication tools and methods. Be specific: you may
change the specifics later.
T3h Search the Web for the latest information on a topic
determined by the instructor (e.g., the TSP). Note at least
four of its basic goals and at least five of the techniques it
uses. Post the references to the course forum or web site
if there is one, and annotate your posting with the name
of your group. State individual and/or group opinions of
the topic or issue.
Your team response should be 4-7 pages long.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Team exercises (Title: "Communication") ctd.
Evaluation criteria:
a. Clarity (A = very clearly written, with all salient
points explained and negligible redundancy)
b. Specificity (A = specific procedures as to how the
team will communicate under most conceivable
circumstances)
g. Soundness of your topic summary (A = very clear
that the writer understands the goals of the Team
Software Process; posting clearly organized)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.