Why Study Software Engineering

1
Why Study Software Engineering

• An air traffic controller, relying on information
  from his computer console, directs two Boeing
  747's onto intersecting paths. The jets collide
  and burst into flame, and all aboard perish. --
  Washington Post 
• "Software Gone Awry", Scientific American,
  October 1996 --Investigators appointed by the
  European Space Agency reported in July that a
  software bug brought down the new 8-billion
  Ariane 5 rocket. 
• A hospital minicomputer, monitoring a patient
  recovering from surgery, fails to alert hospital
  staff that the patient is having a stroke. The
  patient dies. -- Washington Post 
• "Computer bug bites Alberta exchange", Calgary
  Herald, October 24, 1996 -- The Alberta Stock
  Exchange crashed at 738 a.m. Wednesday, brought
  down by a glitch in its new, fully computerized
  trading system.
• A company dicovers that its computer has mangled
  valuable and sensitive information beyond
  recovery. The loss gravely weakens the company's
  market position. -- Washington Post 
• Also see http//www5.in.tum.de/huckle/bugse.htm
  l

2
1. The Context of Software Engineering
Science
Engineering
Software Engineering
Computer Science
3
What is 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
What is Software Engineering?

• Software engineering (SE) is "the establishment
  and use of sound engineering principles in order
  to obtain, economically, software that is
  reliable and works efficiently on real machines"
  Fritz Bauer at the seminal conference on SE,
  1969
• SE lies on the middle-ground between computer
  science and industry application

5
2. Activities of Software Engineering

• defining the software development process to be
  used (ch.1)
• managing the development project (ch.2 and
  throughput)
• describing the intended software product (ch.
  3,4)
• designing the product (ch.5, 6)
• implementing (programming) the product (ch. 7)
• testing the parts of the product (ch. 8)
• integrating the parts and testing them as a whole
  (ch. 9)
• maintaining the product (ch. 10)

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
6
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.
7
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.
8
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.
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)
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.
10
3. Process

• Set of activities carried out to
• produce an application

11
Set of activities carried out to produce an
application
Process (ch.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
(IEEE) International Standards Organization
(ISO) Canadian Information Processing Society
(CIPS)
Graphics reproduced with permission from Corel.
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
12
3. Project

• Set of activities required to
• to produce the desired artifacts

13
Project
people
flow of work

• Set of activities required to
• to produce the desired artifacts
• Object Orientation very useful paradigm
• Unified Modeling Language design notation
• Legacy systems common starting point
• replacement of, enhancement or addition to
  existing system

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
14
4. People

• The most challenging part
• of any project

15
People

• A small software project can be done by one
  person
• Large software projects require teams
• Interactions between people necessary, but
  difficult
• Managers, analysts, programmers, testers, users,
  customers
• We will learn certain skills
• Project Management
• Effective Meetings
• Presentations
• Technical documentation
• Technical Reviews
• Your project work will provide practical hand-on
  experience

16
5. Product

• The software application and associated project
  artifacts

17
Artifacts

• Product -- the application and
• associated artifacts, including
• Requirements (ch. 3,4)
• Specifies what the product must do
• Software architecture (ch. 5)
• Single user, network centric, database?
• Detailed design (ch. 6)
• Describes how the product will work
• Implementation (ch. 7)
• Emphasizes standards
  
• Employs selected coding methods
• Test artifacts (ch. 8,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.
18
6. Quality

• A software application must satisfy a
  predetermined level of quality

19
Methods to attain desired level of quality

• Inspection (ch.1)
• team-oriented process for ensuring quality
• applied to all stages of the process
• Formal methods (ch.1)
• mathematical checks to ensure programs do what
  they are meant to do
• Testing
• at the unit (component) level (ch. 8)
• at the whole application level (ch.9)
• Project control techniques (ch.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.
20
What are the key challenges facing software
engineering?

• Legacy systems
• Old but valuable (mission critical) systems must
  be maintained and updated
• Increasing diversity heterogeneity
• Systems are distributed and include a mix of
  hardware and software
• Demands for reduced delivery times
• There is increasing pressure for faster delivery
  of software

21
Professional and Ethical responsibility

• SE involves wider responsibilities than simply
  the application of technical skills
• SEs must behave in an honest and ethically
  responsible way if they are to be respected as
  professionals
• Ethical behaviour should be gt legal
  responsibility
• Confidentiality - respect the confidentiality and
  intellectual property of their employers or
  clients
• Competence - do not misrepresent level of
  competence or accept work beyond ability to
  deliver

22
Ethical dilemmas you may encounter

• Disagreement in principle with the policies of
  senior management
• Your employer acts in an unethical way and
  releases a safety-critical system without
  finishing the testing of the system
• Participation in the development of components
  for military weapons or biogenetic systems

23
ACM/IEEE Code of Ethics

• Eight Principles related to the behaviour of and
  decisions made by professional software
  engineers, including practitioners, educators,
  managers, supervisors and policy makers, as well
  as trainees and students of the profession.
• Preamble
• Software engineers shall commit themselves to
  making the analysis, specification, design,
  development, testing and maintenance of software
  a beneficial and respected profession. In
  accordance with their commitment to the health,
  safety and welfare of the public, software
  engineers shall adhere to the following Eight
  Principles

24
ACM/IEEE Code of ethics - principles

• PUBLIC - Software engineers shall act
  consistently with the public interest.
• CLIENT AND EMPLOYER - Software engineers shall
  act in a manner that is in the best interests of
  their client and employer consistent with the
  public interest.
• PRODUCT - Software engineers shall ensure that
  their products and related modifications meet the
  highest professional standards possible.
• JUDGMENT- Software engineers shall maintain
  integrity and independence in their professional
  judgment.
• MANAGEMENT - Software engineering managers and
  leaders shall subscribe to and promote an ethical
  approach to the management of software
  development and maintenance.
• PROFESSION - Software engineers shall advance the
  integrity and reputation of the profession
  consistent with the public interest.
• COLLEAGUES - Software engineers shall be fair to
  and supportive of their colleagues.
• SELF - Software engineers shall participate in
  lifelong learning regarding the practice of their
  profession and shall promote an ethical approach
  to the practice of the profession.

25
7. Student Team Project
26
Decide Initial Team Issues
One way to ...

• 0. Set the meeting agenda and time limits.
• (see ch.1, 2)
• 1. Choose the team leader.
• 2. Decide how the team will communicate.
• 3. Identify the customer
• 4. Get an understanding of the project in general
  terms - dont be embarrassed if project seems
  too vague, probe until you are comfortable.

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
27
Set Team Expectations
One way to ...

• 1. Get everyones commitment to taking required
  time
• Define an expected average number of hours per
  week
• Gather dates of planned absences
• If not forthcoming - alert management, inform
  instructor implement written mutual evaluations
• 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.
28
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 MS
  Word.
• 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, axe.acadiau.ca with notification to
  all members.
• 6. Alternative mode of electronic communication
  For 1-1 communication of very limited group
  interest, members will use MSN 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.
29
8. Case Study Overview
30
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.
31
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.
32
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.
33
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.
34
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.
35
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.