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.

Scrum Master: Alice Hodkin

UML:  Ben Adlington

Paired Programming: Michael Hancock , Charles Hackett

Test Cases: Prince Ofori, Barnaby Smith

Sprint Aims:

• Come up with additional test cases if necessary
• Complete use case diagram and start domain model
• Program the back end so that the socket can connect to the server
• Program the back end so that the code and the GUI can be tested

 

Testing – Barnaby Smith, Prince Ofori

These are the test cases for sprint for sprint 2. They are all black box for test driven development. They may need altering at a later date due to any possible changes that may occur.

Prince Ofori: Expanded

This sprint the role of tester was assigned to me by the scrum master, the primary task I and Barnaby were set was to define functional test cases that would inform the design of the application. Due to the nature of SCRUM the testing team of which I was part began writing the test cases whilst the development team were writing the code. This synchronicity is unusual in iterative development methodologies, SCRUM however allows the implementation of test driven development (TDD). The process of developing these test cases was not exceptionally time consuming and they were passed along to the development team to review their code whilst in the process of development allowing developers to develop code that passes the test and can be easily in future SPRINTS or releases.

The role of TDD in the development of the application cannot be understated. The short development cycle (1 week long SPRINTs) resulted in varying sub-teams within the group working at the same time, communicating between groups to inform and improve the development of the application was key to the increased productivity of this sprint as compared to the first sprint.

Barnaby Smith: Expanded

Ben Adlington – UML

Above is the UML that I have created for sprint 2. It contains a basic design for each of the classes for the application that we will be creating. These designs may need to be altered at a later time if more features are implemented due to the requirements changing.

Alice Hodkin – Scrum Master

Above shows the completed tasks of sprint 2, which were assigned using Scrumdesk, with some help from Prince. These tasks provided a clear graphical representation of what each team member needed to achieve during this sprint. When tasks were completed, they could be moved across the board. During this sprint, all of the tasks allocated were completed within the designated time, meaning that in the next sprint, new tasks that need completing can be assigned.

Charles Hackett- Programming-  Charles Hackett Pair Programming

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

In this sprint I pair programmed with Michael Hancock and we began developing the system in Java and created the socket which is used to communicate with the server, we used the ServerSocket and PrintWriter and BufferedReader Java Api’s to code the initial implementation of the system and this allowed us to successfully implement the ‘Helo’ command which is used to acknowledge a successful connection. During these programming sessions we encountered a couple of errors that can be seen in the pair programming log, the first of these was just a few small syntax errors as we where using Notepad and we missed a couple of things before it was compiled, the second error was also a syntax error where we did not use the right syntax in the While Loop as we tried using ‘Null’ instead of empty speech marks. We spent 4 hours coding and the time driving was 50%.

Michael Hancock- Programming

In this second sprint I had the role of developer with an emphasis on pair programming with Charles Hacket. We began work on the back end of the system. This included implementing class designs and the domain model myself and Charles had designed last sprint. Up to this point only work on the systems front end had been done. We both spent about 50% of the time ‘driving’, the rest of the time discussing implementation and trying to spot mistakes. Personally I found this quite a frustrating process since I felt like the person whom was driving, never really needed the help of another person. Rather their interruptions stopped the flow of development. It would have been easier/quicker if we have developed on our own on separate parts of the class design.

Another problem was that we both have fundamentally different programming styles, and at no point had any design pattern or convention for naming variables/functions/classes had been established. This made reading each other’s code a more difficult experience. Aside from this we did discover a few bugs when reviewing the code after. Including a threading issue and incorrect use of java’s .equals(“”) function. The resulting pair programming log can be seen below.