Getting Started

Website: : http://www.cs.odu.edu/~zeil/cs350.html

Syllabus: : All students are responsible for reading the course syllabus and abiding by the policies described there.

• Lectures: Tues & Thurs 11:00–12:15, Dragas 1117
• Recitations: Fri 1:00–1:50, 2:00–2:50, Dragas 1105

Recitations will be used for special topics and for meetings with teams once the semester project is underway. Until then, they will not meet.

1. Course Structure

1.1 Readings

• Chapters from text
  • Zeller, Essential Open Source Toolset, Wiley, 2005, 0–470–84445–0
• Online Lecture Notes
• Other Online Materials
  • Articles & manuals on internet
  • Textbook chapters
    • Available online via ODU library from odu.edu network only
  • CS 382

1.2 Assignments

• Individual assignments
• Team Project

1.3 Exams

• Midterm & Final
  • Administered on-line
  • Dates & times TBA
• Final exam is cumulative.

2. Course Pre-requisites

• CS 330 (Object-Oriented Programming and Design), or
• CS 361 (Advanced Data Structures and Algorithms)
  • Students who have not taken CS 330 are encouraged to take CS 382 (Introduction to Java) as a pre-requisite or, at the very least, to work through that courses’s website during the first few weeks of the semester.

3. Communications

Contact Info

Steven Zeil	E&CS 3208
(757) 683–4928	zeil@cs.odu.edu

When possible, students should use the course Forum for communications rather than email.

3.1 Office Hours

Office hours are posted online at http://www.cs.odu.edu/~zeil/officehours/

4. Important Policies

4.1 Late Submissions

… are not normally accepted. Exceptions may be made in cases of

• documented emergencies
• arranged prior to the due date when possible.

Extensions to due dates will not be granted due to

• difficulties “porting” from one system to another
• transient system crashes
• system overloaded

4.2 Academic Honesty

ODU is governed by a student honor code.

• Everything you turn in for grading must be your own work.
• Detailed policy statement is in the syllabus.

Academic Honesty (cont

• Aiding a fellow student to copy someone else’s work (including your own) places you equally in violation.
  • Includes leaving work world-readable on the computer system!
• Failure to report observed violations of the honor code is also a violation.

4.3 Grading

Assignments:	25%
Semester project:	30%
Midterm exam:	20%
Final exam:	25%

5. Opening Discussion

• How do you expect professional software to differ from “academic” software development?

• What are some of the factors that make some software development projects especially difficult?

5.1 Lessons from Cost Models

COCOMO (COnstructive COst MOdel) by B. Boehm, 1981

The Intermediate Cocomo formula estimates effort in person-months:

\[ E = a_{i} (\mbox{KLoC})^{b_i} \cdot \mbox{EAF} \]

where the EAF is a multiplier computed from:

	Ratings
Cost Drivers	Very Low	Low	Nominal	High	Very High	Extra High
Product attributes
Required software reliability	0.75	0.88	1.00	1.15	1.40
Size of application database		0.94	1.00	1.08	1.16
Complexity of the product	0.70	0.85	1.00	1.15	1.30	1.65
Hardware attributes
Run-time performance constraints			1.00	1.11	1.30	1.66
Memory constraints			1.00	1.06	1.21	1.56
Volatility of the target environment		0.87	1.00	1.15	1.30
Required turnabout time		0.87	1.00	1.07	1.15
Personnel attributes
Analyst capability	1.46	1.19	1.00	0.86	0.71
Applications experience	1.29	1.13	1.00	0.91	0.82
Software engineer capability	1.42	1.17	1.00	0.86	0.70
Target environment experience	1.21	1.10	1.00	0.90
Programming language experience	1.14	1.07	1.00	0.95
Project attributes
Application of software engineering methods	1.24	1.10	1.00	0.91	0.82
Use of software tools	1.24	1.10	1.00	0.91	0.83
Required development schedule	1.23	1.08	1.00	1.04	1.10

Where do often we see this combination?

• Large teams with
  • high turnover
  • vastly different levels of experience / ability
• Minimal opportunity for face-to-face communication

6. Course Themes

• Look at best practices from the open source world.
• What are the tools and techniques that developers use on a daily basis?
• Automate best practices.
  • Make it more trouble and more time consuming to do things wrong than to do them right.

6.1 Areas of Emphasis

• Test-Driven Development
• Build Management
• Version control
• Configuration Management
• Documentation Management

Test-Driven development

Exemplified by the philosphy of “write the tests first, then design and write the code.”

Build management

Making sure that you and others can build the system easily.

• A good build manager will support TDD, documentation processes, and many of the other things we will be exploring.

Version control

The ability to track changes in the software.

• Avoid accidents
• resolve conflicting changes
• Explore ideas, then discard ones that turn out to be undesirable

Configuration management

• How do we cope with importing third-party libraries that are themselves changing and have version depencies among themselves?
• How do we cope with dependencies of our own software upon the underlying platform?

Documentation management

• Integrating documentation into the development process,
  • minimizing the “chore”.

.