Last updated: October 28, 2005. The
most recent updates are usually in red type
Description: Techniques for the construction of
reliable, efficient and cost-effective software. Requirements analysis,
software design, programming methodologies, testing procedures, software
development tools and management issues.
Students design and implement a system in a group project. Laboratory course.
|
Background
of the Instructor red if changed |
Midterm Description red if changed |
|
Evaluation
of Students red if changed |
Plagiarism red if changed |
|
Forums
-- past and present red if changed |
Policies in Eric Braude’s
classes red if changed |
|
Project
and Presentation red if changed |
|
|
Homework and due dates red
if changed |
Tools
red if changed |
|
How
to Contact Eric Braude red if changed |
Textbooks and Materials red
if changed |
|
Learning Objectives red
if changed |
Topics and Class Dates red
if changed |
Students will be able to plan
software application projects, gather requirements, create an
architecture, create a design, implement the code and test the product.
Required
·
Optional: Software Engineering: an
Object-Oriented Perspective by E. Braude (Wiley 2001)
·
Updated
notes
·
The site for the above book contains a soft
version of the case study that you may use for templates, as well as the full
case study source code, and the slides for all classes. The latter correspond to the figures in the
book.
Software
Engineering: A Practitioner's Approach by R. Pressman (McGraw Hill)
Additional References:
The
Mythical Man-Month 20th anniversary edition by F. Brooks et al
A
Discipline for Software Engineering
by W. Humphries ("the PSP book")
Introduction
to the Team Software Process
by W. Humphries ("the TSP book")
To reinforce a central concept in
software engineering, students will work in teams on most project parts.
Team leadership will change once during the semester. Specialization within groups may be
permitted, but all members must know all parts. Teams will give
presentations on the last day of class, and may be called upon to give
in-progress reviews.
The format of the presentation
should be as follows.
3 minutes approximately: Introduce members
and describe what the application is supposed to do
3 minutes approx: Show your design
4 minutes approx: Give a demonstration if
possible
5 minutes: What did **not** work in the
process
5 minutes: What **worked well** in the
process
Use different people or pairs to present
different parts. Have all set up in
advance so that there is no waiting between presenters.
The midterm will probably be in the
following form.
1. Describe a realistic process for developing
a software application given the following circumstances …... Explain your choice and show a rough
schedule.
Criteria:
a. Adequacy and
appropriateness of the process
(A
= entirely appropriate number and type of phases)
b.
Clarity of description (A = all expressed very clearly, with
specifics)
2.
Within
the constraints mentioned in question 1, give parts of requirements
documentation for the following application.
Provide the most important headings for your documentation, as well as illustrative examples of content
only. Omit "documents referenced",
interface specifications of all kinds, design constraints and
"scope".
Your
customer is …….
Criteria:
a. Clarity of
requirements description (A = very clearly expressed examples)
b.
Completeness within the (sub) headings you have chosen (A = complete within the
subheading; no redundancy)
3. Give an overall architecture of the software
application described in question 2.
Preferably, use two to four annotated diagrams. Accommodate expansion of the requirements;
explain.
Criteria: a. Clarity of design
(A
= very modular and very clear design; low coupling; high cohesion)
b. Growth potential of the design i.e.
attention paid to reasonable future growth
(A = all key areas and
reasonable growth addressed).
There will be a midterm, together
with assignments, given on most weeks for the first two thirds of the semester.
The assignments will consist of group work on the term project.
|
|
weight |
|
Midterm |
35% |
|
Project
|
65% |
Parts of assignments are evaluated
equally unless otherwise stated.
All members of the group will
receive the same grade for each joint submission, factored by peer evaluations
within the group. To fulfill your peer evaluation option, you must
individually send me an e-mail, after the group's
final submission is made, apportioning your evaluation of the RELATIVE
CONTRIBUTION TO THE GROUP's GRADE as follows. Be fair
and rational. Suppose that your group has n participants. Apportion 10(n-1)
points among the team members excluding yourself. For
example, members of a team consisting of A, B, C, and D, could be evaluated by
member B as A=8, C=12, and D=10. The extent of this factoring will be decided
by the instructor near the end of the course. Groups have the option to decline
peer evaluations, in which case all participants will receive the same grade
for each joint submission.
Within each project, grades will be
apportioned as follows.
|
Final
submission |
30% |
Influenced
by peer evaluations, if any |
|
Remainder |
70% |
Late homework is not accepted
unless there is a reason why it was impossible to perform the work. In that
case, the written reason should be attached to the homework, which will be
graded on a pass/fail basis.
Please also read detailed
information about grade averaging method.
Please cite all
references and uses of the work of other.
All instances of plagiarism must be reported to the College for action. See plagiarism
policy and reference.
|
Dt. |
Cls |
Topic |
Approximate project
schedule Official assignments and due
dates are at homework page and due dates |
|
9/8 |
1 |
Review course contents Overview of software
engineering |
Tentatively form teams and
projects. Identify communication mechanisms. |
|
9/15 |
2 |
Process of Software
Engineering Describe the problems and
challenges of developing software products; Describe steps in the process for
developing software products; summarize and compare various models (top-down,
incremental, spiral etc.); the Capability Maturity Model |
Finalize teams. List informal requirements of
project, describe the challenges, explore feasibility; volunteer skill
specialization (e.g. Java) Summarize process alternatives; apportion
feasibility retirement. Investigate legacy system;
develop program to learn tools. Develop SCMP and prototype |
|
9/22 |
3 |
Software Project Management Introduce project management
concepts, development metrics and risk management; the Personal Software
Process. Refine informal requirements. Implement prototype parts. Scheduling,
quality assurance, configuration management; inspection techniques I. |
Draft project management plan,
metrics, describe risks with retirement Apportion detailed risk retirement
tasks; draft project management plan; draft configuration management plan.
Refine informal requirements. Apportion skill matrix. Reverse engineer legacy system. Develop SPMP |
|
9/29 |
4 |
Requirements Analysis I Introduce the concept of system
engineering; describe requirements analysis and C-requirements |
Build prototypes and proof-of-concept
experiments. Develop SRS |
|
10/6 |
5 |
Requirements Analysis II Describe and apply D-requirements |
Define requirements for project Develop SRS |
|
10/20 |
6 |
Design I: Essentials Design principles and concepts;
Define "architecture" and review alternatives |
Specify design for project
modules; Decompose project into 3-7 modules for group execution. Specify
interfaces. Develop SDD |
|
10/27 |
7 |
Design II: Design
Techniques Describe alternative design methods;
match with requirements |
Develop SDD |
|
11/3 |
8 |
Implementation Programming standards etc. Code inspections |
|
|
11/10 online |
9 |
Integration Describe integration and unit
testing |
|
|
11/10 |
10 |
Testing Describe testing strategies and
techniques; inspection techniques Review for midterm |
|
|
11/17 |
11 |
Midterm |
|
|
12/1 |
12 |
Maintenance |
|
|
12/8 |
13 |
Project Presentations |
Project due; Present results |
|
12/12 |
|
(no class) |
Individual project assessments
due |
Here are some (mostly free) tools
to consider
For configuration management: Freepository , SourceForge
Spring
1999; Summer 1999; Fall
1999; Spring 2000; Fall
2000; Spring 2001; Spring 2002;
Fall
2002; Spring 2003; Summer
2003; Fall
2003; Spring 2004
Fall 2005:
Post
message: 673F05@yahoogroups.com
Subscribe:
673F05-subscribe@yahoogroups.com or go to the site at http://groups.yahoo.com/group/673F05/