Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456 CSci 435/535: Syllabus
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. If you like a formal (mathematical) approach to software
development, take CSci 420 Formal Methods in Software Engineering.
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 (ISBN: 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. (This is to be determined on 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, head project manager, and sometimes customer. 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 members of the team. The remainder of the 435 students are
developers, organized into teams, and 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)
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. A manager will eventually assume ownership of the issue,
verifying the appropriateness of the point values. Once an issue is resolved,
any developer working on the issue then sets its status to "Waiting for Team
Leader". The team leader checks the technical correctness of the work, then
sets the issue 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 (Developers)
Midterm exam: 15%
Final Exam: 20%
Homework: 30%. The homework assignments will be subject to a weighted
average.
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.
Point Distribution (Managers)
Midterm exam: 15%
Final Exam: 20%
Homework: 25%. The homework assignments will be subject to a weighted
average.
Project: 30%. There will be several project milestones, and your grades
for the milestones may be subject to a weighted average. Each milestone grade
is assigned by the professor, based primarily on satisfactory completion of
the milestone requirements.
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.