Description
My journey of learning with students in this subject started with an idea. The idea was to create an application to rate baristas to show our appreciation for their work. From there, I developed a scenario in which I imagined how I would use the app as a customer to rate baristas. Next, thanks to the students, a focus group discussion I conducted with them revealed a number of requirements that the system would need to meet to achieve its aim. Some of these were technical; some of them were good to have features. Next, the students and I created a System Vision Document. In this document, we briefly described the problem, we listed several system capabilities and considered the benefits that the system would bring. After that, the students and I created a number of user stories following the format [As a (role), I want to (goal) so that (reason or benefit)]. Those user stories were accompanied by several acceptance criteria so when we have interacted with the system as actors, we know what to expect. In the next step, I made a list of functional requirements that the app must meet. I used the ‘verb’ followed by ‘noun’ format to articulate these functional requirements. From those, I created a number of use cases and categorised them under each actor following the ‘user goal technique’. After that, I briefly described the use cases saying what the actor does and what the system does in response. This allowed us to create a use case diagram, which showed the actors interacting with the system and the use cases involved in these interactions. Next, I also created part of a class diagram for the rate barista system to model the data that the app needs to store. I created four classes but there was also a bridge class to simplify the many-to-many relationship between customer and barista. From there, I considered the states through which one or two classes may go across the use cases. I showed these states in a state machine diagram for the barista class and for the customer class. The thing to note about state machine diagrams is that the states are always in the past tense because they describe a state that the object has arrived at. Having done that, I then developed a fully develop use case description for one use case, register barista. It was a useful exercise because the flow of activities in that table allowed me to create my next model, which is the system sequence diagram. The system sequence diagram describes the interactions between an actor, in my case the café manager, and the system. The actor initiates actions and the system respond passively with output. I also drafted a context diagram and part of diagram 0 (data flow diagram) for backward compatibility. The context diagram showed me the actors involved in the system and the system as a black box. There was no number in the context diagram. The diagram 0 showed four processes each of which mapped to a use case. Upon reflection, this method was effective as evidenced by a significant improvement in the progress rate for this subject and exceptionally good SES scores. In the face of the success of this strategy, I have decided to adopt it next year in my teaching of Ethical Hacking (ITC398). I will let you know how I go.Period | 2022 → … |
---|---|
Held at | Computing, Mathematics and Engineering |
Related content
-
Prizes
-
Change One Thing Award
Prize: Award › Internal award