Sprint 1: Requirements Gathering

Scrum Master: Prince Ofori

GUI: Ben Adlington, Barnaby Smith

Design: Michael Hancock (Domain Model) , Charles Hackett (Use Case Diagram)

Testing: Alice Hodkin

Requirements:

  • System must have a GUI, the more aesthetically pleasing the better
  • System must be able to connect to the stock market system, the server code will be provided
  • The system must be automated to buy shares for the highest possible profit
  • Stock must change a predefined times
  • Show currently owned
  • List Profit/Loss
  • All systems start with £10,000
  • Request current stock portfolio
  • List details for share value
  • User Feedback

Prince Ofori – Scrum Conclusion

Sprint 1 Scrumdesk overview

Sprint 1 Scrumdesk overview

 

The image above depicts the completed tasks of Sprint 1, as scrum master I allocated tasks and roles to the members of the team and managed the documentation of the to support the progression of the project. Using Scrumdesk tasks were created with an estimated completion time and effort level to define the importance of those tasks to the success of the scrum. The time which each team member spent on their given task within this sprint is also represented graphically in the side bar of the user interface.The role as scrum master also required gathering the requirements from the client and relay this information to the team. The importance of these features and the role that they held to the  implementation of this software artefact, moreover it identified an appreciable difference between other software development methodologies that the group had utilised in the past.

Scrum unlike sequential methodologies such as the Waterfall enables an amount of flexibility that the former does not due to the iterative nature of the methodology.  Within the first sprint all members of the team played an active role within the preliminary steps of development, in contrast to Waterfall and Spiral, both which are rigid in the steps in which the team members can interact in the development of the design Scrum improves on the communication and interaction with all members of the team across varying stages of the Software Development Life Cycle.

Ben and Barnaby – GUI

design 1design 3

In sprint 1 Ben and I were set the task of designing the GUI, we used paint to create a simple layout of what we would like the GUI to look like, this was before we had received exact requirements from the domain model and so was designed as an estimation of what the GUI could look like. After receiving the requirements from the domain model we then used the NetBeans IDE to create a more accurate GUI. This uses lists to display the available and owned stocks to the user and a simple buy and sell interface. It also clearly displays the profit value of the stocks that you own. Other more advanced features are held in the task menu, such as automation, connection and disconnection to the server.

 

Alice Hodkin – Testing

Scrum Test Cases 1testCases_sprint1

In SCRUM, test cases can be written before any programming or GUI design has begun. These may need editing in later sprints to reflect changes in the needs and requirements of the system. To create these test cases, I made a table that will provide a base to use for basic black box testing, adding tests based upon the results of the client meeting.

Once the GUI was produced, I added extra test cases to test the feature specific to the GUI design.

Charles Hackett- Use Case Diagram

For this sprint I was delegated to do an UML Use Case diagram, a Use case diagram is a simple way of explaining how users will interact with a system, as can be seen in the image bellow the shareholder will be able to view previous transactions, view the gross profit, and view the shares list of the current shares that they own, the system will also have an automate ability which will automatically buy and sell shares for the user in order to make profit.

Use case Diagram

Michael Hancock – UML Domain Model

For the first sprint, I was assigned the role of design by the Scrum master. Here I was to propose and visualise the UML domain model. This was an important role especially in week one, since this design would be use to put together the initial components of the systems during development. For our first sprint we dedicated two weeks, this task took me all of that time since I was unfamiliar with UML and had to re-learn how to use it.

Using the initial meeting with our client, I was able to sketch out a basic outline for the system. I worked closely alongside Charles Hacket whom was developing the UML case diagram, we discussed potential system layouts and designs; particularly how the elements of that system would interact. I found this particular sprint quiet challenging since I am less than adept at UML, however it was helpful to have two people working on design so we could discuss the system together. I also spent time discussing the system design with both of this scum’s developers, since they would be developing the design I provide. The final output domain model is shown.stock