During the third sprint of my software development capstone, my team and I were assigned the task to figure how an offline data capture service worked and how it would work with AMPATH’s patient database. The reason for creating the offline data capture service is to enable the retrieval of patient data while in an offline status. This is important because villages in Africa may not have internet connection, but AMPATH still wants to add additional information to their patient database.
One thing that I’ve learned from this week’s activities was how to an offline data capture service worked. To figure that out, my team and I also created other small tasks that aid in figuring out the offline data capture service. Another thing that I’ve learned how to do as an individual was creating tasks from scratch. In addition to our product owner assigning tasks to each group, my team and I discussed on how to approach towards the goal of establishing an offline data capture service. This lead to the tasks that we created for us as a team to do. Throughout the entire process, I wouldn’t have done it any differently because everyone in the team, including myself, was productive in the way that we did things. This experience can be applied in real life situations, especially software development jobs. Since I want to be in the video game development industry, I’m going to have to learn how to approach the goals and objectives by creating my own small tasks that will lead up to completing the overall goal of a project.
What we did during the week was that we tried to create a balsamiq diagram which displays our idea on how an offline data capture operates. We also researched offline data capture services in Angular, and found more tutorials on them. We also checked out pouchdb and how it would be implemented in our offline data capture service and researched encryption to come up with ideas on how our offline data capture service would work cohesively with an encryption service that another team in our class was doing during this sprint. We succeeded in utilizing balsamiq to create our diagram of the offline data capture service, learned pouchdb, understood how an encryption service works, and successfully came up with ideas about how to interpret the offline data capture service by reading online articles and other resources.
The work quality for this sprint was adequate for all of us to do. From the past sprints up until this sprint, everyone contributed fairly if not more for some of us. I’d have to give a lot of credit to my teammates Rick, Jay, and Jerry as they helped me as well as the entire team on making sure everyone was on the same page. Jerry reminded the group about the standups. His contribution to the group has improved from the last sprint and I felt he communicated more in our meetings in class and on slack. Jay and Rick did an exceptional job of finding some resources about the offline data capture service and they both did well creating the diagram as well. What I did throughout this sprint was a lot of information retrieval which I shared as much as I could with my group about pouchdb, the encryption service, and about the offline data capture service. All of efforts played a huge role in getting us to where we are at with the offline data capture service right now as we are putting the pieces together with our diagram and our ongoing research.
Overall, creating the online data capture service is still an ongoing process. The team and I will still carry some tasks from this sprint onto the next sprint. A couple of these ongoing tasks include:
- Figuring out how pouchdb will work with Angular.
- Figuring out how encryption will work with our local storage system if we decide to work with local storage instead of pouchdb.