1.9 Fifth Iteration

For the fifth iteration I had to:

1. Outline the logic that needed to take place to allow the swap
2. Implement that logic
3. Test the logic

Risks: 

• The main risks surrounding this iteration are in regard to the logic,  as there are many variables that I must consider. Therefore, maintaining and implementing these rules will be the biggest risk in this iteration.

• There is also a risk that I will not have identified all the rules and logic surrounding a swap. However, I plan on releasing an "Alpha" version of my application on the Google plan store in order to get multiple users to test the app and its logic. I may be able to identify other rules during that test period that I was not able to initially.

This application is designed to be catered toward each specific company that wishes to use this service. Therefore, there may be some unique logic surrounding each company. For example, company A may have rules that forbid employees from different departments to swap a shift. Alternatively, company B might allow this rule. Therefore, it must be noted that some logic may be unique to each company. However, I will implement a set of base rules that I can assume the majority of companies obey. The unique logic can be added at a later stage and catered to each company.

As stated above, the logic I plan to implement will be a broad set of rules that I can assume most companies obey. Many of the rules are trivial however could seriously break the application if not implemented correctly.

The rules I will implement are as follows:

1. A shift added into the swaps table cannot be swapped by the employee who added the shift into that table.
2. A shift cannot be added into the swaps table if the date associated with the shift matches the current date.
3.  Cannot swap a shift that is currently pending (waiting for an employee to respond to the swap) in the swaps table. 
4. Cannot swap a shift whose date has already expired.

Rules related to contracted hours are something I need to address. Many companies may have rules relating to how many hours an employee can work in relation to their contract. Some companies wish for their employees to work within their contracted hours while other companies are more flexible, allowing employees to work a broader range of hours making the contract the minimum amount of working hours an employee must adhere to. To overcome this complex issue, I plan to implement logic in a later iteration that will only allow for swaps to take place if they contain an equal amount of working hours. This way, both parties are catered for and that contracted hours are not affected. 

However, the issue is not completely solved. This application has the potential to allow HR to post additional shifts into same a table of "Extra" shifts. Employees looking for extra hours or an additional shift that working week could request that shift and add it to their current roster. Yet, the dilemma in relation to the contracted hours occurs again and even gets more complex as now a employee could potentially work over the legal amount of hours as well as their contracted hours. According to the Irish Organisation of Working Time Act, section two, part 15, "An employer shall not permit an employee to work, in each period of 7 days, more than an average of 48 hours". This would have to be implemented as direct logic into my application in a later iteration when I attempt to construct a table of extra working hours.

Implementing the logic listed from one to four consisted of a serious of "if" statements as I was able to implement quite efficiently as my shift and swap objects consisted of the correct attributes for testing this logic. I the only issue I did encounter was in relation to the pending swap rule. The logic in the rule compares an employees currently list of shifts to the table of swaps. If there is a matching shift, the logic gets executed and does not allow the employee to swap the shift. The issues lay in my REST calls. The REST call would be initiated to fetch all the swaps in the system to allow for a comparison between an employees current list of shifts. As I am using the Volley framework to make these calls, the calls are by default passed into their own threads and executed. As the calls were fetching data, my code would continue to execute even before the swaps data was gathered. This would throw a null pointer exception as there would be no data in the list of swap objects yet. Therefore, to overcome this, I placed my calls in the "OnStart" life cycle of the fragment. This would ensure that the call would be made at the very start of the line of executed code. Furthermore, I created a Boolean trigger that would be set to true when that data was gathered and false otherwise. I surrounded that swap logic with an "if" statement that would only allow access to the user if the trigger was true, ensuring that the correct data was gathered.

Once I had completed the logic, I ran my unit tests that tested each rule to make sure that they were behaving as I had designed them to. 

Overall, I was successful in implemented basic logic and rules associated with the swap process. For my next iteration, I will began my designing a basic log in and register element to my app.

Citations: http://www.irishstatutebook.ie/eli/1997/act/20/section/15/enacted/en/html#sec15