1. The Context of Software Engineering - PowerPoint PPT Presentation

1 / 37
About This Presentation
Title:

1. The Context of Software Engineering

Description:

a knowledge of the mathematical and natural sciences gained by study, experience, ... Symbology from [Ja1]; explained in chapter 1 ... – PowerPoint PPT presentation

Number of Views:61
Avg rating:3.0/5.0
Slides: 38
Provided by: bost55
Category:

less

Transcript and Presenter's Notes

Title: 1. The Context of Software Engineering


1
1. The Context of Software Engineering
2
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
3
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
4
2. The Activities of Software Engineering
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
5
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.
6
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.
7
The 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.
8
The 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.
9
The 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.
10
The 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.
11
3. Process
12
Set 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.
13
Set 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.
14
3. Project
15
Project
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.
16
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.
17
4. People5. Product
18
Artifacts
  • 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.
19
Artifacts
  • 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.
20
6. Quality
21
Quality
  • 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.
22
Quality
  • 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.
23
7. Student Team Project
24
Decide 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.
25
Set 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.
26
Specify 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.
27
8. Case Study Overview
28
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.
29
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.
30
User 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.
31
Engage 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.
32
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.
33
FrameWork / 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.
34
Homework
35
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.
36
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.
37
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.
Write a Comment
User Comments (0)
About PowerShow.com