The Activities of Software Engineering

1
The Activities of Software Engineering

• GA Tech CS 3300
• Fall 2002

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

• The Four Ps of Software Engineering
• Process
• People
• Project
• Product
• Quality
• Project Work
• Domains
• Projects
• Teams
• One Way To Get Started

Non-Contents Assignments and Project deadlines.
(Next Tuesday)
3
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.
4
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.
5
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.
6
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.
7
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.
8
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.
9
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.
10
Domains, Projects and Teams
Domain
Utility team
Project
Team
Support team
Project team
11
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.
12
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.
13
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.