COMP 565 Software Design and Development Syllabus

COMP 565 Software Design and Development - Spring Semester 2004

COMP565 Software Design and Development - Syllabus

Professor Michael Werner - Wentworth Institute of Technology

Prerequisites by topic:

1. Programming abilities including data structures techniques.

2. Database understanding and experience.

3. Technical writing, and Technical Communication skills.

Writing Standards:

All written work that is submitted for this course must meet the standards set for English I. Poorly written papers will be returned to you, without a grade, for revision. Students are encouraged to utilize the writing center for help in polishing their papers.

Topics: (Specific sections of chapters will be assigned later)

Goals: After taking this course the student should be able to:

1. Prepare a Requirements Specification Document according to IEEE standards.
2. Use Computer Aided Software Engineering (CASE) tools to prepare a systems analysis of the existing system.
3. Prepare alternative designs for the replacement system, using both a process-oriented and an object-oriented approach. Document the designs using CASE tools.
4. Prepare detailed designs for files, data entry screens and other user interfaces, and algorithm designs for processes. Document using CASE tools.
5. Prepare a formal detailed testing plan.
6. Carry out project management activities including scheduling, coordinating team efforts, version control for documentation and code. Use Project Management software.
7. Prepare User and System Manuals.
8. Implement the design by producing robust, efficient and maintainable code. Carry out the test plan, correcting any errors detected.
9. Give formal oral presentations of the designs, responding to questions as needed. Give a final product demonstration.

Tests: There will be 3 tests and a final exam.

Grades will be determined approximately as follows:

Team Projects 30%

Oral Presentations 5%

Required Papers 5%

Tests 35%

Final Exam 25%

Attendance:

Because this is a course, which focuses on group work, it is not possible to make up absences from class by getting someone's notes, reading on one's own, etc. Regular attendance at every class and laboratory is expected. All class members are expected to attend presentations, whether or not it is their own team, which is presenting. Frequent absenteeism usually results in failure to fulfill course obligations on a timely basis, hence it may result in a lowered grade. You are responsible for all material given in class as well as in assigned readings.

Laboratory projects

Students will work in 3 to 5 person teams to design and complete major software projects. The projects will be submitted as a proposal followed by 3 major phases. Each phase will be ended by submission of a formal report followed by an oral presentation.

Laboratory Periods:

Laboratory periods are used for group meetings, project presentations, preparation of systems analysis documentation, and the design, coding and testing of programs. These periods may also be scheduled for software demonstrations, and conferences with the instructor. At times, specific instruction in the use of various software packages will be given in the laboratory.

Team Organization:

Students will propose teams to the instructor at the end of the first week of class. The instructor may modify these proposals in the interests of providing a good balance and mix of skills in each team. Important skills are oral and written communication, systems analysis, leadership/management abilities, and expertise with various software packages and computer languages. Teams will decide on a project and a team leader. The leader will assume overall responsibility for project management, including scheduling team members into tasks.

A peer review process will be conducted at the end of the course to allow each student to rate the quality of the contributions of others on his/her team. The peer review scores will be used to weight an individual student’s grade up or down from the grade the team receives on its project. For example, if a 3 person project is given a score of 80, then the participants might get scores of 86, 72 and 82 if the first student was peer-rated high, the second low, and the third slightly above the norm. Note that the 3 grades average to 80.

Since the team's grades are shared among team members, a mechanism is provided to enforce that all members contribute to the effort. If, at any time it is felt that a member is not doing his/her share of the work, the other members may, by unanimous vote, exclude that member from the team. The excluded student must then petition other teams for admittance. If no team will admit this student, he/she must embark on an individual project, not less difficult than any of the team projects. It is suggested that teams take measures to prevent exclusion from occurring. Such measures could include formal contractual arrangements within the team, warnings, careful scheduling of meetings, etc.

The Group Projects will be submitted as a proposal followed by three phases.

The deadlines are:

0 - Project Proposal: due Jan 20

1 - Requirements Analysis & Definition due Feb 7

2 - System & Software Design due Feb 28

3 - Implementation & Testing due Apr 11

Each phase will be ended by a report and an oral presentation. The 3 reports will eventually be bound together as Chapters 1, 2, and 3.

Students are encouraged to prepare the charts and some other documentation using Rational Rose and Microsoft Project software (both available in Wentworth Labs) or equivalent.

Phase 0: Proposal.

This is a brief paper outlining the need for the new software. The proposal should state who would be the users of the system, what its purpose will be, and who will develop it. The project leader or spokesperson should be identified. The proposal should also identify similar software that is currently available for purchase (or free use), and make the case that this software is inadequate to do the job, necessitating the development of new software.

Phase 1: Requirement Specification Document.

Prepare a detailed requirement specification using guidelines derived from IEEE standards. The specification should describe all required functionality from a user point of view. The language should be sufficiently detailed and specific, so as to produce testable requirements.

1.  Introduction

1.1.  Purpose of the system

1.2.  Scope of the system

1.3.  Objectives and success criteria of the project

1.4.  Definitions, acronyms and abbreviations

1.5.  References

1.6.  Overview

2.  Current system

3.  Proposed System

3.1.  Overview

3.2.  Functional requirements

3.3.  Nonfunctional requirements

3.3.1. Usability

3.3.2. Reliability

3.3.3. Performance

3.3.4. Supportability

3.3.5. Implementation

3.3.6. Interface

3.3.7. Packaging

3.3.8. Legal

3.4.  System models

3.4.1. Scenarios

3.4.2. Use case model

3.4.3. Object model

3.4.4. Dynamic model

3.4.5. User interface – navigational paths and screen mock-ups

4.  Glossary

5.  Costs, benefits & scheduling

5.1.  Estimated costs

5.2.  Estimated benefits

5.3.  Tangible

5.4.  Intangible

5.5.  Payback period

5.6.  Project schedule

5.7.  Gantt chart

Phase 2: Design Document

The design document will begin with architectural design, namely the division of the proposed system into modules with assignment of specific responsibilities to each module. UML diagrams will be used to show the relationships of modules to each other and communications between modules. The architectural design must account for such system aspects as responding to events, storing persistent data, and providing for security.

Detailed (object) design follows. Prepare a detailed specification of all human interface aspects, inputs and outputs. This includes mock-ups of all forms and reports. Database design must include details of all tables, views and queries. Details of data structures and algorithms to be used must be included.

1. Introduction

1.1.  Purpose of the system

1.2.  Scope of the system

1.3.  Design goals – Describe the goals for availability, responses time, reliability, security, etc.

1.4.  Definitions, acronyms and abbreviations

1.5.  References

1.6.  Overview

1. Current system architecture – Briefly describe the current software system.

1. Proposed software architecture

3.1.  Overview

3.2.  Subsystem decomposition – Identify the subsystems and the responsibilities of each. You can use component diagrams.

3.3.  Hardware/software mapping – How will subsystems be assigned to hardware? You may use deployment diagrams.

3.4.  Persistent data management – Identify the data which will be persistent. Describe the file system or database to be used, including a complete database design.

3.5.  Access control and security – For each different actor describe the operations they will be enabled to use. Describe authentication and security provisions.

3.6.  Global software control – Describe the control flow (e.g. procedural, event-driven, threaded). Procedural control flows can be described using activity diagrams. Event-driven flows are best described using sequence and state diagrams.

3.7.  Boundary conditions – describe how the system will be started up, initialized and shut down. How will it respond to errors and exceptions?

1. Subsystem services – This section describes in detail the services provided by each subsystem.

4.1.  User interface design (include all screen layouts and a hierarchy diagram for the user screens. It shows which screens are called from which others).

4.2.  Output design (include all report layouts)

4.3.  If your system is data intensive, you should show detailed and exploded data flow diagrams

4.4.  Class diagram. Show all classes – namely those identified in the requirements stage plus new classes needed in the implementation. For each class, show all operations it supports. But not simple operations such as getters, setters, constructors and destructors.

4.5.  Define the logic of the processes. For each complex process in the class model, give a pseudocode algorithm that clearly indicates the input, output and the processing.

4.6.  A description of the dynamic properties of those objects that have interesting changes of state, using state transition diagrams.

4.7.  You should do consistency checks. For example, a message in a sequence diagram is usually implemented as a function call in the target object. Your class diagram should show an association between the classes of the source and target objects. The target class should have an operation matching the message and its parameters.

1. Project planning

5.1. Development plan - A brief narrative description of the development plan referring to figures/tables to describe major development landmarks for supporting details. Describe any changes in schedules, costs and benefits from Phase 1.

5.2. Costs, benefits & scheduling

5.2.1. Estimated costs -

5.2.2. Estimated benefits

5.2.2.1.  Tangible

5.2.2.2.  Intangible

5.2.3. Payback period

5.3. Project schedule - Use PERT and/or GANTT charts. A schedule in chronological order showing code completion and test completion dates for each coding task and all integration and integration testing. (GANTT chart). Be sure to schedule at least a week for final integration and system test after the unit test of the last module.

5.4. Allocation of coding tasks to team members.

Phase 3: Implementation Document

The program modules designed in part 2 are actually built as per specification. They are then tested according to a test plan and demonstrated in a class presentation. The hardware and software needs will vary with the project but may include programming languages such as Java, C, C++, HTML, Visual Basic, COBOL, Tcl-Tk, Perl and LISP; as well as database management systems such as Access or Oracle. The programs are required to implement the main features of the product as described in the design, however, due to time constraints, they need not do extensive data validation or exception handling. The implementation document must include a testing plan and a deployment plan.

1. Introduction.
2. UML component model.
3. UML deployment model.
4. Detailed planning for each program (Use either HIPO charts, program structure charts, flow charts or pseudocode)
5. Working programs
6. Software Test Plan (see handout)
7. Changeover plan
8. User manual
9. System manual
10. Revised project scheduling and costs

Presentation Guidelines:

·  All group members must speak at least once, although some can speak more than others.

·  Use media such as PowerPoint slides effectively

·  Be professional (appearance, speaking style, etc.)

·  Keep it to 20 minutes

Plagiarism:

Wentworth's Academic Conduct and Honesty Policy as outlined in the student handbook will be strictly enforced.

1/9/2004 Page 6