COMP 253 SPRING ‘07

Logistics and Introduction 16 January

Contact information

Best methods (in order) are AIM: dianepozefsky

don’t use to send me files or information that I need to save

email: pozefsky@cs.unc.edu phone (cell): 824-9073

Dropping in is fine

TeamsSami Says(Gary Bishop)

Corey Davis Patrick Reynolds Adam Roberts Edward Rowe

3 pm Wednesday

Learning Disabilities Services(Dorian Miller)

Stefan EtsradaRemi JeanMikael Meyer

2 pm Wednesday

Dynamic Visualization(Don Smith)

Kevin Gorczowski Eli HolderThomas Sandberg

4 pm Wednesday

Campus Tour(John Oberlin)

Paul PucciarelliFlorian GyarfasJustin Steffy

11 am Wednesday

Hawking Toolbar(Gary Bishop)

John FousheeAndrew HulbertBrian Louden

8 am Thursday

Linux Screen Reader Scripts(Peter Parente)

Cristobal PalmerAndy ShiJoel Feiner

9 am Wednesday

Oral Microbiology Lab(Eric Simmons)

Benjamin JohnsonDavid MichaelsonDavid Williams

10 am Wednesday

Let’s take 5 minutes

Schedule time with your team and me

The right software, delivered defect free, on time and on cost, every time. Carnegie Mellon Software Engineering Institute

Software Engineering Objective

Course Objectives Overview of the practice of software

engineering: why software development is more than coding

Hands on experience of the full process and working on a team

Awareness of software engineering failures in the real world

Awareness of new technologies

About the Projects

Service Learning: APPLES course Does not require that all projects be

service learning No additional work. Appears on your

transcript.

Logistics All meetings are in my office (Sitterson 356) I would like to attend your first meeting with

your client If not the first, shortly thereafter

I’m flexible about rescheduling meetings But I get grumpy when I’m stood up

Feel free to contact me at any time by email, phone, or IM

Class attendance is expected

Inclement weather policy Generally follows university If not having class on a day the

university is open, I will email class before 9 am

Possible exceptions University open and busses not running University re-opens at 11 and sidewalks

aren’t cleared until then We win another national championship

Class Material All content available on web site

Slides Templates

http://www.cs.unc.edu/~pozefsky/COMP523_s07/home.html

Sections for each project Should be repository of all material Public site Will give access as soon as I have your cs id Can be pointer to any site you want

Readings

No class text Light assigned readings

Lots of references However, if you are going to go

into the software engineering field, consider reading

Brooks, The Mythical Man-Month

How the Course Will Run Classes are planned for the full semester

Classes will lighten toward the end of the semester Additional time to be used for team meetings Working on guest speakers

Meetings Weekly team meetings with me: organizational and

technical Meetings with the client as appropriate (probably

weekly) Weekly team meetings

Regular deliverables Description posted on web Broad dates are class-wide; details are team-defined Multiple executable deliverables to client

Beyond the Project Tests

One or two virtual in-class quizzes (open book, note, computer)

Must be done electronically Covers the broader issues

Depending on class performance, second may be cancelled or for extra credit

Presentations Midterm: what the project is aboutl Final: show and tell

End of the Semester Project completed Additional documents

Critique of another team’s documentation

Evaluation of team performance Final presentation

Show and tell In lieu of final exam Clients invited

Significant Changes Spec first Each week, I’ll ask each team member to fill in

a form with hours for Meetings Documentation Code Design

Final project will be due 2 weeks before the end of class

Last two weeks, for testing Final grade is on the FIXED code

Deliverables Functional specification Project schedule Contract User interface sketches Design Implementation manual User guide Code Running system Presentations

First Deliverables

Team rules: 18 January First meeting with client ASAP Web site as soon as I get you

access

Web Site Contact information Overview of project Related links Repository for all documents

Most important early documents are Team rules Contract Schedule Journal or log of decisions made and reasoning

… or you’ll keep revisiting the same decisions

Documentation All electronic documentation will be

linked from the web site Commonly used software packages

only Spelling matters

as does grammar Deadlines are expected to be met

Adapting the schedule is different than missing deadlines

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 Ways to contact and communicate Responses to emails

Expected times Meaning of no response

Coding practices Style Prologue How to maintain current state

Strongly recommend using a formal mechanism CVS, Subversion, …

More than one project has accidentally regressed in the last two days

Grading 80% project

individual contribution multiplier (.8 – 1.1) 40% code 30% documentation 5% on time delivery 5% professionalism

10% team presentations 10% quizzes and critique

7.5% quizzes 2.5% other team critique

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

Weekly record of hours Peer evaluations My evaluation Client evaluation Consultant evaluations

All software projects are different

but …Requirements will change.Surprises will happen.Schedules will slip.Life will happen.

Common Mistakes Over committing (“big eyes”) Unrealistic schedules

Training Access to people or materials Hours in the day

Level of detail Vague descriptions Over specification

Not knowing your user Assuming that you’ll get it right the first time

Clients vs. Users The client is the person “paying the bill” The users are the ones that will

Use your system Maintain your system Administer your system

Know their Skill level Time constraints Tolerances Expectations