IS480 Team wiki: 2015T2 Period Finals
|Home||Project Overview||Project Management||Documentation||The Team|
- 1 Powerpoint Slides
- 2 Project Progress Summary
- 3 Project Management
- 4 Technical Complexity
- 5 Reflection
- 6 Sponsor's Comments
Please find our Finals presentation slides here.
Project Progress Summary
Current Iteration: 10 (13/04/15 - 24/04/15)
- Overall Project Progress: approx 95%
- Currently performed 2 User Tests
- Uploaded to the App Store!
User Test 2
- To compare the time users take carrying out the tasks, to the time of our experts
- To identify tasks that take a significantly longer duration for users as compared to experts
- To detect issues that users face in using our application
- To learn more about the good and bad aspects of our application
- To gather feedback regarding the usability of our application
- To further improve our application based on the test results
Refer to User Test 2 in our wiki for more info.
Successful Upload to App Store
User Test 3
Number of Users: 58 users
Date: 11 to 16 Apr 2015
Duration: Over a period of 1 week, users will use MenstruTrack as a period tracker
Test Platform: iOS device with TestFlight application
Questionnaire Platform: Google Form
- To gather feedback from users using our application as their period tracker
- To analyze user behavior and identify pages that users visit more
- To gather issues that users may face
Refer to User Test 3 in our wiki for more info.
- Uploading our app the the Apple app store required our app to comply to many various rules. As a result, we failed on 3 attempts.
- Duration of vetting by Apple takes approximately 1.5 weeks each time we uploaded our app to the app store.
- Apple does not release its existing iCal app for open development purposes. Therefore we had to implement the calendar module from scratch.
- User interaction controls (e.g. extendable period bars) are not standard UI controls in the Apple library. Therefore we had to build various UI controls from scratch that interact directly with the calendar.
- Due to the shortage of time, we were not able to implement the "good to have" portion of the scope
- We have however, put in place some simple and basic google analytics for tracking purposes and as evidence of usage by users
Project Schedule (Plan Vs Actual):
|1||2 Sep 2014 - 3 Oct 2014||3 Sep 2014 - 9 Oct 2014||-|
|2||6 Oct 2014 - 5 Nov 2014||6 Oct 2014 - 5 Nov 2014||-|
|3||10 Nov 2014 - 5 Dec 2014||10 Nov 2014 - 5 Dec 2014||-|
|4||8 Dec 2014 - 9 Jan 2015||8 Dec 2014 - 11 Jan 2015||-|
|5||12 Jan 2015 - 23-Jan 2015||12 Jan 2015 - 13 Feb 2015||Delay due to complexity in building calendar module|
|6||26 Jan 2015 - 6 Feb 2015||26 Jan 2015 - 6 Feb 2015||Reduced scope for Profile development to focus on completing calendar|
|7||09 Feb 2015 - 20 Feb 2015||15 Jan 2015 - 22 Feb 2015||Used buffer time to catch up on functionality builds|
|8||23 Feb 2015 - 6 Mar 2015||23 Feb 2015 - 13 Mar 2015||Delay due to Calendar Module|
|9||9 Mar 2015 - 20 Mar 2015||13 Mar 2015 - 10 Apr 2015||Delay due to code clean up to ensure 0 crashes in order for successful upload to app store|
|10||Apr 2015 - Apr 2015||Apr 2015 - Apr 2015||-|
- Delay caused in finishing build of calendar in order to upload to app store
- Delay due to rectifying changes from comments during Mid Terms, integration issues
- Delays due to rectification of issues in order to achieved 0 crashes for upload to app store
- Code clean-up to continue in iteration 10
Lessons learnt from iteration 5 taught us not to under estimate coding tasks. This helped us better measure the time required by breaking down large programming tasks into smaller ones which are more manageable and predictable. Hence helping us reduce the fluctuations in the task metric measurements.
The Planned vs Actual Man hours depict the accuracy in allocation of time for individual tasks. Ever since iteration 5, programming tasks were better measured with lower variance. The only fluctuation that exists is in iteration 9. This is due to the fact that extra time and effort was used to rectify issues in order for our final push of the app to the app store. This took longer than planned, therefore a slight delay variation.
- No testing carried out in iteration 7 as there were no programming tasks
- More critical bugs were found after integration resulting in app crashes
Swift is a new language for building iOS applications. We chose to build in Swift to keep up with new trends. However, learning and developing in Swift pose a challenge due to the limited resources available.
During the development process, we realised that at some of the views, the keyboard will cover some of the text entries. This will be especially true for iPhone 4S because of the different aspect ratio (iPhone 4S uses 3:2 while iPhone 5 onwards use 16:9). In order to mitigate this problem, instead of just removing the development entirely for iPhone 4S, we developed an algorithm to allow the top of the keyboard to reach the bottom of the text field.
The process in developing the algorithm:
- Find the height of the screen.
- As the keyboard is defaulted, there is no way to change the animation of the keyboard, as such, the only way is to shift the background.
- As such, the amount to shift depends on a key ratio.
- To calculate the key ratio, we have to conduct the following mathematical study of the different screen sizes
To calculate the amount to be deferred, the universal formula that we derived is Screen Height/The y-coordinate of the active text field. After translating the algorithm to codes:
Period Forecast Algorithm
- To forecast when is the next period, using the most recent period data will be most appropriate.
- We used a simple weighted moving average formula to forecast the next period
- The formula uses the 3 most recent period data, the most recent one has a weight of 0.7, second most recent one has a weight of 0.2 and the 3rd most recent one has a weight of 0.1
- Our algorithm also removes all the outliers within the data. In this case, the outliers are cycle lengths which are <25 and >40
Cycle Stage Algorithm
- To know which cycle stage the user is currently in, we need a algorithm to be able to calculate. The algorithm is explained using the table below, accompanied by 2 scenarios
Auto Layout feature
- Designing for different screen sizes poses a great challenge to all mobile developers. In iOS, we are required to use the 'Auto Layout' feature which uses 'Constraints' to position the various elements to fit different screen sizes.
- Unlike a web platform, we are unable to specify the height for a particular element to be for example 50% of the screen. Therefore, we need to create our own grid system, which is customized for different views of the application
- To create a proper grid in a view, we have to use constraints to set it in the way we want it to be. After which we can then put in our elements.
- The picture below shows a rough guide on how to define the grid, putting in the elements after that, as well as the constraints that we need to create in order to create the view.
Building an iOS application with Swift was definitely a challenging task for the team, one in which we may have under estimated. Through this experience, we have seen in ourselves the ability to persevere, the aptitude for learning and the boldness to go against the conventional. Despite the initial setbacks and negative feedback, we remained determined to complete the application and to upload it onto the App Store. We chose to focus on what is good and work closely with those who supported us to have come this far. During this process, we had to constantly learn new skills beyond what the school has taught us such as the Swift language, usage of the xCode IDE, Apple's rules for uploading our application and the lady's menstrual cycles. We have come to realise that even something unconventional such as 5 guys building a female related application can be done because app development boils down to simply understanding processes, logic and algorithm which is something that can be achieved regardless of gender. In conclusion, we believe that tenacity, with a little luck, got our app accepted. A sleepless night of rectifying all issues for our final push has definitely paid off.
- In order to fully understand the code and framework, the team took an entire winter break to learn more about Swift. Two of the more reliable sources that the team was studying from is provided by Stanford University and Apple's Developer Guide.
- Learned the importance of understanding technical tasks and planning according to its complexity
- Have a better gauge of how long to plan for various activities for a more accurate schedule
- Had a first hand experience of the effectiveness of managing stakeholder and changes through formal means
Teng Yu Reflection:
We started something bigger than all of us. we have to finish it.
Initially when the team was formed, both internal and external expectations were very high as everyone see us as a strong and well-balanced team. Maybe it is because of this, we went ahead and challenged ourselves. As we venture further into the project, we realised that the mountain top seems further away instead of getting nearer. The climb was treacherous and mid-way, during our Mid Terms Presentation, we took a tumble and reality struck; that maybe we could never accomplish what we promised. It was demoralising but like a slap to our faces, we realised the severity of the situation. Instead of turning around and giving up, we pulled each other along and climbed together. Whenever someone faces a difficulty, we reallocated our personal time to help him to along; it was never about me, it is always about us. Throughout this journey, without the support of various stakeholders such as our supervisor, sponsors and professors, we could still be at the mid-way of the mountain. As we celebrate the success of reaching the top, one key reflection that I learn is "Nothing is impossible, it is just whether you want to do it". With the right mentality and perseverance, I am glad that my team has delivered our promises to our sponsors, supervisors and professors.
- In a project with a huge scope such as IS480, it is equally important to pay attention to the larger picture such as project management on top of the smaller tasks. For example, the goal of our project, what we plan to achieve, what is the value that we are providing to the users as well as the client, and not to forgot the plan that will make all these work out. In the previous modules that i have taken such as Software Engineering, the project was already properly scoped for us and we do not need to think about things like goals and accomplishments. However for IS480, it is different.
- In this project, I have to learn about mobile application development with a new language ‘Swift’ from scratch. Previously I had only experience with web development. As such, building a mobile application in a new language really put a test to my abilities for this project.
- Designing an iOS app possess a different challenge compared to a web application. In particular, designing for different screen sizes and managing the huge amount of interactions between the user and the application. This is a huge different compared to web development that i am more familiar with.
- Gained ‘Learning to Learn’ skills. In the field that we are in, there are always frequent updates and emerging technologies. We need to constantly upgrade ourselves and learn new skills. Thus, learning to learn skills is crucial to be able to adapt to changes.
- It is also important to look at the entire process/journey of IS480. I have overcame many obstacles and grew from the first day i took up this project till now. It serves as a very good learning point for future projects that i am going to take up.
- Unless you have many years and experience specializing in the particular development language and framework used for the project. It is impossible to plan the time required for programming task since the amount of code and the implementation steps are unclear.
- In order to make my estimations more accurate for the PM, I'll have to identify the implementation steps first (which means running through in my mind the HOW of building a function and module with the use of WHAT classes.) This is difficult early on, as we are unfamiliar with the technology, and should have done the research first before estimating tasks. However in this case, research does takes up time as well, and therefore we will always have to accept a task with a level of uncertainty resulting in an inaccurate estimate on time required.
- Many of the functions, and UI seemed implementable in concept, and we assumed that many of the operations and libraries will be available for us to use. However, we soon realize that while in web development, interactive applications with complex jQuery is an exception, in iOS development, the emphasis was on interactivity and interactive applications were the norm.
- We had to learn drawing of graphics, making objects translate, appear, change colors, control the state of various view elements... etc
- We spend more time learning than implementing in the initial stages, therefore we would have been seen as "not delivering" in the early stages despite being in the process of rapid internalization of the development concepts and implementation methodology unique to mobile development and objective C. Unfortunately, our main KPI is on the amount of work produced, and sometimes that may not be an accurate indicator of the amount of work and preparation necessary to make it happen.
We challenged ourselves by taking up a project with many uncertainties. For example, we had to learn a new language that little people can help us with and a topic we have no idea about. I have to admit that we failed several expectations and could have done better in many instances. However, what I have learnt from this project, is the importance of attitude. Obstacles and failures are just part and puzzle of life, but what keeps the team going, is the right attitude. It is the attitude to be positive, to be willing to learn and to put in your best that defines your experience. In terms of skills, I have surely learnt more about handling a full-fledged project. Everything we have learnt, from IDP, SE, PMSB, AA, are all put into use. In addition, I have also learnt to use new softwares like POP, iTunes Connect, xCode and Testflight. I have learnt to work with a team with different dynamics.
In all, FYP was a challenge. It showed me the difficulty of creating something that looked so simple to me previously. Most importantly, it showed me that it is not about how hard you fall, but how fast you get back up.
- Men who care ;)
- Care to take time and understand things you didn't previously, such as the context of this app, the specifics in a women's cycle, building an iOS app, the business aspect etc. Care enough to make sure the team delivers and produce an app useful to us sponsor.
- Care not just to make an impression but to deliver quality and professionalism in liaising with us.
- And most importantly, care enough to initiate and take charge of the project as though the app is yours.
Benefits of the Application
- MenstruTrack will help us in 2 main aspect. To keep connected and engaged with our current retail / online customers, and also to engage new / potential customers.
- These will help to increase our bottom line as well as building up our brand in the feminine care space. Future plans will be to include analytics and more targeted recommendations for customers.
- MenstruTrack can also be extended as an avenue for other consumer brands to reach out to ladies.
- Due to Apple's strict curation process, the launch was slightly delayed, but overall, we are very satisfied with the outcome.
- The team was flexibility in tweaking requirements according to UT feedback, and also took much initiative to think through the functionalities and nitty gritty of how the app should function.
- From many feedback given, ladies like the look and feel of the app - that is the first battle won.