1 Background
2 Case Description
-
Diagnosing
-
Action planning
-
Action taking
-
Evaluating
-
Specifying learning
2.1 Background on the user-centered techniques to analyze and design an application
Types of Defects | Description of Defects |
---|---|
Omission | Omission of any information necessary in the artifact. |
Ambiguity | Unclear definition of certain information in the artifact, which may lead to multiple interpretations. |
Incorrect Fact | Misuse of the artifact elements. |
Inconsistency | Conflicting information between the artifact and the information needed to solve the problem. |
Extraneous Information | Unnecessary information included in the artifact (e.g., information that is not needed to solve the problem). |
-
Opening point
-
Scene
-
Signs
-
Dialogues
-
Structures of dialogues
-
Transition utterance
-
System process
-
Breakdown recovery utterance
-
Ubiquitous access
-
Closing point
2.2 Developed application and practices adopted for the development of artifacts in the analysis and design phases
Sprint | Tasks Description |
---|---|
Sprint 1 | Sprint Planning Meeting |
Personas Specification | |
Scenarios Specification | |
Extraction of Requirements from the Personas and Scenarios | |
Development of Use-Case Diagrams | |
Use Case Prioritization | |
Retrospective Meeting between the Analysis and Design Team and Management Team on Lessons Learned | |
Sprint 2 Sprint 3 Sprint 4 Sprint 5 | Sprint Planning Meeting |
Interaction Modeling for Use Cases: A (Sprint 2), B (Sprint 3), C (Sprint 4) and D (Sprint 5) | |
Use Case Specifications: A (Sprint 2), B (Sprint 3), C (Sprint 4) and D (Sprint 4) | |
Development of Prototypes for Use Cases: A (Sprint 2), B (Sprint 3), C (Sprint 4) and D (Sprint 5) | |
Development of Activity Diagrams for Use Cases: A (Sprint 2), B (Sprint 3), C (Sprint 4) and D (Sprint 5) | |
Retrospective Meeting between the Analysis and Design Team and the Management Team on Lessons Learned | |
Sprint 6 | Sprint Planning Meeting |
Improvements in the Artifacts of the Previous Sprints | |
Retrospective Meeting between the Analysis and Design Team and the Management Team on Lessons Learned |
-
Interaction Models - In the interaction modeling, the team developed the MoLIC diagrams to represent all interaction paths between the user and the system;
-
Use Case Specification - In the use case specification, the team described the use cases considering the different execution flows;
-
Prototypes - The prototypes necessary to represent the interface were also developed;
-
Activity Diagrams – UML activity diagrams were developed to provide an overview of the system behavior through the sequence of actions in the activities (Czopik et al. 2014).
-
Title - description of the lesson’s name;
-
Situation - details of the situation in the project;
-
Cause of the Situation - reason for the occurrence of the situation in the project;
-
Consequence of the Situation - description of the consequences of the situation in the project;
-
Action - details the solution to the situation, i.e. providing details of an activity that was applied to solve such a situation;
-
Benefit - describes the effects that were caused by the action or situation in the project.
2.2.1 Activities of the analysis phase of the development process of the HCDP application
2.2.2 Activities of the design phase of the development process of the HCDP
-
A. Analysis of the development of artifacts in Sprint 2
-
B. Analysis of the development of artifacts in Sprint 3
-
C. Analysis of the use of interaction models as basis for the development of other artifacts in Sprint 3
2.3 A technique for inspecting MoLIC interaction diagrams
E# | Verification Items for the MoLIC Element vs Software Requirements |
---|---|
Opening point Closing point | Verification item 1: Was the element used in the model to represent the start/end of the interaction? If not, report it as an Omission defect. Generated problem: This defect may impair understanding the beginning/ending of the interaction by the team members. Verification item 2: If the previous item occurs, does the element represent the beginning / end of the interaction according to the requirements? If not, report it as an Inconsistency defect. Generated problem: This defect may impair the consistency of requirements with the appropriate start/end of the user interaction in the system (e.g. incorrect sequence of interaction scenes with regards to what was described in the requirements). |
Scene, Signs, Dialogues and Structures of dialogues | Verification item 3: Are all requirements represented in the interaction model? If not, report it as an Omission defect. Generated problem: This defect may hinder the development of a necessary requirement (e.g. the software engineer did not capture all of the goals that the user could have, considering the requirements used as basis). Verification item 4: Are there inconsistent requirements in the interaction model? If so, report it as an Inconsistency type defect. Generated problem: This defect may make the software inconsistent with the requirements (e.g. in a sequence of dialogues that should be structured with XOR, the AND structure was used). Verification item 5: Is there information in the interaction model that is not in the context of the requirements? If so, report it as an Extraneous Information defect. Generated problem: This defect may make the software present irrelevant information (e.g. scenes that were not described in the requirements can be represented in the prototypes). Verification item 6: Is it possible to understand all the information about the requirements in the interaction model in a clear way? If so, report it as an Ambiguity defect. Generated problem: This defect may cause the insertion of other defects in the developed artifacts, since each team member may have a different interpretation (e.g. description of similar scenes provided multiple interpretations about the user goals.) Verification item 7: Have all requirements been correctly represented in the interaction model? If not, report it as an Incorrect Fact defect. Generated problem: This defect may hinder the development of correct requirement (e.g. the sign issuers can be attributed to the user or to the designer’s deputy in an incorrect manner with what was described in the requirements - confusion between “d:” and “u:”). |
Transition Utterance and Breakdown recovery utterance | Verification item 8: Are there any omissions on interactions required for the software features? If so, report it as an Omission defect. Generated problem: This defect may impair the user interaction with the system (e.g. lack of transitional utterance when switching from one scene to another, impairing the interaction sequence). Verification item 9: Is the content of the interactions between the features consistent with the requirements? If not, report it as an Inconsistency defect. Generated problem: This defect may make the user interaction inconsistent from the requirements point of view (e.g. the content “u: play again” regarding the scene that is outside the context of the interaction in the game, such as the “see positive ending” scene). Verification item 10: Is the content of the interactions between the functionalities in the context of the requirements? If not, report it as an Extraneous Information defect. Generated problem: This defect can also impair the user interaction from the point of view of the requirements (e.g. the content “u: search hotel” is outside the context of the game). Verification item 11: Does the content of the interactions between the features provide multiple interpretations? If so, report it as an Ambiguity defect. Generated problem: This defect may provide for the insertion of other defects in the developed artifacts, since each team member may have a different interpretation (e.g. the use of two user transition utterances for the same goal, which provided multiple interpretations about the user transition). Verification item 12: Have all interactions been correctly represented in the interaction model? If not, report it as an Incorrect Fact defect. Generated problem: This defect may hinder the development of correct interactions (e.g. in the breakdown recovery utterance, solid lines can be used, instead of the dashed lines). |
System process | Verification item 13: Was the element required for the interpretation of an applied user action? If not, report it as an Omission defect. Generated problem: This defect can impair proper user interaction in the system after a certain action (e.g. an interpretation for the game results regarding the positive ending or negative ending). |
Ubiquitous access | Verification item 14: Can the features associated with this element be accessed at any time in the user-system interaction? If not, report it as an Inconsistency defect. Generated problem: This defect may make the user interaction inconsistent from the requirements point of view (e.g. there is not opportunity for the user to change the topic of the conversation from any other scene for the game exit. Therefore the ubiquitous access element should not be related to closing point element). |
Sprint | Subjects | Number Defects | Time Hours | Effectiveness (%) | Efficiency |
---|---|---|---|---|---|
Sprint 1 | S1 | 2 | 0,83 | 40% | 2 |
S2 | 3 | 1 | 60% | 3,61 | |
Spint 2 | S1 | 4 | 0,7 | 66% | 5,71 |
S2 | 3 | 0,6 | 50% | 5 |
3 Discussion and evaluation
“I found it great to have the interaction model for developing prototypes. I mapped the information in the prototypes from the diagram, which improved my performance in this activity” (S3).“I believe that the definition of these activities helped each team member carry out his/her tasks and improved our communication. The team was already aware of what they would do; and we found fewer errors in evaluating the consistency of the developed artifacts” (S4).“The dependency between activities can cause rework, as in Sprint 2. With the set of activities, we did not have this problem. In addition, we do not become idle” (S2).“The interaction modeling meetings provided a better understanding of the artifacts to the team members” (S1).
3.1 Related work
3.2 Threats to validity and limitations
-
Internal validity
-
External validity
-
Conclusion validity