MET CS 673 Software Engineering

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.

• Meeting Time: Thursdays 6:00-9:00 pm
• Meeting Place: Charles River Campus FLR 121 (Fuller building, opposite the BU Bridge)
• Prerequisites: Course in Data Structures and at least one 500-level programming course

Students will be able to plan software application projects, gather requirements, create an architecture, create a design, implement the code and test the product.

Textbook and Materials

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”)

Project Structure

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.

Presentation format for last class

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.

Midterm

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).

Evaluation of Students

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.

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.

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.

Here are some (mostly free) tools to consider

For configuration management: Freepository , SourceForge

Forums — past and present

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 2004: Spring 2005

Fall 2005:

Post message: 673F05@yahoogroups.com

Subscribe: 673F05-subscribe@yahoogroups.com or go to the site at http://groups.yahoo.com/group/673F05/