computer report (index and introduction)

1/4

CPSC 362 Foundations of Software Engineering

Homework (1) Outline Summer 2014

[Version: 7/6/2014] HW1 Outline (Tentative – this HW outline can be changed later. Please check any updates.) What To Do Apply the principles (tasks/activities/models) you learned from the textbook (Ch.7 – Ch.11), and practice (perform and document) requirements analysis for an application for a smart watch (“FullertonHelp”) running on mobile operating system (Android OS). Functional requirements include similar functions that can be found in many smart phones (phone call, text, etc.), however, the more important/unique functions include a “help function” using GPS for Alzheimer’s patients (or children) who lost their way. Once the “help” key on the patient’s watch is clicked (or a pre-fixed ping/echo time is passed, or the patient moves out of either home or a pre-fixed area, or a pre-fixed time is passed), the watch shows up a Google map that locates where he/she is and where is his/her home. At the same time the subscribers’ (usually their family members or guardians) watches start ringing, and their watches show where the patient is located if they click the “find” key. [*The pre-fixed ping/echo time: The subscriber will send “ping” to the patient manually (by pushing its button), and the patient must return “echo” manually (by pushing its button) when they get a “ping” signal. If the patient does not respond with “echo” within the pre-fixed time, we assume something happened to the patient.] In addition, each team may extend functions to include their own ideas.

[Source: images on the Web] • HW1 will perform the requirements analysis activities (and its documentation) and

prepare for detailed design (and its documentation). • HW2 will complete detailed design (its documentation). HW2 is an extension of

HW1. • Reading Ch.7 - 11 will be helpful for HW1, and reading Ch.12 - 18 will be helpful for

HW2. Document all activities in terms of models shown in the textbook. • Appendix 1 and 2 provide information for the modeling language, UML, and Object-

Oriented Concepts. Team Charter Construct and submit your team charter (using the given template; with your own words).

2/4

Functional Requirements (FRs) List 10 FRs. Start with 10 FRs in the analysis phase. Prioritize FRs to focus on. Non-Functional Requirements (NFRs) List your own 5 NFR. Start with at least 5 NFRs, and then finally prioritize/choose 2 NFRs. NFRs include Quality Attributes and Design Constraints Minimum process requirements • Use the (1-pass/customized) Waterfall Process.

o In the HW report, have a separate section that describes each phase (Figure 2.3). (See the format of HW Report below.)

o Requirements Analysis: Define and document requirements analysis. (This part must be completed in HW1.)  Perform all tasks shown in Ch.7-11.

• See Ch.7-11, and Appendix 1 and 2.  Minimum requirements (minimum work-products):

• Functional requirements (list at least 10 FRs, and focus on mainly 3-4 FRs)

• Non-functional requirements (list at least 5 NFRs, prioritize NFRs, focus on 2 NFRs)

• (Textual) Use cases (UCs): Construct at least 10 UCs total. Construct at least 1 UC for each FR (Ch.8, Ch.9)

• At least 1 UC Diagram (UCD) (Figure 8.2, Figure 9.4, Ch.8-9) • At least 1 (Analysis) Class Diagram (ACD) (that show all

‘candidate/potential’ classes that can be extracted from FRs/UCs, and their relationships) (Ch.8-10, Figure 8.4, Figure 10.1, Figure 10.2, Figure 10.4-7).

• At least 3 Class-Responsibility-Collaborator (CRC) cards (for 3 candidate classes; must show at least 3 responsibilities for each class; must have at least 1 collaborator for a class) (Figure 10.3)

• At least 1 Activity Diagram (AD) (for the most appropriate FR/UC/scenario) (Figure 8.3, Figure 9.5, Figure 11.6)

• At least 1 Swim-lane Diagram (SLD) (for the most appropriate FR/UC/scenario) (Figure 9.6)

• At least 1 State Diagram (SD) (for the most appropriate FR/UC/scenario) (Figure 11.1)

• At least 1 (Analysis) Sequence Diagram (ASD) (for showing interactions between actors and the system (and external systems only if necessary) as a black-box; these interactions can be identified from FRs/UCs/scenarios) (Figure 11.2)

• Do not follow both Figure 11.3 and 11.4 - they are not good examples for both sequence and class diagrams)

3/4

o Design: Perform and document design activities. (This will be completed in HW2 – To be discussed later.)  Perform all tasks defined in Ch.12-18. Design (in HW2) must be

tightly related to the requirements analysis models (in HW1).

o Code: (This must be completed in HW2 – To be discussed later.)  Only prototype coding will be required (class names and method

names only, no body implementation). However, coding must be tightly related to the design models. Here we emphasize on translating design into code, rather than coding to a specific OS. Coding to a specific OS is not required, even though studying a mobile OS is recommended. Your coding can be OS-independent.

o Test: No activity for testing is required. o No other activities will be required.

o No CASE tool is required to use. Hand-writing/drawing is fine. However, use

of one or more CASE tool is recommended. Traceability • Showing bi-directional traceability is required.

o Construct Traceability Matrix showing relations between artifacts (within 1-2 page).

o Bi-directional traceability between requirements models.  (e.g.) A traceability matrix that shows relations between FRs and use

cases. o Bi-directional traceability between requirements and design models o Bi-directional traceability between design models and (prototype) code. o Construct Traceability Diagram (1 page) that shows relations among all

artifacts you construct. This helps you understand how all artifacts are related. o See both Figure 12.1 and Figure 12.4 to learn relations among artifacts.

Required Work Products and Document (HW Report Format) • File format: (Open-) office file format (DOC or any open-office file format), PDF,

RTF or standard graphic file formats. Space: single/double, Fonts: Times/Arial, Font size: 11-12.

• Document all activities (and their work-products/artifacts) in terms of the phases of the Waterfall Process (Figure 4.1, Figure 12.1, Figure 12.4).

• The contents/format of the HW report must be (at minimum) like the following: o A Cover Page

 HW Title, team title, names of all (only participating) members (and email addresses, signatures), submission date, course title, instructor name, …

o Revision History  Who did what, when, …

o Table of Contents (chapter titles, page numbers)

4/4

o Communication (within 1 page) (What is this? See Figure 4.1)  Project initiation (5-10 lines)

• A short description of the application to build (5-10 lines)  Requirements gathering (5-10 lines): what you did for this?

o Planning (within 1 page)  Estimating, scheduling, tracking (all in 1 page)

o Modeling: Requirements Analysis (See Ch.7-11, and Appendix 1 & 2)  Document activities. Produce work products related to this phase.

Perform all activities described in the textbook. (Perform all activities to construct minimum work-products described above.)

o Modeling: Design (See Ch.12-18)  Document activities. Produce work products related to this phase.  Fill in this part in HW2. Now you only type “To be done in HW2”.

o Construction: Code  Prototype code (only class names and method names – tightly related

to design models)  Document activities. Produce work products related to this phase.  Fill in this part in HW2. Now you only type “To be done in HW2”.

o Construction: Test  Still need to have this chapter title, but only type “No activity for test

is required.” o Deployment

 Still need to have this chapter title and only type “No activity for deployment, deliver, support, feedback is required.”

o References (list references here, and cite them in appropriate places in the report)

o Team Charter (using the given template)  Construct and submit your team charter using the given template.

Clearly discuss/specify how to evaluate team members (in the section of “evaluation criteria”). This helps you understand in advance how to evaluate members (and how you will be evaluated by members).

o Team Evaluation (using the given template)  Construct and submit your team evaluation using the given template.

‘Fairly’ evaluate members with objective evidence (by the “evaluation criteria” you discussed in your team charter).

Presentation • By the due date, submit a hard copy of your HW report (all work products you

produced). • Bring your files in a USB drive for presentations. • No preparation for separate presentation materials is required. (Just project your files

as it is when presenting.) [The End of HW1 Outline] [The HW2 Outline: To be announced]