CSci 435/535: Software Engineering
Syllabus
Where and When
- Class: 11:00-11:50 MWF, Jones Hall, Room 302
- Office hours: 1:00-2:30 MW, and by appointment. 140 McGloughlin-Street Hall
Instructor
Web Page
Description
- From the catalog: "The software life cycle. Software design methodologies.
Testing and maintenance. Programming teams."
- This course will provide an introduction to the discipline of software
engineering. An emphasis will be placed on practical knowledge and experience,
although some theoretical and historical material will be presented as well.
- It is assumed that students already have programming experience. This
course will not devote much time to coding, debugging, or other basic software
knowledge which the student should have acquired earlier in the curriculum.
Instead, it will focus on the problems, design, techniques, and tools which are
involved with the development of large software systems by groups of people.
- A significant portion of this course will be devoted to a project which
you will complete outside of class. Students are required to meet for two hours
a week with their group to work, and to work individually as well. Note that
you may need to devote significant time to the project during "crunch time"
prior to a deadline.
- This course is cross-listed as CSci 535. If you are a graduate student
with software experience, you are advised to take CSci 780 instead. Graduate
students are expected to perform more (and different) work than
undergraduates.
Prerequisites
- CSci 312. CSci 301 is preferred, and will be required next year.
- Good individual programming skills.
- Initiative: I expect students of your caliber to not need hand-holding.
"But you didn't tell us to do that" only goes so far.
Some Topics
- Development Processes
- Testing and Other Verification Methods
- Project Management
- The Software Lifecycle
- Object-Oriented Analysis and Design
- Formal Methods
Books
Required
- Code Complete (2nd Edition) by Steve McConnell (ISBN: 0735619670)
Suggested (Required for CSci 535)
- The Mythical Man-Month: Essays on Software Engineering (2nd
Edition) by Frederick P. Brooks (0201835959)
Anyone who knows anything about software engineering has read this book. I
strongly advise you to get it if you expect to write software for a living.
Course Structure
Classes
This course is about learning "book knowledge" along with "experiential
knowledge". Mondays and Wednesdays will be traditional lectures on SE topics.
Friday class meetings will be related to the particular software project which
we will be working on. (Details are in the document "Project Description"
which will be handed out this Friday.) Friday meetings may involve short
informational presentations, inter-group communication and status reports, and
elevation of issues.
Project
Unlike many group software classes in which groups of students all implement
the same software, we will be working as one large team to develop a sizeable
software system. The system will be developed incrementally as a series of
milestones. Each student will receive a grade at the end of each milestone
based on the points they have earned by resolving issues. (Details are in the
document "Project Grading".)
If the work for a milestone is not met, this will obviously affect student
grades for that milestone. However, this should not necessarily penalize
students in the next milestone. To address this issue, managers will have to
negotiate with the customer (i.e. the professor) to narrow the set of features
or extend the milestone deadlines.
Management Organization
The class structure is as follows. The professor serves as the infrastructure
manager, and head project manager. Project managers consist of the CSci 535
students and perhaps some CSci 435 students. Project managers report weekly to
the professor. At the next level are team leaders, chosen by the project
managers from the 435 students. The remainder of the 435 students are
developers, performing a wide range of activities. This management heirarchy
is mainly meant to reduce communication and management overhead, and not to
restrict people from working with the people they want.
The customer's principal responsibilities are:
- To help identify key requirements
- To negotiate time and requirement tradeoffs
- To validate key design decisions
- To evaluate the resulting product
The project manager's principal responsibilities are:
- Motivate team leaders to perform their tasks
- Negotiate milestones with the client
- Plan weekly goals for each team leader
- Plan development activities
- Provide technical assistance to developers when necessary
- Resolve personnel issues
- Attend weekly manager-only planning meetings
- Attend weekly status report meetings with the professor (and get weekly
status reports from team leaders)
- Run the Friday project meetings
- Manage tasks on the issue tracker: create new tasks as necessary, assign
points for tasks, sign off on completed tasks
- Monitor the status of project risks and outstanding issues
- Manage distribution of project responsibilities to team leaders
- Manage the documentation (perhaps by delegation): the requirements
specification, the high-level design, the detailed design, user documentation,
etc.
- Lead the teams in producing the development strategy.
- Verify that quality assurance methods are adequate
The team leader's principal responsibilities are:
- Serve as principal point-of-contact between the team and the manager(s).
- Manage assigned software modules and other responsibilities
- Motivate the team members to perform their tasks.
- Identify the tasks to be accomplished in the next week and by whom.
- Verify the satisfactory completion of tasks, promoting to the managers
for final signoff.
- Each week, report team status (via e-mail) to the project managers.
- Lead the team in implementing the modules for which the team is responsible
- Develop and maintain the high level design (with the other team leaders)
- Design and implement quality assurance methods
- Run all weekly team meetings, acting as facilitator
The developer's principal responsibilities are:
- Implement the portions of the software assigned by the team leader.
- Integrate modules of the system.
- Develop and implement both unit-level and system-level tests.
- Develop requirements, test plans, and other project documentation.
- Attend all team meetings.
[Modeled after Introduction to the Team Software Process by Watts S.
Humphrey, Addison-Wesley]
Tracking Work
The work to be done will be managed using an issue tracking system. Both
managers and developers can add issues to the tracking system, which can be
anything: bugs, feature enhancements, development tasks, etc. After an issue is
added, developers add themselves to the issue to indicate that they are working
on it. Once an issue is resolved, any developer which "owns" it can set its
status to "Waiting for Manager". At this time the manager assigned to the task
will review the work and certify it as complete by changing its status to
"Closed".
While the majority of issues will be resolved by one developer or a small
group of developers, from time to time tasks will be given to everyone in the
class as homework assignments. This gives everyone a chance to learn a
particularly important topic. For example, every group will develop a
requirements document as a homework assignment. The managers will select the
best one for the project, or merge several of the best ones. In contrast, the
implementation phase will have each group working on a different part of the
overall system.
Generally speaking, managers will not complete any of the tasks for the
project. Instead, they will create tasks to be completed by the undergraduate
developers. They will also review and certify completed work. Because
points are assigned to tasks, the project managers will ultimately determine
the project grade for each student in the class. In addition to these
responsibilities, graduate students will provide technical assistance, and will
provide weekly updates to the professor. In the case when a manager must step
in and complete the work for a task, the scoring methods will penalize the
developers. (This is described in the document "Project Grading".)
Managers will have their own task list which they (and the professor) will use
to track management related issues.
Grading
Point Distribution (CSci 435 Developers)
- Midterm exam: 15%
- Final Exam: 20%
- Project: 35%. There will be several project milestones, and your grades
for the milestones may be subject to a weighted average. Each milestone grade
is simply the "Performance Score" reported by issue tracker.
- Homework: 30%. The homework assignments will be subject to a weighted
average.
Point Distribution (CSci 435 Managers)
- Midterm exam: 15%
- Final Exam: 20%
- Project: 15%. There will be several project milestones, and your grades
for the milestones may be subject to a weighted average. Each milestone grade
is the group grade reported by issue tracker.
- Homework: 30%. The homework assignments will be subject to a weighted
average.
- Management: 10%. Management grades will be given at each milestone based
on weekly written reports, ability to manage developers, and ability to run the
Friday meetings. These grades are subject to a weighted average.
- Developer Evaluation: 10%. At the end of the course, the developers will
evaluate the managers.
Point Distribution (CSci 535)
- Midterm exam: 15%
- Final Exam: 20%
- Project: 25%. There will be several project milestones, and your grades
for the milestones may be subject to a weighted average. Each milestone grade
is the group grade reported by issue tracker.
- Management: 30%. Management grades will be given at each milestone based
on weekly written reports, ability to manage developers, and ability to run the
Friday meetings. These grades are subject to a weighted average.
- Developer Evaluation: 10%. At the end of the course, the developers will
evaluate the managers.
The "No BS" Rule
- The student gets 10% on short-answer questions in which the answer given is "No BS". Note: not turning in a test or exam gets you a 0.
Letter Grade
- 90% ≤ grade < +∞ → A
- 80% ≤ grade < 90% → B
- 70% ≤ grade < 80% → C
- etc.
... but the professor makes the final call on all grades.
Late Work Policy
- 20% of the points are lost per day (or portion thereof) that an assignment is late. Example: Due Monday at 5pm, and you turn it in 6pm Tuesday: -40%
Make-up Policy
- Tests can be made up with prior approval of the instructor
- Your final exam schedule can only be altered by the Office of Student Affairs
Students Who Need Accommodation
- Please see me after class or send email to set up a brief meeting.
Guidelines for Class Assignments
- The Honor Code is always in effect, unless the professor says otherwise
- External material: feel free to use the internet, books, etc. If you
happen to find a solution to a problem, do yourself a favor and avoid it.
- Fellow students: Help each other with general questions, but don't give
away the strategy or "secret" of a problem. Let the professor give hints if
necessary.
Back to CSci 435/535 Homepage.
