30 August 2010
Introductions
Logistics
Web Site:
http://www.cs.unc.edu/Courses/comp523-f10/
 Office Hours: Open office policy
 This course is
4 credits
EE
APPLES
CI (Implication: document iterations)
Programming Languages distribution group
 Class attendance is expected
 Exams will cover class material


NO INCOMPLETES
Course Objectives

Overview of the practice of software
engineering
 Awareness of software engineering (and
failures) in the real world
 why software development is more than
coding
Hands on experience of the full process
 Working on a team
 Awareness of new technologies

Team Meetings
Beyond the Project

Content
 Quick pass for project
 More in depth of how it is done in the larger
world

Exams
 2 essays in lieu of midterms
 Final is project presentations TUESDAY DEC 14

Readings
 Key papers tied to lectures


Guest speakers
Hot Topics
Readings
Goal is for you to read the classical
papers
 Scheduled relative to content
 Each paper will be accompanied by 2 or
3 questions for you to be ready to
answer
 If discussions lag, I will call on people

Guest Speakers
Fred Brooks, Design of Design
 Gary Bishop, Writing accessible code
 Mike Reiter, Writing secure code
 Dave Ogle (IBM), Testing
 John Reuning (ibiblio), SCRUM

Hot Topics
Observation: not many COMP courses
teach what’s new and hot
 Assignment:

 Identify a topic that you want to learn about
 Team paper and presentation (15 min)
○ Based on choices, not projects
○ 5 days allocated beginning in October
 Presentation must be reviewed with me
before class

Topics due September 8
Grading

75% project








individual contribution multiplier (.8 – 1.1)
30% code
30% documentation
5% on time delivery
5% professionalism
5% presentations
10% hot topics (paper and presentation)
15% essays (6%, 9%)
Individual Contribution

Rare that it will go over 1.0
 Basically, you can’t do better than the project
 But there are always exceptional circumstances

Inputs
 Peer evaluations
 My evaluation
 Client evaluation
 Consultant evaluations
Professionalism
You are representing the university, the
department, this class and yourself
 Your web site is publicly available and may
be accessed by outside people
 You are expected to

 show common courtesy
 make it to meetings promptly or notify people
 meet your commitments

It is part of your grade
Team Rules


Establish them now … before problems arise
Team behavior
 Notifying team members if you’re going to be late –
meetings AND assignments
 Ways to contact and communicate
 Responses to emails
○ Expected times
○ Meaning of no response
 Recovering from slippages

Coding practices
 Style
 Prologue
 How to maintain current state
Project Resources

Talk to me about what you need
 I can provide server and repository space, but
NOT maintenance support
Recommend freely available software, not
software that is a limited free trial period
 Focus on simple solutions
 Feel free to use existing solutions


If you are having team or client
problems, contact me early: don’t let it
fester!
Web Site

Each project is required to have one
 Will be linked from course page
 Should be repository of all material: a
WORKING site
○ Capture decisions (including rationale)
team assignments
 Public site
 Can be pointer to any space you want
○ Recommend using a public resource
○ Will give you CS space if you want
Code Management

You MUST use a form or version control
 Homegrown is possible but too unreliable

Primary choices
 CVS
 SVM
 Bazzar (Russel team apt to use)

You can install your own or use a
publicly available version
Web Site Options
Build Your Own Web Site
 Google code, doc, calendar, …

 Caveat: Google doc good for working
documents…not for final formatting





Assembla
Sourceforge
Wiki
Combinations thereof…
Check with your client about preferences
Web Site Content
Contact information
Overview of project
Related links
Repository for key deliverables
functional spec
design document
 AND all other documents










user manuals
Team rules
Contract
Schedule
Code
Journal or log of decisions made and reasoning
… or you’ll keep
revisiting the same decisions
Templates and descriptions will be available on web
site by end of week
 http://www.cs.unc.edu/Courses/comp523-f10/
Deliverables

* Functional specification
 User interface sketches
Project schedule
 Adapting the schedule is different than missing
deadlines
 Contract

 Commitment to PRIMARY goals and agreement on
SECONDARY





* Design Document
* User guide
Code
Running system
Presentations
How the Course Will Run

Meetings
 Weekly team meetings with me: organizational and
technical
 Meetings with the client as appropriate (probably weekly)
 Weekly team meetings
 Each week, I’ll ask each team member to fill in a form with
hours spent (education, not grading)

Regular deliverables




Description and dates will be posted on web
Multiple executable deliverables to client
Multiple classroom demos
Class dates BUT will consider reasoned
arguments about project-specific exceptions
Meetings
All meetings are in my office (Brooks 146)
 Begin today
 I’m flexible about rescheduling meetings
 But I get grumpy when I’m stood up
 Agree on contact procedure for missing or
late

Software Engineering Objective
The right software
delivered defect free,
on time and
on cost,
every time.
Carnegie Mellon Software Engineering
Institute
All Processes Include
Requirements
 Design
 Implementation
 Test
 Maintenance

All software projects are different
but …
Requirements will change.
Surprises will happen.
Schedules will slip.
Life will happen.