CS361 Software Engineering I

1
CS361Software Engineering I

• Fall 2008

2
Welcome

• Class meetings STAG 323, TR 400-520
• Instructors Mark Van Patten / Mark Clements
• Office BEXL 100
• Email mark.vanpatten_at_bus.oregonstate.edu
• clementsc_at_bus.oregonstate.edu
• Office Hours M-F 9-5pm by appointment or
  drop-in. You might want to call or email first
  to be sure were there.
• Teaching Assistant Eunyoung Chung
• Class website http//classes.engr.oregonstate.edu
  /eecs/fall2008/cs361/
• All slides will be posted here after each lecture.

3
Key Firsts to Keep in Mind

• 1st Class in CS Professional Program
• 1st of 2 Software Engineering
• Core Courses
• 1st Major Project Class

4
Course Description

• This course is
• - Software Engineering NOT Programming
• - About software engineering processes and
  issues faced in developing quality software
• - Writing-intensive
• - Hands-on, project-based
• - Team-oriented, i.e., how to work on a team.
• Goal A hands-on introductory experience of
  software engineering processes in a team
  environment.

5
Assumptions

• You should be very familiar with programming
  concepts and practices, including
• Object-Oriented Programming
• Class diagrams
• Basic testing and debugging techniques
• Basic code documentation practices
• This is a CS pro class you are expected to be
  responsible and keep up with the reading and
  complete your assigned work on time. Lectures
  will not cover all reading but will focus on
  explaining material which is particularly
  difficult or which is not well-explained in the
  book. You are responsible for all materials for
  exams and your work.

6
Course Objectives

• The purpose of this course is to teach you the
  basic software engineering methods, focusing
  especially on the first half of the software
  engineering lifecycle. After completion of this
  course you should be able to
• Describe process models of software life cycle
  and discuss their phases, advantages and
  disadvantages.
• Gather requirements for realistic software system
  by interacting with a user or a user group write
  a requirements specification document.
• Model system requirements using one or more
  semi-formal notations such as UML, dataflow
  diagrams, entity-relationships diagrams, state
  diagrams.
• Design software systems at architectural level,
  and at lower levels, using one or more techniques
  such as object-oriented design or structured
  design. Express designs in design specification
  documents.
• Validate requirements and designs by reviewing
  specifications with user or user group adjust
  the specifications or design as necessary.
• Describe several methods of estimating the cost
  and developing a schedule for a programming
  project.
• Work effectively in a team.
• Prepare effective, professional software-related
  documents.

7
Reading

• Textbook
• Software Engineering by Pfleeger Atlee
  Required
• Waltzing with Bears by Tom DeMarco Timothy
  Lister Required On reserve in the library. Can
  also be ordered from Amazon.
• Additional Resources
• The Cathedral The Bazaar
• Open Sources 2.0

8
Grading

• This class is meant to be a writing-intensive and
  hand-on course. This means that you will be
  required to work on group projects and class-work
  (in addition to doing readings) outside of class
  time. This class will also be very interactive.
  Participation will count towards your final grade
  - a healthy discussion in each class session is
  expected.
• Participation 10
• Homework 5
• Midterm 1 25
• Final exam 25
• Project 35

9
Class Project

• You will form 5-person teams. Written work
  produced by the teams will indicate which team
  member wrote each section. Each team member will
  periodically, and anonymously, evaluate the other
  team members. The team assignments will receive
  an overall grade, which will then be distributed
  according to the teams internal evaluation,
  adjusted by the instructor. In extreme cases, a
  team can decide to fire a team member with just
  cause at week four. To do this, the team members
  must contact the instructor and make their case
  for why the team member should be fired.

10
Special Lectures

• OSU has a lot of cool people stopping by, some of
  them give talks, some related to this class, most
  of them very interesting.
• EECS colloquium series
• CS 461 Senior Software Eng. Proj.
• Open Source Speaker Series
• Visiting Guest Lecturers (Some in this class.)
• Some of these will be advertised in class,
  attendance is voluntary. If a particularly
  relevant speaker visits, you will be asked to
  make a special effort if to attend.

11
Other

• Special Needs
• If you have any special needs, or there is
  anything I can do to accommodate your learning
  needs, please come speak with me after class
• Academic Dishonesty
• The rules regarding Academic Dishonesty will be
  strictly enforced. Note that the penalties are
  quite severe and that the instructor has no
  discretion once a case of cheating is detected.
  Please see the OSU web-page for more details

12
Other

• Things to do
• Check out
• Open Source Educational Lab (OSEL)
  http//osel.oregonstate.edu
• Open Source Lab (OSL) http//www.osuosl.org
• The Business Solutions Group (BSG)
• http//BSG.oregonstate.edu
• Linux User Group (LUG) http//lug.oregonstate.edu/
  

13
What do you expect to get out of this class?
14
What is the difference between a Software
Engineer and a Programmer?
15
What is the difference between a Software
Engineer and a Programmer?

• Terms often used interchangeably in job
  descriptions, but they mean different things
• Programmer
• Responsible for producing code which meets a set
  of requirements and specifications
• Software Engineer
• Responsible for determining and writing
  requirements and specifications
• Managing development team
• Developing system design
• Coordinating development, integration, testing,
  documentation, and support activities

16
Q What is Software Engineering?
17
A Solving Problems!

• Analysis vs. Synthesis
• Methods and/or Techniques formal procedures for
  producing a result
• Tool an instrument or system for accomplishing
  something in a better way
• Procedure a combination of tools and techniques
  that produce a particular product
• Paradigm a particular approach or philosophy
  (like a style of cooking)

18
Wheres Waldo?
Computer Science Software Engineering The
Customer
Theories
Computer Functions
Problem
Tools Techniques
19
The Role of the Engineer
Computer Science Software Engineering The
Customer
Computer Scientist
Customer
Theories
Computer Functions
Problem
Software Engineer
Tools Techniques
20
Key Participants in the Process of Developing a
Software System

• Customer company, organization, or person
  paying for the software system
• Developer company, organization, or person
  building the software system
• User person or people who will use the system

21
What is a system?
22
A System Defined (I)

• a collection of objects and activities, plus a
  description of the relationships that tie the
  objects and activities together.
• for each activity
• - inputs required
• - actions taken
• - outputs produced

23
Parts of a System

• Activities
• an event initiated by a trigger
• transforms one thing to another by changing a
  characteristic
• Objects or Entities
• an element involved in activities
• Relationships
• origin, destination - effect of activity
• Boundary
• Domain of activities and relationships in which
  entities are involved

24
A System Defined (II)

• A set of entities
• A set of activities
• A description of the relationships among entities
  and activities
• A definition of the boundary of the system

25
Examples of Systems

Examples of Interrelated Systems

26
Building a House

• Style
• Design/Plans
• Materials
• Architect
• Bank
• Location, Location, Location
• Homeowner
• Neighborhood

27
Building a System

• Requirements Analysis Definition
• System Design
• Program Design
• Implementation
• Unit Testing
• Integration Testing
• System Testing
• System Delivery
• Maintenance

28
Software Development Process

• A description of software development that
  contains some of these key activities, organized
  so that they produce tested code

• Integration Testing
• System Testing
• System Delivery
• Maintenance

• Requirements Analysis Definition
• System Design
• Program Design
• Implementation
• Unit Testing

29
The Development Team
Requirements Analysis Definition
Analyst
System Design
Designer
Program Design
Programmer
Program Implementation
Unit Testing
Tester
Integration Testing
System Testing
System Delivery
Trainer
Maintenance
30
The Development Team
2
Requirements Analysis Definition
Analyst
System Design
Designer
Program Design
Programmer
Program Implementation
Unit Testing
Tester
Integration Testing
System Testing
System Delivery
Trainer
Maintenance
31
The Development Team
3
Requirements Analysis Definition
Analyst
System Design
Designer
Program Design
Programmer
Program Implementation
Unit Testing
Tester
Integration Testing
System Testing
System Delivery
Trainer
Maintenance
32
A Little Bit of HISTORY
33
The Only Constant...
34
CHANGE!
According to Wasserman (1996)

• Criticality of time-to-market
• Shifts in the economics of computing lower HW
  costs, greater dev and maintenance costs
• Powerful desktop computing
• Extensive networking - LAN, WAN, PAN
• Adoption of object-oriented technology
• GUIs using windows, icons, menus, pointers
• Unpredictability of the waterfall model