Category Archives: Sprint 2

AMPATH-WSU Sprint 2 Retrospective

And the issues continue… 😦

Hello dear readers, welcome to my second retrospective blog post. I don’t know why did I decide to switch to using MAC laptop on the last semester of school. As I mentioned on the first spring blog, I was able to fork and clone the code but was having issues in the terminal when trying to build the code. We figured out that the build environment was not fully set up and there was also something else wrong. To be honest I got pretty mad at MAC as I was having issues in another class for installing a virtual machine. I had an old windows laptop at home so I just started to install everything form beginning on that laptop. Sam, my other teammate which is also a MAC user had issues but different ones.

I would like to mention that I really like the way our team works. Kristi was able to help me and Sam with the issue of building the project locally. We always help each other and we don’t leave any of us behind. In my opinion this is a very important behavior to have in a team because that makes a team more productive and brings the teammates closer to each other. StackOverflow and Google helped a lot as well. Realized other people had had similar issues in the past as well. I would strongly suggest to research about the environments and tools you are going to use before you start installing them.

After we made sure that everyone was in the same page and each of us had everything set up we went and checked our to do tasks. I mentioned in the first sprint that that spring felt like a research sprint, I would say that this sprint wasn’t that different either. Actually I was not expectingΒ  to start development right away as we were exposed to new tools. I would like to say that even though we haven’t started with development yet I am very happy about all the material that we are learning as its very useful and gives us a great experience.

Before the end of the second sprint we were notified that the developers in Kenya gave some additional information to our professor about what do they want the app to look like and what are some of their requirements. I also know that they send us videos of the wire-frames. This will allowΒ  us to analyze the requirements and apply all the knowledge we are learning in the CS-448 (Software Process Management) class. We are all very excited to get started on watching the videos and start working on this project.

I would say that we did a lot of learning during this sprint and I would like to assume that the next sprint will be the same as we are going to study, analyze the requirements given, and separate out duties within the teams and within each other. I opened a few of the videos that Greg had posted for us and I am really excited about this. I can’t wait to let you guys know where’re we at by the end of next sprint.

From the blog CS@Worcester – Danja's Blog by danja9 and used with permission of the author. All other rights reserved by the author.

Another Sprint, Another Retrospective

Hello, again my dear readers! Another sprint has passed and as such, it is time for another sprint retrospective. These couple sprint weeks has left my group and me with a slightly lower than average workload. From the first two sprint weeks, not much has been added to the Trello sprint work board. The bulk of this sprint’s work was funneled into two major setup tasks.

The first of these major setup tasks was ensuring that each member of the team had the ng2-amrs software on our individual development environment. We also had to ensure that each person had it set up so that ng2-amrs could be built and run on each individual development environment. This proved to be a task that would throw more unexpected errors our way than I think any of us could have expected. Of the few in class meetings we did have, many were spent debugging and troubleshooting many of the varied npm errors that rose up to bother each and every one of us. My personal experience with installing ng2-amrs and getting it running was not the worst of all the ones in our group but it was not without its issues. I myself encountered three separate errors that stopped me in my tracks. However, thanks to the knowledge of my fellow peers both in and out of my group, they were solved. The rest of my fellow peers had similar troubles with the same bugs that I experienced and in addition, some new ones as well.

The second of the major setup tasks for ng2-amrs was for each team member to study and get familiar with Protractor and Karma. Protractor and Karma are both testing frameworks for Angular. Thankfully, there were easily accessible, available, and easily understood tutorials that were available right from the web sites of the two respective home pages of Karma and Protractor.

While not much happened these two sprint weeks, I can not say that it was spent lazing around or that it was quite unproductive or fruitless. Setting up the ng2-amrs was a good introduction back in to working with npm and was more than just learn the two basic commands of ng build and ng serve. In addition, I can now say that I am much more in tune when it comes to solving errors that might pop up when building an npm server. I have also learned what to search for on Google when a specific problem does crop up and wherein the error code to look to actually find the error that has actually occurred. Learning both Protractor and Karma was a nice change of pace as well. I remember learning how to test in my 443 class last semester and I remember that it was an interesting and enjoyable experience. Thus, this week two sprint retrospective comes to a close. Hopefully, in the next sprint, we will receive more messages from the project representative and be able to dive into something a little more relevant than just setup.

Until next time readers!

 

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

Sprint 2

This week finishes up sprint 2 of our senior software development capstone project. In this sprint we accomplished quite a bit. The most important advancement that we made in this sprint is getting specifications from our product owner as to what we need to do for them. At the begining of this sprint cycle we were able to meet with a representative from the food pantry, Serena. Serena was able to tell us more about the food pantry and what they are doing as well as what they would like to see as a product from us. One of the biggest takeaways from this meeting was to realize that the main objective for us is to assist the food pantry in their quest to transfer all their business and business operations from paper to digital. One of the largest problems we realized off the bat is that the food pantry does everything from data storage to daily operation by paper. We know as software developers that this physical paper way of doing things is very inefficient and can be vulnerable to human error (totaling numbers in wrong columns, incorrect data input, etc). Our thought was to help them by making software to help them transfer to digital and also do some automation for them so that they can avoid any possible human error. However, we as the software development team are not here to tell the food pantry owners what they should be asking for. There is a fine line that a software developer working with a product owner where you should suggest what you think you should develop for them that may be helpful while also staying within their guidelines. The biggest issue here is that the food pantry representatives do not have a definitive set of product guidelines and rather are open to any ideas we may have for them, as they currently are 100% paper and are looking for any help to go digital in a way that is useful to them. I enjoyed this part of the sprint because I got to interact with the people on the other end where we can talk about what we need to do and what we would like to do. After our meeting with the product owners we were able to start on our project. One of the group members started working on back-end development and was able to deploy a gitlab project for it. I started working on a front end HTML mockup of our worker client screen. Another member of the group worked on finding out how to parse a json file using gson. After our most recent sprint meeting we decided on tasks that we’ll start doing for the new sprint. More front end development will be done this sprint. This will be taken on by myself and another few team members. I specifically will be working on CSS stylesheets for our project. The other members will begin writing a Java program to connect our project to a database. In sprint 2 I learned a lot about project management and working with product owners.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

Not a lot has happened in the last two weeks. There has not been a clear assignment given to be accomplished individually or as a team. On the first class meeting of this sprint, I helped Matt get through the final errors to get the ng2-amrs, since he was seeing the same errors that I had seen and figured out how to get through myself. After installing the right version of node, and then following the determined steps to fix the series of error messages that come up after trying to run npm start, it says compiled with warnings and does not error and the AMPATH login page comes up when visiting localhost:3000 in a browser.

Once he got it running, everyone on the team was able to run it without errors, so we had nothing left to do but vaguely review some miscellaneous information about JavaScript and angular. After that, our team did not meet in class for a couple of days or class had been canceled. It was not until Thursday during the sprint review that we started to get something to do, but that was the last meeting before spring break, so we did not get a chance to actually start anything, only to look at the new information that has been given and begin to process it.

From watching the first of the six AMPATH videos that we were sent, it looks like we are being given an existing user interface and it is up to us to implement the desired logic and behavior to have it interact with the medical records back end. The videos walk through some of the buttons and elements that were already placed together on the front end, and some specifics are described about what the elements are supposed to be for and how they should interact with the medical records data. From here on, we will finish watching the rest of the videos to better understand what they explain and what is expected of us, and we will have to decide among the other teams who is doing what, and figure out what it is we are actually going to be doing and how to do it. From what I have understood so far, I think that we are going to need to read a lot of the code that has been written so far, and then while we are writing more code to implement the new front end features, we will be referring to the existing code in order to find out how to access or manipulate certain data and objects. Depending on the amount of documentation that exists, it is possible that we may need to come up with our own documentation just to keep track of how everything works. I think that our previous experience programming in typescript during the last semester should be helpful while writing the code for this, although this does seem like it is going to be significantly more in-depth in certain areas.

From the blog CS@Worcester – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective Blog

Our second sprint was much more productive than the first, thanks to our meeting with the representative from the food pantry. During the meeting we were able to gather a lot of information about what they needed from us. Currently, new users fill out a Google form which determines what level of aid they qualify for. This is something that we would want saved and automatically determined when that user comes to the food pantry. One of the main issues they’re currently having is that employees have to manually track the weight of their current stock. So every donation they receive they have to measure its weight and then manually enter the weight of the donation as well as what types of items were received. This is the main task we’re working on finishing this sprint. For this we should be focusing on making small quality of life improvements (such as automatically adjusting the total weight) and work from there. I’m interested in seeing if it would be possible to connecting to a scale to do this automatically after weighing a donation, but that’s something that should come later.

From the meeting we were able to figure out some of the food pantry’s pressing needs that we could address. I feel like we were able to devise clear goals to work towards.

After the meeting was over I believe we may have ran out of time before assuring that everyone knew what tasks were assigned to them for the sprint. During the sprint I think this was cleared up as Nick had already begun re-purposing one of his previous projects for the food pantry and let us know what he needed help with. Although, since we missed a couple of meetings we ended up making less progress than we could have.

During our retrospective, Nick showed us and the representative from the food pantry the progress he made on the new worker intake form. It’s definitely a step in the right direction. Once it’s cleaned up a bit I think it’ll be better than what they’re currently using. One thing we need to do is to make sure that we create something that actually makes it easier for employees at the food pantry to do their job. For this project in particular, we need to solve the main bottlenecks that they described: manual data entry and calculations. These are things that can easily be solved by automating the process. It’s important that we create something that is an actual improvement from just sticking with the Google form.

Near the end of the sprint I was given a different task to work on. This was what we were initially working during the first sprint prior to the meeting with the employee from the food pantry. For this I need to create a REST API interface using the USDA’s FoodKeeper Data so Joshua Farrar can deploy it to Heroku. While we were working on this during the first sprint, we were all researching what we needed to do individually which I feel may have wasted a lot of time. The resources for REST APIs that Professor Wurst sent me have been useful, and hopefully I’ll be able to finish this during the next sprint.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Capstone Retrospective 2

Although we have not been given anything to work on from AMPATH, save yesterday’s meeting, I have made the most of my time to learn as much as I could about Angular. I haven’t gotten all the way through the tutorial, but I want to emphasize learning it throughly over rushing it.

The first time I was going through the tutorial, I was well over halfway done when I realized I was missing one of the steps to get it to work. This happened early on in the tutorial as well, and I resorted to blindly copying and pasting every step again to get it to work. It turned out to be a very minor fix. I was much further in this time, and I was about to do the same thing, but I realized I would be wasting my time if I did that. If I didn’t understand the code enough to diagnose these simple fixes, I am not getting much out of the tutorial doing it this way.

I was talking to members of my team about it, and we came to the conclusion that even if we individually only got through the first few sections of the tutorial, our time would be better spent if we understood what we were doing thoroughly over completing all the sections without as good of an understanding of the concepts.

Even though we have not been doing a lot of work together as a team for the clinic, it is really nice being able to bounce ideas off members of our team. It is great  to have the ability to share resources with people I am working towards the same goal.

It feels like I am living out some of the apprenticeship patterns that are laid out in the textbook for this course. I am challenging myself to learn new concepts, even without a looming test or set deadline. I have gotten better and better into the habit of carving out a small chunk of my time to learning a new concept here and there. I hope this continues as this course develops, and I hope to continue this trait for the rest of my life.

Yesterday, our group liked the idea of working on the projects described in the videos in part 2a and 2b. I liked everything that I saw, and would be more than happy to work on this. It’s not certain if we will be the ones who get to work on this, but we will coordinate that with the other groups. I am very happy to get started. This is what I’ve dreamed about doing since I decided to major in computer science. It is really exciting making that happen.

I also read a part of Edward R. Tufte’s book Visual Explanations, where he has a page giving an example of what an effectively-laid out medical chart might look like (p. 111). Although this might be the only example I could find on something for medical use, I think this book might prove to be a good resource for displaying the data. I’m sure there is a lot to be learned even from the examples that are not specific to medicine.

The most useful tutorial I have found comes from Angular itself. It is a really easy-to-follow step by step guide that holds your hand through the entire thing: https://angular.io/docs

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Sprint Review Blog # 2

Β Β Β Β Β Β Β Β Β Β Β  Our second sprint had little coding action and more of a personal learning aspect that we decided to focus on. I found that the team benefited from individual learning in a similar fashion to an independent study when trying to learn about important concepts like Mockito testing and Angular formats. We then compiled our individual learning resources into our slack channel to help each other find resources that others may have missed. This allowed an easier flow of understanding while also being able to bring us all onto the same mindset of where we were in terms of starting the project. I will proceed to understand the AMPATH format for their angular code and translate that knowledge to the requirement we will need to meet in the future. AMPATH members have recently posted videos and presentations of how they want their new interface to look with explanations for user interactivity. We want to continue to understand how we should edit and evolve the code already given to us and turn it into the final product that they want. We will have to communicate not only with our team member but the other teams as well to go over which functions should be divided up and worked on. This will create a better organization system for how we should communicate with other teams as well to understand any implementations that they will do which might affect our portion of the project. We learned about how the AMPATH project works through the videos which explained everything from selection tabs to navigation elements. It seems that this design concept may be similar to that of a mobile app from the setup of the mockup files which makes our approach much easier to narrow down. The most important aspect of this design seems to be simplicity with functionality for the patients and their doctors. The ability to create a smooth design is going to be complicated with different teams working on separate functions that are supposed to come together to create this app. It will require concise and mutual communications from several fronts that we will need to perfect over time. I predict that in the beginning it will be difficult to explain our coding schemas and ideas properly to each other but once everyone gets a taste of each other’s coding styles, it can be done with minor hiccups. We also need to decide whether we will stick with the idea of using a Mockito style for our testing or setup a server on campus to continue working with fake data. We have communicated with multiple teams about this idea and think that we should at least try to see if setting up a server is viable with as few hiccups as possible otherwise, we will have to look further into testing. I believe that setting up the server could work out well for every group, but it could cause issues with connecting and internal errors that we wouldn’t be able to figure out properly. It is definitely worth a try as it would be an interesting experience to understand and make it easier to test if we should be able to get fake data.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective – Round Two

            A reflection
on what I learned from this week’s activities is that when the working mindset
begins it goes quite smoothly. Once everyone settles in and breaks the ice, we
are able to communicate clearly and effectively what our intentions are and how
we are to go about it. When a certain task is finished, other members are notified,
and opinions are needed before we go any further with the task or beginning a
new one. When we get proper feedback, we are able to safely continue down the
path or create a new one to account for changes.

            Another
lesson learned from this week’s activities is that members will tend to focus
on tasks that they are comfortable with first. In my case, since no one was
comfortable picking up the role on working with databases, I felt confident and
comfortable enough to pick up the task. As for the other group members, they
also went off in the direction that would prove most beneficial to the group.
This way, the group will spend less time learning material that other members
are clearly proficient enough to get started. After that, we are able to
converse and teach our knowledge with the rest of the group members which is
quite efficient.

            In light of
this lesson learned, the next time there is a situation where the group is
clearly new to each other, and a project is being newly developed. It should be
safe to assume that everyone is not comfortable with each other yet and needs
time to adjust to the new environment and mindset. In this case, there is no
need to be anxious about the project over the course of several weeks as the
working process will natural come.

            During this
sprint, my task was mainly focused on creating a design for the database. This involved
reviewing materials provided by the client and any requirements or constraints that
are to be noted. The chosen route when creating a database to account for Database
Management System (DBMS), as such an E-R Model is required. The chosen platform
for the database is SQLite, we noted the importance of being able to export the
database file as a CSV file and vice-versa. Being able to obtain a CSV file is
important for the client as it’s their preferred filetype for distributing
information.

            Starting
off, I noted for four entities, staff, client, inventory, and items. In the
staff entity, it contained the attribute OneCard_ID
and a composite attribute Name which
accounted for First, Middle, and Last Name of the staff member. For the
client, it contains all of the attributes of the staff entity but introduces a
third attribute called Last Visit Date,
to account for information regarding the last time the client visited the food
pantry. Then you have the inventory entity which only contains the attribute Total Weight, since the pantry uses weight
to keep track of how much food is in stock. Lastly, the items entity contains
five attributes, Item ID, Item Name, Item
Weight, and Item Stored Date
. However, to account for a concern from the client
about confidentiality of information the names of staff and clients are later
crossed off from the E-R Model. In conclusion, after consulting the group, the
next step is to create and connect the database with the project in order to
fully utilize its intended function.

Β Β Β Β Β Β Β Β Β Β Β  Starting off, I noted for four entities, staff, client, inventory, and items. In the staff entity, it contained the attribute OneCard_ID and a composite attribute Name which accounted for First, Middle, and Last Name of the staff member. For the client, it contains all of the attributes of the staff entity but introduces a third attribute called Last Visit Date, to account for information regarding the last time the client visited the food pantry. Then you have the inventory entity which only contains the attribute Total Weight, since the pantry uses weight to keep track of how much food is in stock. Lastly, the items entity contains five attributes, Item ID, Item Name, Item Weight, and Item Stored Date. However, to account for a concern from the client about confidentiality of information the names of staff and clients are later crossed off from the E-R Model. In conclusion, after consulting the group, the next step is to create and connect the database with the project in order to fully utilize its intended function.

Β Β Β Β Β Β Β Β Β Β Β  Starting off, I noted for four entities, staff, client, inventory, and items. In the staff entity, it contained the attribute OneCard_ID and a composite attribute Name which accounted for First, Middle, and Last Name of the staff member. For the client, it contains all of the attributes of the staff entity but introduces a third attribute called Last Visit Date, to account for information regarding the last time the client visited the food pantry. Then you have the inventory entity which only contains the attribute Total Weight, since the pantry uses weight to keep track of how much food is in stock. Lastly, the items entity contains five attributes, Item ID, Item Name, Item Weight, and Item Stored Date. However, to account for a concern from the client about confidentiality of information the names of staff and clients are later crossed off from the E-R Model. In conclusion, after consulting the group, the next step is to create and connect the database with the project in order to fully utilize its intended function.

What I produced this sprint:

References:

https://www.geeksforgeeks.org/database-management-system-er-model/

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

Sprint-2

There was very little productivity during this sprint due to minimal work assigned. To keep busy our team used the time to learn about angular and testing in angular. One method that helped me learn more about angular was to do the Tour-of-heroes tutorial on the site. After doing so I understood why angular was used and what components really were and how they responded and “talked” to each other.

The final day of the sprint, we were given assignments that included creating the GUI of some sort of web application. Our team sat down and decide which interface we wish to move forward with. Before doing so we actually looked into what programs we were going to use and watched some YouTube videos on the instructions.

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

The IncreEdibles Sprint 2 Retrospective

This is the Sprint 2 Retrospective for team The IncreEdibles. We got assign to food pantry development, but we didn’t give any specific task. Big part of our team is design program and listen to the food pantry owner. There are two projects that we are working on, one is the make API that support other project where they can pull any information that they want. The other project is to work with Worcester State University food pantry.
As a group we decided to focus on WSU food pantry since we see more potential in this project. First, we want to know what the important features that costumers want. We learned that setup with costumers is not easy, not just to set the time and place for meeting. We have setup our communication on Slack, but most of the costumers are not in tech they don’t want to install complicate software. They want to have program where simple β€œplug and play”, so their energy can focus on what important to them. This is the problem that I think we always face with customers. We as developers before the meeting need to have set of question to ask, not all customers know what they want. We had meeting with Joanne, the professor who run the program. She wants to know who goes in and how much they take out the food, keeping track with the amount of food (by weight) is the main feature.
We took notes from the meeting and make email as direct communication that convenient for both parties. These features are important, but we must think of the design future features as program getting update. Features that they don’t think they need at this moment, that mean we must track data. These are sensitive data, we must be caution. The features seem not difficult as keep up with the weight of the food, but we want to have reliable program where it’s simple and easy to prepare/add feature.
There are few techs that our group need to know, OneCard swipe machine, we need to know that it is operative and how to implement to our program. How to export from the β€œsign up” Google Form. Export form that the costumer can export to submit to Worcester Food pantry. And most important is design our program where it is simple, clean and it do what it’s supposed to do.
Our next step is researching all the techs to make all priority feature work. Make a mock program, and present/sell it to the costumers. In this sprint we want to know how far we can get this program to work. There is other group in different section also look at this program, our problem is time difference and communication. If they have the same direction as us, we should find a way to divide the program into two parts that two group could work on. We find that the communication is one of the biggest problems even with members in the same group.

From the blog CS@Worcester – Nhat's Blog by Nhat Truong Le and used with permission of the author. All other rights reserved by the author.