Team Project Handbook - Systems Design - Foundations of Chemistry | CSC 3150, Study Guides, Projects, Research of Information Systems Analysis and Design

Download Team Project Handbook - Systems Design - Foundations of Chemistry | CSC 3150 and more Study Guides, Projects, Research Information Systems Analysis and Design in PDF only on Docsity!

CSC 4150 / CPE 41 50

Team Project H andbook

A utumn 200 7

Prof. Elaine Weltz 

Table of Contents

• General Project Information
  • Project Timetable
• Team and Personal Documentation
• Basic Requirements for All Written Documentation.
• System Requirements Document
• System Design
• Implementation Deliverables
  • User's Startup Manual
  • Appendix A – Sample Team Documentation Appendices
  • Appendix B – Sample Use Case Template
  • Appendix C – Sample Data Dictionary: Class and Attributes.
  • Appendix D – Sample Data Dictionary: Operations

PROJECT MILESTONES

Except for the two demonstration days and Requirements Review, the milestone dates for deliverables are "not later than" dates. In the past, students have tended to become pushed by time pressures near the end of the quarter. If you wish to give yourselves more time for coding and testing, you may turn in requirements or design specifications any time prior to their due dates. A two-working-day grading turnaround is promised for all submitted documents. With that in mind, the following should be noted about the end of the week:  I will be leaving campus immediately after class on Fridays. If you wish to submit a deliverable on Friday, please bring it to class.

PROJECT TIMETABLE

DATE DELIVERABLE

September 28 @ noon Project and Team Proposal (may be submitted electronically)

October 12 and 15 Requirements Review deadlines (material exchange and review meeting)

October 19 System Requirements Document

October 22 User-Interface Prototype Demonstration

November 9 System Design

December 3 System Presentation and Demonstration

December 7 @ noon Implemented and Tested System with User Documentation

Team Reflection and Peer Evaluations

GRADING

1. Requirements and Design documents are graded on the following:  Completeness and continuity of the document.  Adherence to written document standards (see page 5).  Neatness and polish  Correct application of the "technical rules" of the analysis and design methodology used. Variations introduced, or methodologies used other than those introduced in CSC 3150, 4150, or 4410 must be documented (and your documentation adhered to).  (Requirements) All listed functional requirements must be documented via use cases; all use cases must be traceable back to given functional requirements.  (Design) Comparability and traceability to System Requirements. Major changes must be documented; minor refinements need not be. Your System Requirements document will be included as an appendix to the Design document so that comparability and traceability can be judged.
2. The finished system will be graded on the following:  Completeness of the system (any missing features must be documented as such).  Documentation neatness and polish; adherence to written document standards (see page 5).  Ease and convenience of operation.  Correctness – does it work?  Effectiveness – does it do what it advertises?  Aesthetics – is it user friendly; is the UI consistent, logical, and pleasing to the eye?
3. Percentage of quarter grade associated with each project deliverable:  System Requirements Document 10% (page 6)  User-Interface Prototype 10% (to be described in class)  Design 10% (page 8)  Presentations (2) 10% (to be described in class)  Implementation w/ Documentation 15% (pages 10 and 11)

Team and Personal Documentation

Members are expected to be equal contributors to their team (though contributions within a specific

phase or on a specific activity may vary). Since the instructor cannot "police" each team, four

instruments will be used to monitor team activity and individual contribution.

Team Documentation

 Team Log. Each team will keep an ongoing report of status throughout the quarter. This will consist of a

weekly emailed Meeting Log, including “minutes” for each team meeting. All teams will meet at least once per week ; if there are more meetings, include notes for each. Email this to all team members and to the instructor (eweltz@spu.edu). The email MUST have as its Subject: 4150 Log. Each week’s log must be received by the instructor by noon each Tuesday. A sample outline is included in Appendix A. The exact style can be tailored to the needs of your team.

 Team Reflection and Evaluation (Project Post-Mortem). Each team will submit an evaluation of

their project experience. This will take the form of answering several open-ended questions. The exact questions will be distributed near the end of the quarter; the evaluation is due December 7 with system deliverables.

Personal Documentation

 Personal Time-Sheets. Each team member will keep a detailed accounting of time spent on project

activities. This will be submitted for review via email to eweltz@spu.edu. Include time spent on each activity (to the nearest ¼ or ½ hour) and total time for the week. Appendix A shows a weekly summary example; you can keep a daily log if you prefer. This reporting is the responsibility of each individual. The email MUST have as its Subject: 4150 Time and must be received by the instructor by noon each Tuesday. To be most helpful, teams should plan to review each other’s time sheets on a semi-regular basis. In this way, they will obtain a clearer picture of inconsistencies in the amount of time being spent on project activities and can work toward balancing the load.

 Peer Evaluations. Each team member will complete an evaluation of team members (including

themselves). This form will ask you to rate the contribution made by each team member to the development process. An evaluation form will be distributed near the end of the quarter; it is due December 6 before the start of the Final Exam.

A Word on Working Together

Stress points WILL arise during the quarter. Your fellow team members will at times be your closest

friends and at others your greatest frustrations. It is the responsibility of ALL TEAM MEMBERS to

communicate regularly and openly with one another. You are all responsible for each other. Each

person is expected to do everything in their power to achieve project success AND everything in their

power to facilitate the success of the rest of the team. If you are having any difficulty with completing

tasks for any reason, don’t keep it a secret; to do so ensures a project of less than optimum quality!

System Requirements Document

Reminder: Refer to “Basic Requirements for All Written Documents" for additional information on

document content and layout.

The following is the “company standard” outline of sections for a CSC 4150 requirements document.

Your audience is a combination of your team and any possible customer/client. Each section except the

Introduction will also include its own “introduction”, a short paragraph telling the reader what to

expect from the section.

Executive Summary – see Pfeiffer page 108. Use this summary to introduce your team, describe your

activities to date, and your plans for the remainder of the project.

1. Introduction

 System Description and Rationale – See Pfeiffer page 109, “PROJECT DESCRIPTION”. What is being

built? By whom? Why is it being built? Who is the customer? What are the expected benefits to customer and user?

 System Scope – Briefly describe what is (and is not) included in the scope of your system’s functionality.

List, but do not describe here, the major system services. See Pfeiffer page 109, “SCOPE OF STUDY” for style suggestion. Include also how your system will work and interface with other systems (if applicable).

2. System Requirements – See D/W/T Chapter 5, especially pages 124 – 129, and Tsai/Kamar Chapter 6 for

a review of requirements analysis, functional requirements, and nonfunctional requirements.

 Functional Requirements – Provide a brief textual description of the system’s functional requirements.

Outline and briefly describe the services to be provided to the user; a bulleted list of requirements might be the easiest to create – and reference. One can think of this section as providing the details of the system services listed in the Introduction’s “System Scope”. Functional requirements must be related to and traced to the Software System Model (section 4). Include references to which Use Cases will provide each required service, making sure the reader knows what these references mean.

 Nonfunctional Requirements – List and describe any and all:

 System Requirements and Constraints (hardware, memory, networking, etc.)  Software Requirements and Constraints (are there limitations or version concerns?)  Performance Requirements (for example, speed, capacity, reliability)  Security Requirements  Cultural or Political Constraints  Project Constraints (for example, team and time constraints)  Other Constraints (if there are any) All requirements (functional and nonfunctional) are to be stated in quantifiable, testable language. For example, NOT “Page download will be fast” BUT rather “Page download time will not exceed 5 seconds.”

3. Hardware and Software (ref. D/W/T Chapter 13, “Physical Architecture Layer Design” and Tsai/Kamar

Section 7.2, “Architectural Design”) This section places the system to be built in its context and describes HW and/or SW that will be needed in order to implement and operate the system. Most 4150 projects do not assume purchase of HW/SW. If this is the case, no purchase cost information is required ; target HW/SW minimums still need to be outlined.

 Description of System Architecture – Is this a stand-alone or interconnected (networked) system? Is it

server-based, client-based or client-server in architecture? Are there client-server tiers? Where are each of the four “basic functions” (data storage, data access, application and presentation logic) housed?

 System Architecture Model – D/W/T Figure 13-9 (page 435) shows three versions of UML Deployment

Diagrams. Provide at least one diagram of your system’s architecture in Figure 13-9’s Version B or Version C styling. If you wish to include BOTH version B and C style drawings, that is fine (although for standalone systems it would seem a bit overkill). Include before the drawing(s) a text description of the components of the system’s environment.

 Required Hardware Components

Describe minimum and recommended HW requirements for your system. Include estimated purchase cost (if applicable).

 Required Software Components

What system and support software is required to run your system? Include estimated purchase cost (if applicable).

 Development Software – describe any tools to be used in system development. Include why these

have been chosen.

4. Logical System Model

 Use-Case Diagram (ref. D/W/T Chapter 6; Tsai/Kamar 6.3.2)

Use Visio to create a Use-Case model (VISIO Software / UML Model Diagram / UML Use Case). Remember that not all readers of a Requirements document are technical types, so be certain to describe in your introduction to this section what the symbols mean.

 Use-Case Descriptions (ref. D/W/T Chapter 6)

Include Use-Case Descriptions to describe the activities of your system. Appendix B of this handbook includes a sample template (available electronically from my home page: http://myhome.spu.edu/eweltz/, CSC 4150, Downloads). ALL USE CASES MUST BE DESCRIBED.

 Initial Data Model (ref. D/W/T Chapter 7; Tsai/Kamar 7.3.3; CSC 4410 text and/or notes)

For most of you, this will consist of a Class Diagram (VISIO Software / UML Model Diagram / UML Static Structure). For this initial model, you need only include the Classes you anticipate for the system with their Attributes and Relationships (that is, no operations at this point). If you prefer, you may use VISIO to draw an Entity-Relationship Diagram for a database-oriented system.

 Data Dictionary

Include Visio screen shots of class and attribute definitions. For all classes (including association classes) include Name, Visibility, Documentation (1 – 3 sentence description), and attributes. For all attributes , include Attribute (name), Type, Visibility, Multiplicity, Initial Value ( if there is none). Appendix C shows which documentation is expected and the desired detail. Similar information is required for entity- relationship diagrams, though style can be modified (see instructor if you are unsure if your style is appropriate). To be useful, this dictionary must be in alphabetical order by Class (or entity).

5. System Evolution

You may already be aware of system functions that are desired but will not be part of the original version. These, and any planned or recommended upgrades to hardware or software for continued system use, should be outlined here. This is also the appropriate place to document which system services are guaranteed for Version 1 (the one you are building this quarter) and which might be considered optional until later if time becomes a problem.

3. Structural and Behavioral Design (ref. D/W/T Chapters 7 and 10; Tsai/Kamar 7.3.3)

NOTE: If your system is not designable using object-oriented techniques, see the instructor to discuss

alternative program design methods.

 (Complete) Class Diagram (D/W/T Chapter 7)

This final version of the system Structural Model will begin with your Initial Data Model (Requirements Section 4). Add the operations needed to implement your system, being careful to correctly and completely define all parameters and return values. Add any new needed classes or attributes; you may also eliminate classes now determined to be unneeded.

 Updated Data Dictionary: Classes with Attributes and Operations

While Contracts (D/W/T) are a good way to describe the outline of classes and operations, their creation would include some documentation that is redundant to the class and attribute definitions you have already completed for System Requirements. Therefore, I have chosen to have you submit operation documentation similar to that for CSC 3150. Appendices C and D provide examples of content and printouts. For all current classes (those included in the Complete Class Diagram of the previous section), include: Name, Visibility, Documentation (1 – 3 sentence description), attributes, operations For all attributes of these classes: Attribute (name), Type, Visibility, Multiplicity, Initial Value ( if there is none) For all operations of these classes: Operation (name), Return Type, Visibility, Scope For parameters, Parameter (name), Kind and Default Value (or ) Describe the operation (Documentation), and be sure to note if “IsQuery”. Note: This description need not be complete pseudo code, but should be more detailed than, for example, “this operation handles a customer request”. The key is that this needs to supply enough detail that a programmer could use this information, along with the Behavioral Model of the next section, to code your class.

 Behavioral Model (D/W/T Chapter 8)

 Submit either UML Sequence or Collaboration Diagrams showing how your classes will accomplish the Requirements Document’s Use Cases. Since you want to develop a complete system, it is assume that all use-cases from System Requirements will be documented by these diagrams.  Submit a Statechart Diagram to show the states of at least one object type in your system. More are optional…but a good idea if they will help visualize and create the system.

4. System Evolution

Revise and update this section from your System Requirements Document. You may now have a better idea of what can be done now and what must be done later…

5. Appendix - System Requirements Document

Does not need to be rewritten, but any substantive changes that have been made to the requirements during design should be noted. You may make such notations neatly in ink (using blue, red or green so as to contrast the black printing).

Implementation Deliverables

The following 4 items are to be submitted as your completed project. The first two are to be

electronically submitted, but last two must be in paper form (even if you include a ReadMe and/or online

help with your system).

1) Software System (executable)

This may be submitted on CD or other media, or as the address of a Web-based application. Aside from that, I would prefer not to have to deal with the additional "variables" of downloading a system from the Internet or as an email attachment…so I won’t.

2) Source Code

This is for the purpose of establishing that your team followed appropriate coding style and documentation standards. It may be submitted as hard copy or on disk (preferred). Yes, this will be reviewed as part of the system's evaluation. For database apps, basic DBMS-generated data dictionary materials will be substituted (or you may include in your User's Manual a section telling "advanced" users how to access embedded code).

3) User's Startup Manual

The outline on the next page is to be used as a guide. Make sure that your User's Manual is accurate and easy to read. If I run into any difficulties with using your system, guess where I'll look for help!

4) System Development Documentation

Re-submit your System Requirements and Design Documents as an Appendix to the Startup Manual.

Appendix A – Sample Team Documentation

Meeting Log

Team: Date:

Members Attending:

Progress Reports on Action Items from Last Meeting:

Concerns and New Items for Discussion:

Action Items and Team Assignments:

Next Meeting Date/Time/Place:

Personal Time-Sheet

Name: Elaine Weltz Week Ending: April 28

Time Activity Comment

2 hours Use Case Diagram

2½ hours UI Design

10 hours UI Prototype coding Taking longer than expected!

1 hour Team meeting

15½ hours

Appendix B – Sample Use Case Template

Use-Case name : ID : Importance :

Primary actor : Use-Case type :

Stakeholders and interests :

Brief description :

Trigger :

Trigger Type (circle one): External Temporal

Relationships :

Association :

Include :

Extend :

Generalization :

Normal flow of events :

Subflows :

Alternate / exceptional flows :

Appendix D – Sample Data Dictionary: Operations

Class Advisor ’s Operations: The Operations’ Parameters: QueryGrad Details: