ZEN Client Information Gathering

From ZenWiki

Jump to: navigation, search
Element Content Description
Experiment ID ZEN Client Information Gathering
Responsible Engineer Sajjad
Purpose This experiment will help further decomposition the ZEN Client.
Expected Outcomes A better understanding of the information gathered using SMIG. The design will be incorporated into the Architecture document.
Resources Required
  • Use case: 4.5 hours
  • Design: 8 hours
  • Implementation: 8 hours
Artifacts
  • A draft use case specification.
  • A design of the information gathering prototype.
  • A working prototype.
Experiment Description The experiment will
  • Create a draft use case specification describing the functional requirements of the information gathering prototype.
  • Create a draft SMIG data model, especially the portion that is needed for information gathering.
  • Create a GUI-based representation of the SMIG data model using Eclipse RCP.
  • Create the functionalities described in the draft use case specification.
  • Demonstrate the quality attribute scenario #17:While entering information to a question, this question can be tagged with multiple tags in less then 1 second per tag
  • Help the responsible engineer understand the fundamentals of Eclipse RCP.
  • Provide productivity data for future estimation and planning.
Duration
  • Iteration #4, from Jan. 25 to Feb. 21, 2007.
  • The draft use case specification will be reviewed before Feb. 1.
  • A preview of the prototype should be available before Feb. 15.
  • Final prototype will be delivered to the client before Feb. 22.
  • The mini-schedule of events will be tracked by the Chief Scientist.
  • The Team Lead will roll up the durations and dependencies in the project plan.
Results and recommendations The responsible engineer must document the results of the experiment. Describe deviations from the expected outcomes and reasons for the deviations. Discuss and deviations from the planned experiment description. Describe recommendations as a result of conducting the experiment.


Contents

Use Case 1: Enter answer

Use case name: Enter answer
Unique use case ID: UC201
Primary actor(s): Interviewer
Secondary actor(s): None
Brief description: During an interview, once an interviewer selects and loads a question from the SMIG, he/she should be able to select an answer to that question from a list of pre-defined answers within the SMIG. This use case focuses on this ability of the user.
Preconditions: The interviewer has selected and loaded a question from the SMIG.
Flow of events:
  1. The interviewer selects an answer to the current question from a list of pre-defined answers to that question and gets his/her choice recorded.
Postconditions: None.
Alternative flows and exceptions:
  • An interviewer may opt to not get his/her answer recorded to the question at hand and may leave the subject question unanswered.

Use Case 2: Enter comments

Use case name: Enter comments
Unique use case ID: UC202
Primary actor(s): Interviewer
Secondary actor(s): None
Brief description: In addition to selecting an answer for a question, an interviewer may enter a text based comment along with his/her response to the question. This use case focuses on this ability of the interviewer.
Preconditions: The interviewer has selected and loaded a question from the SMIG
Flow of events:
  1. The interviewer chooses to enter a text based comment along with his response for the subject question.
Postconditions: None
Alternative flows and exceptions:
  • The interviewer may opt to not enter any comment(s) along with his/her response to a question.

Use Case 3: Add tags

Use case name: Add tags
Unique use case ID: UC203
Primary actor(s): Interviewer
Secondary actor(s): None
Brief description: In addition to selecting an answer for a question, an interviewer may enter one or more tags along with his/her response to the question. This use case focuses on this ability of the interviewer.
Preconditions: The interviewer has selected and loaded a question from the SMIG
Flow of events:
  1. The interviewer enters one or more tags along with his/her response to the subject question.
Postconditions: None
Alternative flows and exceptions:
  • An interviewer may decide not to enter any tags with his/her response to the subject question.

Use Case 4: Save response

Use case name: Save response
Unique use case ID: UC204
Primary actor(s): Interviewer
Secondary actor(s): None
Brief description: Once the interviewer has entered his/her answer to a particular question along with any optional tags and/or comments, the user should be able to save this data into the Zen tool. This use case focuses on this very ability of the interviewer to get his overall response to a question recorded into the Zen tool via the Zen client.
Preconditions: The interviewer has entered at least an answer to the subject question.
Flow of events:
  1. The interviewer enters his/her answer to the subject question
  2. The interviewer adds any optional tags and/or comments for the subject question
  3. The interviewers overall response to the question (i.e. answer, tags, and comments) are recorded into the Zen tool.
Postconditions: The interviewer's overall response to a question (i.e. answer, tags, and comments) are recorded by the Zen tool.
Alternative flows and exceptions:
  • The user may decide not to save his/her response to a question and may instead, move to another question.




Design

Architectural Views

- C&C Architectural View

Image:Information-Gathering-CC-view.jpg


  • Description of Architectural Elements.
Element Description
AnwserEditor AnswerEditor is responsible for providing the answering form and accepting information for answering the selected question.
AnswerResponseHandler AnswerResponseHandler is responsible for converting information gathered by the AnswerEditor (as the question's answer) to a format that is compatible with the answer storage component i.e. the ResponseArchive.
ResponseArchive ResponseArchive represents a component responsible for storing responses to questions i.e. the answers. This storage component is accessed via a JDBC connector.



- UML Class Diagram

Image:Information-Gathering-class-diagram.jpg


  • Description of Elements.
Element Description
Question Represents a question in the SMIG. Each question has a unique ID, belongs to a specific SMIG, has the actual text of the question, has a list of possible answers associated with it, and applicable tags.
Response Every answered question has a response. Therefore, since since responses are unique, they have a unique ID. Each response has an associated question. Each response contains applicable comments, tags, and the actual text of the answer.
Tag A tag is unique and therefore has a unique ID. Has a title and includes a way to ascertain whether it is flagged or not.
Comment Every comment is unique and therefore has a unique ID. It also contains the actual text of the comment.
Answer Every answer has a unique ID and contains some text associated with it.


Architectural Alternatives

  • Given the functionality covered by this experiment, the resulting architecture is quite straightforward and there are no significant viable alternatives that can be considered at this time.


HTML Prototype

  • The following is a screen shot of a HTML based prototype produced under this experiment:


Image:html-screenshot.jpg


Reflection

  • While the experiment itself was quite simple, a comprehensive usability study must be performed to evaluate the degree of affordances offered by the HTML prototyped developed under this experiment. Additionally, it has been experienced that RCP has a steep learning curve associated with it.
Personal tools