Anda di halaman 1dari 37

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 Transition

Prelim. Iter. .. Iter. Iter. ….. Iter. Iter. ….. Iter.


iterations #1 #n #n+1 #m #m+1 #k

Requirements

People Process
Analysis

Design

Implemen-
tation

(the manner
Test

(by whom it is done) in which 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 Transition

Prelim. Iter. .. Iter. Iter. ….. Iter. Iter. ….. Iter.


iterations #1 #n #n+1 #m #m+1 #k

Requirements

People Process
Analysis

Design

Implemen-
tation

(the manner
Test

(by whom it is done) 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.
The Four “P’s” of Software Engineering
Unified Process Matrix

*
Jacobson et al: USDP
Inception Elaboration Construction Transition

Prelim. Iter. .. Iter. Iter. ….. Iter. Iter. ….. Iter.


iterations #1 #n #n+1 #m #m+1 #k

Requirements

People Process
Analysis

Design

Implemen-
tation

(the manner
Test

(by whom it is done) in which it is done)

Project Product
(the doing of it) (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.
3. Process
Process Set of activities carried out to
(chapters 1 & 2) produce an application

Unified Process Matrix


Jacobson et al: USDP

Development sequence:
Inception Elaboration Construction Transition

Prelim. Iter. .. Iter. Iter. ….. Iter. Iter. ….. Iter.


iterations #1 #n #n+1 #m #m+1 #k

Waterfall
Requirements

Analysis

Design

Iterative Implemen-
tation

Test

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Process Set of activities carried out to
(chapters 1 & 2) produce an application
Unified Process Matrix

Development sequence: Inception Elaboration Construction

Prelim. Iter. .. Iter. Iter. …..


Jacobson et al: USDP
Transition

Iter. Iter. ….. Iter.

Waterfall
iterations #1 #n #n+1 #m #m+1 #k

Requirements

Iterative
Analysis

Design

Implemen-

Process frameworks:
tation

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 workflow
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.
people flow of work
Project

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
Artifacts
Product -- the application and
associated artifacts, including:
• Requirements (chapters 3 & 4) Software
Requirements
• explain what product is meant to be Specification
• Software architecture (chapter 5)
• Garland and Shaw's classification
• Detailed design (chapter 6) Design
model

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Product -- the application, Artifacts
and associated artifacts, including:
• Requirements (chapters 3 & 4) Software
Requirements
Specification
explain what product is meant to be
• Software architecture (chapter 5)
use Garlan and Shaw's classification
• Detailed design (chapter 6) Design
model
use the language of Design Patterns
• Implementation (chapter 7)
emphasize standards Source &
employ selected formal methods. object code
• Test artifacts (chapters 8 and 9)  
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

dressing living
room 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 Choose the value of


you wish to set the quality selected

16.3

image

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
User Interface
Shawn Current life points: 100.0 for Setting
Quality Values
Choose the quality Image Choose the value of
you wish to set 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
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel.
Engage Foreign Character Use Case
Details of use case

Encounter 1. System displays the


foreign character in the
Initialize same area as the
player’s.
player
2. System exchanges data
Actor Engage between the two
(agency foreign characters.
external character
to the 3. System displays the
applicati results of the
Name of use case
on) 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

Role-playing game layer (framework) «uses»

Encounter video game layer


«uses»* EncounterGame
«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.
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:
Clarity (A = very clearly written, with all salient
points explained and negligible redundancy)
Specificity (A = specific procedures as to how the
team will communicate under most conceivable
circumstances)
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.

Anda mungkin juga menyukai