comp730:MeAndYou Spring 2017 Tiffany Munsell Log


 * Home
 * MeAndYou
 * Semesters
 * Spring 2017

Week Ending March 28, 2017

 * Task:
 * This week was the first time that we were able to see the MeAndYou project and source files that were developed by the 2016 class. Each group member was to review the source files so that he or she could become familiar with them. By familiarizing ourselves with the work that has been done allows us to get a better sense of the structure and how it integrates together.


 * The Wiki documentation needs attention and can use some updating. I will get clarification on the requirements and can start rewriting those.


 * I will work with John to come up with sample user data (20,000 entries) and load those into the database.


 * Jaden was researching best practices for storing MySQL data locally.


 * Results:
 * We discovered that only two people could remotely login to the server at any one time. The architects of all groups coordinated a time to log in so that copies of the files could be retrieved and saved locally. This way, each student would have a copy of the files to view and work from on their own computer. In doing so, we can simulate branch development as a branch identifies a concurrent development path requiring independent configuration management. Branches allow for the development of different features which can be done by different teams concurrently and merged into a single version later. Each person can make changes to a local version without modifying the original. The sequence of versions created by each team is a branch, and is independent from the versions created by the other teams. When versions of different branches need to be arranged, the versions are merged; a new version is created containing selected elements from both ancestor versions. We will need to pay close attention to the versions of each branch and check/test them for consistency before merging or committing them back to the main repository (the UNH server).


 * I was able to successfully run the project locally on my home computer. I did notice some inconsistencies with the util.php file and the config.txt file. In the util.php file, the following statement appeared to be looking for 3 parameters within the config.txt file.
 * $connection = new mysqli($textArray[0], $textArray[1], $textArray[2]);
 * However, the config.txt file only had 2 parameters listed:
 * 127.0.0.1,root,
 * I believe the connection needs 4 parameters in order to access the mySQL database as follows:
 * $connection = new mysqli('localhost','root', 'root', 'meandyou');
 * The above statement worked for me. It appears that the config.txt file is referenced in multiple locations, so it would be best to update that file with the additional parameters rather than hardcode them into the util.php file.


 * I compiled a list of the functional and non-functional requirements that we have so far and will go over them with Professor Jonas in class on Wednesday.


 * I checked into Mockaroo (www.mockaroo.com) which lets you create mock data to test applications. Mockaroo generates realistic data which can be downloaded and then loaded directly into a test environment using SQL format. Having the test database filled with realistic looking data, will be more engaging for a tester. Testing with realistic data will make the database more robust because it allows us to catch errors that are likely to occur in production before integration or release. Mockaroo can generate up to 1,000 rows of data at a time for free.


 * Plan:
 * Meet in class on Wednesday to discuss what were able to learn about the project from last year based on review of the source files. Did we have any issues running the files? Do they make sense? What do we feel needs to be improved? What modifications can we make?


 * Decide on the final design for the database. There has been a lot of back-and-forth about the table names and design structure. We need to clarify and decide on this as soon as possible to that there are less inconsistencies when it comes time for integration.


 * Write queries to import large amounts of sample data.


 * Create test cases to test the database entries and how it handles duplicate data.


 * The current version uses password encryption for new user entries. However, the sample passwords that were batch loaded into the database via any of the create.sql files are not showing as encrypted. I understand that it is just sample data, but would like to check to see if there is a way to correct this so that the database is more secure.


 * Concerns:
 * Only one version of mySQL can be running at a time. If MySQL is installed on the computer, it will cause a conflict with XAMP, which is also trying to run MySQL. By default, MySQL will automatically start the MySQL server on startup. We will need to go into system preferences (Mac) or control panel (Windows) to stop the MySQL server before running XAMP. On the UNH server that will be hosting the project, it might be better to just uninstall MySQL since scripting will be done locally on our own computers.


 * We need clarification and confirmation of requirements from Professor Jonas. Requirements Elicitation is group activity completed with both the developers and client. Since Professor Jonas is the Project Manager/Product Owner/Client, I would like to make sure that he agrees with the requirements we have come up with so far.


 * Most of us are familiar with databases and coding with MySQL. Once the scripts to create the database and the queries are written and refined, what else can we do as a group besides updating the documentation?


 * Schedules and availability for group members greatly differ from one another. It seems like the best time to meet with each other is during class. We should try to come to class prepared with questions. It would be helpful if we could meet as a class (all teams) at the beginning of class to discuss what each group is working on and their plan for the upcoming week.

Week Ending April 4, 2017

 * Task:
 * Decide on the final design of the database.
 * Correct the database connection issue with the demo version on lamp.unh.edu so it runs properly (Patrick & Andry)
 * Generate sample user data (John)
 * Create ERD & class diagrams (Jaden)
 * Create test cases (Tiffany)
 * Confirm the requirements and update the wiki page (Tiffany)


 * Results:
 * At the beginning of class on 3/29/17, Bill led the team in a much needed discussion over the project plan. This was very helpful, because there had been some confusion about the project design and direction. We had the opportunity to work as a collaborative team and ask questions. I feel that it would be helpful to have these meetings at the beginning of class each week.
 * During the class meeting, the decision was made to use Bill’s data model. Upon further consideration after class, it was decided that this would be too time consuming to change the model at this time. It was ultimately decided that the project will continue to use the existing data model presented by last year’s team.
 * Andry and Patrick were able to correct the database connection issue for the demo on the server. Andry led our database group meeting on 3/31/17 and was able show the demo in action.
 * John is using GenerateData (generatedata.com) to create realistic sample user data. Using this application, he is able to generate and output the data directly into SQL format. Upon viewing the sample he created, I was impressed as it looks really good.
 * Jaden used Cacoo (cacoo.com) to create a class diagram of the database tables and their relationships. She also created a more detailed diagram that shows the tables, attributes, and datatypes. Having a well-designed ERD is very helpful when creating a database model, and she executed this beautifully.
 * I brainstormed ideas for what I would like to test with the database and overall project. I shared these ideas with Josh and Macuei via slack. Josh also shared some of his ideas about what is is looking to test with the front-end.
 * I presented my complied list of the functional and non-functional requirements to Professor Jonas in class on 3/29/17. He confirmed most of them and suggested rethinking and tweaking a couple of the others. These changes were made and I shared this with the other team members. I also updated the Functional Requirements and Non-functional Requirements sections of the wiki page to reflect these modifications.


 * Plan:
 * Go over and finalize the attributes list. What new attributes are being added when registered users choose to complete additional information in their profiles? The extra attributes will help increase the possibility of creating a match; the more information that is entered in a search, the higher the probability and confidence of the match between the intended users.
 * Continue working on developing the test cases based on brainstorming questions.
 * Continue updating documentation on the wiki page.


 * Concerns:
 * Keeping a large group focused has been challenging. Since everybody has a different skill set or experience level, there has been a lot of back-and-forth and indecisiveness.

Week Ending April 11, 2017

 * Task:
 * Create an Entity Relationship Diagram (ERD).
 * Create a master attributes list based on the ERD.
 * Write a query (insert statements) to populate the database with sample data (John).
 * Create a sequence diagram (Jaden).
 * Create Activity Diagrams to describe the use cases (Tiffany).
 * Create posters for URC.


 * Results:
 * I attempted to create an ERD based on my understanding of the database model. I have some outstanding questions about it and the model seems to change frequently. Because of this, I would like to discuss it when we meet in class on Wednesday. I did create an attribute list based on the ERD that I created, but I don’t think that it’s complete yet. Again, this is due to some questions that I would like to discuss in class.


 * John generated some sample user data and wrote a query to populate the database.


 * Jaden created a sequence diagram to to highlight the order of interactions between front-end and database objects.


 * I created six Activity Diagrams to describe the workflow and procedural logic of the agreed upon uses cases: Signup for Account (Registration), Login, Perform Searches, Modify Profile, Change Password, and View Notifications.


 * John and Jaden worked together to create the database poster for the URC. Graduate students across all groups gave input and created a combined graduate poster of the URC/GRC.


 * Plan:
 * Integrate the subsystems (GUI, database, software) on the server so that we can get an initial understanding of how things are working so far.


 * Get clarification on the database model and initial code to modify the ERD and attributes.


 * Continue to seek any new attributes that might be needed to modify/create a more complete profile.


 * Go over the Activity Diagrams with the front-end group to obtain their opinion and see if anything should be changed based on their new pages.


 * Concerns:
 * There is some general confusion with the database model and clarification has been requested. We can make modifications based on initial performance and integration testing.

Week Ending April 18, 2017

 * Task:
 * Install and learn SVN.
 * Tweak some of the Activity Diagrams.
 * Start initial unit and integration testing.


 * Results:
 * During class, Bill did a demo showing us how to use SVN (specifically TortoiseSVN) so that we can maintain current and historical versions of our project files including source code, web pages, and documentation. This was helpful because I’ve never worked with SVN before. It will also help now that we are starting to integrate our subsystems and only two people can be logged into the server at any one time. This allows us to still work locally/individually, but have access to the most up-to-date files. Everybody was going to try to install this on their own computers.


 * I shared my activity diagrams with the front-end group and got their feedback. I made some adjustments to clarify the wording so that it was easier to follow. Overall, their feedback about the logic was positive and it matched up with their pages.


 * In class, Will, Andry, and I started testing the webpages with the database. We were able to actively step through their pages to see their designs and new features. We also noticed that there was an issue with properly connecting to the database. It seemed to still be referencing the old database, and would need to be switched over. Also, when logging in, the page was accepting any username and password combination, as long as something was entered in each field. This was most likely related to the database connection issue, because it wasn’t validating the information before accepting it. Finally, we discussed the notifications and questioned whether they should be email notifications or strictly on-site notifications. Others seem like they should just be on-page alerts, such as confirmations, for completing forms.


 * Plan:
 * Make adjustments to the database based on initial integration testing with the front-end group. The software group is also testing their engine with the database. They will let us know what modifications and changes they would like us to make based on their test results.


 * All groups will upload their files to the server so that we can do a system test; it would be helpful to see how everything is currently working together. That way, we can identify any faults and have a chance to debug and make corrections.


 * Decide on how we want to conduct further testing. Do we want to use manual or automatic testing methods? If we decide on automatic testing, what tools are available and how would they be applicable to our needs?


 * Discuss the notifications further.


 * Concerns:
 * I am not sure how to incorporate and setup automatic testing. It might be easier to just manually load the sample data and perform tests by hand-selecting some of that data.


 * The notifications seem like they could be their own subsystem. It might be too much work to incorporate these in just a couple of weeks in the way we all envisioned.

Week Ending April 25, 2017

 * Task:
 * Continue to update documentation.
 * Modifications based on feedback from the software team.
 * Prepare for system testing as a class on 4/26/17.
 * Prepare for live demonstration to product owner for 4/26/17.


 * Results:
 * I uploaded all of my Activity Diagrams to the “Activity Diagrams” section of the Functional Requirements wiki page.
 * I worked on updating the “Introduction” and “Description of the Project” sections of the Functional Requirements wiki page. I tried to clean up the wording, created subsections, added more detailed descriptions, and tried to improve the overall readability of the document so that it is easier to follow and understand.
 * Andry and Patrick worked on updating the database code to reflect the changes requested by the software team.


 * Plan:
 * Now that all subsystems have been integrated, we are going to devote the first half of class on 4/26/17 to working as one large group to begin system testing. Identifying any bugs or issues early in the class, gives us an opportunity to correct them before our live demonstration at the end of the class.


 * Concerns:
 * Hopefully the product owner (Professor Jonas) is impressed with our results so far and can provide feedback and suggestions regarding further development. If additional features are requested, we will need to plan our remaining time accordingly so that we can accommodate these requests.

Week Ending May 2, 2017

 * Task:
 * Continue updating documentation.
 * Work on test cases.
 * Make database modifications based on feedback from the other teams.
 * Prepare for system testing as a class on 5/3/17.
 * Prepare for live demonstration to product owner for 5/3/17.


 * Results:
 * Continued making edits to the content and formatting of the wiki pages to add detail and value.
 * Query edits were made based on connectivity issues during last class.


 * Plan:
 * Since we were unable to do our system testing and live demo on 4/26, we will devote the first half of class on 5/3/17 to working as one large group with a demo scheduled for the end of the class. I’m sure we will find more bugs as we integrate, but we should be able to do our demo this class.
 * Continue finalizing test cases and reformat so they can be added to the wiki page.
 * Work on updating the Master Attributes section of the Wiki as it still reflects the work of the previous class.


 * Concerns:
 * Every time we think we are in a good place, more bugs are detected and need correction; this is the nature of software development.
 * Demands of other courses and end-of-semester are leaving less time for investing in the project.

Week Ending May 9, 2017

 * Task:
 * Update Master Attributes on the Wiki page.
 * System testing
 * Prepare for live demonstration to product owner for 5/10/17.


 * Results:
 * I updated the Master Attributes section of the Wiki page to reflect the work and changes that had been made this semester.


 * Various manual system tests to check the following test questions:
 * When registering, are all fields complete?
 * When registering, are the types of data entered correctly in each field (form validation)?
 * When registering, does the user exist in the database? If not, they can be created.
 * When logging in, does this user exist in the database and if so, were the proper user credentials entered?
 * Is sensitive data (passwords) protected/hashed when entered via the browser interface?
 * What happens when a user tries to create another account (duplicate entry)?
 * When performing a search, are the minimum number of fields complete? The search data will not be stored in the database, unless this is true.
 * When searching, are the types of data entered correctly in each field (form validation)?
 * Are attributes stored in the proper tables when registering, searching, or updating profile information?
 * Can users edit their profile information and does this update properly in the database?
 * Can users see the status of their searches and does this match what is in the database?
 * What happens if a user tries to exceed the number of allowed simultaneous searches?
 * What happens if a user tries to search for the same person more than once simultaneously?
 * What happens if a user tries to search for the same person more than once after the previous search is no longer active?


 * Plan:
 * Live demonstration to product owner.
 * Post-mortem discussion as an entire class to discuss what went well, what did not, and what could be done for future development.


 * Concerns:
 * Will the product owner be pleased with the prototype and the effort that was made by everyone involved?