Last modified: January 5, 2014
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.
Recitations will be used for special topics and for meetings with teams once the semester project is underway. Until then, they will not meet.
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.
Office hours are posted online at http://www.cs.odu.edu/~zeil/officehours/
… are not normally accepted. Exceptions may be made in cases of
Extensions to due dates will not be granted due to
ODU is governed by a student honor code.
Academic Honesty (cont
| Assignments: | 25% |
| Semester project: | 30% |
| Midterm exam: | 20% |
| Final exam: | 25% |
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?
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?
Test-Driven development
Exemplified by the philosphy of “write the tests first, then design and write the code.”
This is easily justified when fixing bugs. You need to have a test handy that shows the bug causing the program to fail, so that you can run it (again and again) while you try to fix the bug. How else will you know that you have it fixed?
But test-driven development is really about how to do the initial design. Programmers are lazy. If they write the code first, they often skimp on the testing because that seems like too much work for code that they are “sure” is correct (programmers are optimists – lazy optimists).
But if the tests are already there, and if it’s easy to run them (or, even better, hard not to run them), then programmers will actually do the testing on a regular basis.
And thinking about tests for special/boundary cases, etc., often helps you remember those cases when later doing the deisgn and coding.
Build management
Making sure that you and others can build the system easily.
Version control
The ability to track changes in the software.
Configuration management
Documentation management
.