Scrum Master: Charles Hackett

Programming: Prince Ofori & Ben Adlington

UML: Alice Hodkin

Michael Hancock and Barnaby Smith unavailable this sprint.

Sprint Aims:

• Implement threads for sending and receiving of data

Prince Ofori – Programming

At the beginning of this sprint the scrum master reviewed the progress made within previous sprints in relation to the artefact. As one of the primary developers of the previous sprint was unavailable questions could not be posed to him as there were some errors within the program that I and my pair programming partner could not understand. This issue highlighted a problem within the SCRUM methodology as team members may become unavailable at the start of a sprint leaving a clear gap in knowledge for the duration of the sprint.

This sprint highlighted the need of a redesign of the artefact as the code was not implemented in a way which could easily be passed from sprint to sprint. Additionally the importance of pair programming in the dispersal of information across the team , additionally the support of a skilled programmer improved the overall speed we tackled issues within the sprint as opposed to the structured and somewhat restrictive nature of other methodologies where roles are defined throughout the development of the artefact.

Ben Adlington – Programming

During this week I was assigned to doing some pair programming work focused on introducing threads for reading and writing data from the server. The pair programming log below shows the time spent programming with and without my partner. The threading was implemented using “Implements Runnable” onto the required classes. This then allows for an overloaded function to be added to the class, this function (run) is used as a thread and is called throughout the program. Within our application this allows data to be read back from the server whilst other code is being executed. Overall there were minimal bugs or errors found whilst coding, mostly missing try catch statements around crucial parts of the code which were later added.

Alice Hodkin – UML

For this sprint, I was in charge of producing the UML diagrams. Whilst UML diagrams had already been made in previous sprints, the requirements of the client had changed slightly since then. Before any of the new requirements of the client could be programmed, they needed to be planned out, by creating UML diagrams.

The diagrams that I created were a use case diagram and a domain model. The use case diagram provided a clear representation of how the user should be able to interact with the newly specified artefact. the main development between this use case diagram and previous versions is the addition of the login stage, which will only allow registered users to access the server, which presents an additional stage for the user to complete before they can complete the tasks that they want to do.

The domain model was also developed to include a login class. Including this class was important in showing how it related to both the user and server, as well as clearly demonstrating that the programmed login class should not directly interact with the shares themselves in any way. Both these UML diagrams should aid the programmers in the next sprint, as the classes that they need to program have already been clearly laid out for them.

Charles Hackett- Scrum Master

For this sprint I was designated as the scrum leader so i had to delegate roles to the other members of the group and give them tasks to complete for this sprint. Using Scrumdesk I created tasks that needed to be completed and then allocated them to members of the group using the web application, I gave the tasks a level of effort that will be required in order to complete the tasks(a number out of 5) and also how important the task was(must, should or could). This can be seen in the image bellow.