Title: 1. The Context of Software Engineering
11. The Context of Software Engineering
2Definition 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
3Definition 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
42. The Activities of Software Engineering
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
5Basic 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.
6Basic 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.
7The Four Ps 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.
8The Four Ps of Software Engineering
Process (the manner in which it is done)
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.
9The Four Ps of Software Engineering
People (by whom it is done)
Process (the manner in which it is done)
Project (the doing of it)
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
10The Four Ps of Software Engineering
People (by whom it is done)
Process (the manner in which it is done)
Project (the doing of it)
Product (the application artifacts)
Symbology from Ja1 explained in chapter 1
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
113. Process
12Set of activities carried out to produce an
application
Process(chapters 1 2)
Development sequence Waterfall Iterative
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
13Set of activities carried out to produce an
application
Process(chapters 1 2)
Development sequence Waterfall
Iterative Process frameworks Personal Software
ProcessSM Team Software ProcessSM Capability
Maturity ModelSM -- for organizations Standards
Institute of Electrical and Electronic Engineers
International Standards Organization ...
Graphics reproduced with permission from Corel.
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
143. Project
15Project
workflow
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.
16Project
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.
174. People5. Product
18Artifacts
- Product -- the application and
associated artifacts, including - Requirements (chapters 3 4)
- explain what product is meant to be
- Software architecture (chapter 5)
- Garland and Shaw's classification
- Detailed design (chapter 6)
Software Requirements Specification
Design model
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
19Artifacts
- Product -- the application,
- and associated artifacts, including
- Requirements (chapters 3 4)
- explain what product is meant to be
- Software architecture (chapter 5)
- use Garlan and Shaw's classification
- Detailed design (chapter 6)
- use the language of Design Patterns
- Implementation (chapter 7)
- emphasize standards
- employ selected formal methods.
- Test artifacts (chapters 8 and 9)
Software Requirements Specification
Design model
Source object code
?
?
Test procedures test cases
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
206. Quality
21Quality
- Application must satisfy predetermined standards.
- Methods to attain quality goals
- 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.
22Quality
- Application must satisfy predetermined quality
level. - Methods to attain quality level
- 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.
237. Student Team Project
24Decide Initial Team Issues
One way to ...
- 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. - Dont 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.
25Set Team Expectations
One way to ...
- 1. Get everyones 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 managers / instructors emphasis.
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
26Specify How the Team Will Communicate
One way to ...
- 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. ltname(s)gt 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.
278. Case Study Overview
28Sample 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.
29User 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.
30User Interface for Setting Quality Values
Current life points 100.0
Shawn
Image
Choose the quality you wish to set
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
OK
Graphics reproduced with permission from Corel.
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
31Engage Foreign Character Use Case
Details of use case
Encounter
1. System displays the foreign character in the
same area as the players. 2. System exchanges
data between the two characters. 3. System
displays the results of the engagement in a
message window. 4. Player dismisses window.
Initialize
player
Engage foreign character
Actor (agency external to the application)
Name of use case
. . . .
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
32FrameWork / 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.
33FrameWork / Application Dependency
Characters
GameEnvironment
RolePlayingGame
uses
Role-playing game layer (framework)
Encounter video game layer
EncounterGame
uses
uses
EncounterCast
EncounterGame
EncounterCharacters
EncounterEnvironment
by member classes implemen- ting framework
interfaces
EncounterEnvironment
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
34Homework
35Team 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.
36Team 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.
37Team 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.