This assignment has three parts. Part A consists of making the team and app preference list. After I have received the team memberships, I will assign the app and have directory spaces made for you. Part B consists of selecting a team name and making the email list for your team. Part C is writing the initial design documents for app design.
Part A – Team and App Selection
The project is a semester long team project: designing and implementing an web app. The team size should be about 5 or 6 students in CS4760 and 2 or 3 students in HU4628.
While choosing teams consider schedules, jobs, where prospective members live and work, and anything else that might impact how well the team will function.
I also advise that one of your team members knows about databases or is interested in learning about databases. Each project will make a database and provide access to the database. It is not necessary for your database expert to have taken the database course, but the database expert will need to have basic understanding of tables, their use and familiar with SQL queries.
Also, useful for your team would be a team members that are already familiar with Web backend (scripting) and frontend (html, css and javascript) programming. All members do not need to have experience with web or database programming, you will learn web development, but a member with prior experience will be able to help with the initial app code design and getting programming started. If you have any experience with web or database programming, please try to find a team that does not have experienced members.
You should schedule meetings well in advance to ensure participation of all team members. During your meetings, take notes on your design decisions and how you reached your decision, so that you can use the notes in preparing your reports. Record your notes in the post meeting form (resources/PostMeetingForm.docx) and upload them to your project directory and website.
Application Selection
Your team should list your preference for the applications from the list in the link below:
List the applications in order such that your first choice is first on the list, second choice is second on the list, etc. All 6 applications should be on the list.
GitHub Account
Your team will get a repository on GitHub, therefore you need a GitHub account. If you do not already have a GitHub account get it now. You will need it for Part B of this assignment.
Email Me
Your team should send me (pastel at mtu.edu) and Karla Kitalong (kitalong at mtu.edu) an email by 5 pm on the due date of Project Assignment 1 Part A. The subject line of the email should be
cs4760-hu4628 Part A Project Assignment 1
Be sure to copy the subject line exactly. I use it to search for your email in my inbox.
The email should include:
- List of members’ proper names
- Application preference list
Please send the email promptly because I need time to have your group directories setup.
I will use the order that I receive the emails to resolve conflicts between teams’ app preferences, meaning if two teams choose the same app as their first choice then I will assign the app to the team that emailed me first. I will also use this order to resolve scheduling conflicts. Emailing your team’s selection first will be a distinct advantage throughout the semester.
Part B – Team Name and Email List
After I have received all the emails from Part A, I will assign the apps to teams. Then your team should choose a name. The name should make all of you proud, but it should not be too long. The name should also represent your project. If your team name is inappropriate I will change it.
Each team should have two leaders, a project technical lead, and a product owner. The technical lead will take the lead on the implementation concerns; the product owner will take the lead on the clients and users’ requirement concerns. Two leaders will collaborate to help coordinate the team and should share the responsibilities with all other team members.
Your team should also make an email list for your team. See
http://www.mtu.edu/it/services/email/
Make this email list immediately so that the graduate student can contact you. Also, add me (pastel at mtu.edu) to your list.
Team Charter
Your team will make a team charter. In the team charter you will give your team name. You will also list all team members and contact information: name, email address and phone numbers. The team charter describes the team’s and individuals’ goals. In addition the team delineates how the team will govern and the expectation of members. See Teams lecture notes.
The form for the team charter is in the resources/TeamCharter.docx.
Meeting Minutes
Your team is to keep meeting meeting notes and post them on the team website. This a lecture about teams for a detail description of meeting notes. Karla and I plan to study your team process and plan to use your meeting minutes to learn the details of your team process. So, Karla and I request that your minutes contain:
- Team Name
- Date, time and duration of the meeting
- Location or Media of the meeting, for example “in-person at Reki 101” or by “Google Hangouts”
- Attendance – list of team members present at the meeting.
- Action Items – list of tasks and team member assigned to do the work
- Discussions, Decisions and Rationale – list of topics and decisions made with rational for the decision.
- Next Steps – list of topics for the next meeting
Post your meeting minutes on the website immediately after the meeting.
Scientist Meeting Notes
Your team should make notes during your meeting with scientists and post them on your team websites. These notes are different from team minutes. These meeting notes are for recording all that you learn from your meeting with the scientists. So you will try to record as much as you can during the scientists meeting. See my lectures on interviewing for more details. Karla and I plan to study the interaction between your team and scientist. We plan to use your scientists meeting minutes to learn the details of your interaction with your scientists. So, Karla and I request that your notes contain:
- Team and Scientists Names
- Date, time and duration of the meeting
- Location or Media of the meeting, for example “by Zoom” or “by Phone”
- Attendance – list of team members and scientists present at the meeting.
- Discussion items – list of items discussed with specifics about the topics.
Scientist meeting notes should posted on the your team website immediately after the meeting
GitHub Repository
Your team will store code in a GitHub repository:
Each team member should have a GitHub account. So if you do not already have an GitHub account, you should make an account now. I will need your GitHub account name to add you to the team.
When I assign your team to a repository, you will get an invite email from GitHub. You need to respond to the email in order to have access to the repository. The GitHub user interface does not allow me resend the invite, so be sure to respond to it. I will announce in class that I have sent the GitHub invite. If you did not get the email, check your trash or spam email folders.
Submit on Canvas
Your team should submit on canvas:
- Team name
- Team email address
- Team leader names and team leader role
- Table of team member name and github name in Excel or CSV format. HU students do not have to have github accounts or name.
- PDF of your team charter. You should add the team charter on to your team drive.
Submit on canvas by 5 pm on the due date of Project Assignment 1 Part B.
Part C – App Summary Document and Burndown Chart
App Summary Document
Immediately after your first meeting with your scientist, you should write an App Summary Document which gives a brief description of the app that you expect to design and implement. The App Summary Document is a one or two page document which includes the following sections
- App Idea – a few sentence description of the main purpose of the app and what it will enable.
- Users – a list of different user types with a few word description of the user and their role using the app.
- Major Workflow – This is a list of the major interaction using the app for each users
- Data – List of general data types. This is NOT a detail list. For example you could list “form data”, “device gps coordinates” and “photos.”
After the first meeting with your scientist, I will ask you to read your App Summary to the class. We will discuss the different aspects of your App Summary. You should use the discussions and your App Summary to delineate what aspect of the app design is missed and prepare for your second scientist meeting.
After the second meeting with your scientist, you should write an updated App Summary Document. After you have made your team website, you will post your web app summaries on your website.
After making each version of your App Summary, email the app summary for your scientist to review and comment on.
Burndown Chart
A burndown chart shows the remaining work to be accomplished on a project over time. The ordinate of the chart is a measure of work or effort and the abscissa is a measure of time from the beginning of the project to the delivery date of the product. Ideally, the graph shows a steady decline of work remaining on the project over time reaching zero at the delivery date. A burndown chart does not always show this steady decline. The graph can show an increase in remaining work if the scope of the project is increased or the tasks of the project were a poor estimate of the work.
A burndown chart is a tool for monitoring the progress of a project and to predict the completion time for the project. The creation of a burndown chart is a planning activity because the team needs to delineate tasks of a project and estimate their values. Performing this activity during the initial phase of development affords the team the opportunity to think about the complete project before getting bogged down in the details of design and implementation.
Burndown charts are a popular tool for the Scrum development processes. A burndown chart is made for each iteration (sprint) and is a tool used to monitor the progress during the sprint. The chart can be used to refine later estimates on user story values and sprint efforts. This course is not using the Scrum development process. It uses a process that I called “Scheduled Rapid Development”. Although the course does proceed by prototype iterations, these iterations are not equal size or effort. Consequently, we will use the burndown chart to monitor the entire development of your projects.
As a team, you will create a burndown chart that you will maintain throughout the semester. To create the burndown chart, you need to create a list of tasks for the project and estimate their effort or work. You can use the course project assignments as a guide to create the project task list. You will need to estimate the effort or work for each project task. The measure of work or effort for the tasks should not be an absolute scale such as person-work hours. Rather, the measure should be relative. Meaning that it can only be used to compare the effort for one task to another. By reading the assignments, you can make your estimate of effort. Some tasks/assignments will be obviously easier than other. The resolution for the measure of effort should not be very refined. It is sufficient to identify that one task is twice as hard as another. A popular scale to use for effort is the Bernoulli scale. If you feel that you cannot make this estimate then give each project task the same value, for example 10.
Besides the measure for the estimate of project task effort, you need to construct a timeline. I suggest using weeks. So the burndown chart will have 15 weeks including final weeks. If you plan for your team to meet twice a week, you may consider a higher resolution for time, for example twice a week.
I have created an Excel template, empty worksheet with formulas, that you can use to make your burndown chart.
The worksheet consists of two parts, a burndown table and a burndown graph. You list the project tasks and their estimated in the burndown table. You monitor the progress of your project by entering how much effort was performed on the tasks for the week. The burndown graph will automatically display the progress of your project. I have created an example spreadsheet using the template.
Open the spreadsheet. Look at column A which is the Product Backlog Inventory (PBI). The tasked named as “Task 1”, “Task 2”, etc. were identified at the beginning of the project and given an initial value, in this case all the tasks have effort value 10. The tasks named as “Add task 1” and “Add task 2” were tasks identified after the project started. I will speak more about them later. For now, look at row 5 after the “Initial Estimated Effort”. This row is the header for the timeline, The headers numbered 1, 2, 3, etc. are the numbered week for the semester. (Note that the column for the “Initial Estimated Effort” is given the week number zero so that the graph plots properly.) The cells below the timeline are filled with the amount of work that was completed for the task. For example on the first week, 5 points of work were performed on “Task 1”. During the second week, another 5 pt of work were accomplished on “Task”, completing the task, and 10 points of work for “Task 2”. You can look at the burndown graph to see the effect of the effort during the first two weeks. The blue line represents the actual progress of the project while the orange line represents the ideal progress for the project. At the third week, the actual progress drops below the ideal progress. This suggests that the progress of the project is ahead of schedule. In this case, the amount that the project is ahead of schedule is small and probably does not mean much because the effort estimates are not accurate.
Look at the rows for the project tasks that were identified after the initial estimated effort, “Add task 1” and “Add task 2”. The row for “Add task 1” has a cell with “-20” for the third week. This indicates that “Add task 1” was identified during the third week and given an estimated effort of 20. We must entered a negative number for the estimated effort because a positive number would indicate work done by the team. Look at the effect on the burndown graph. The actual progress is above the ideal progress. This should not be a concern. It represents that the team has expanded the scope of the project. An alternative method for adding the estimated effort for the task “Add task 1” would have been to enter “20” to the “Initial Estimated Effort”. I do not prefer this method because it will completely change the graph causing the total initial estimated effort to increase to 120. Also the technique does not indicate when then the task was identified and does not appear on the burndown graph. Look at the row for “Add task 2”. The task was identified during the sixth week and given an estimated effort of -30. The effect on the burndown graph is very similar to adding the “Add task 1” task. The ideal actual progress of the project is again above the ideal progress.
Look at the row for “Task 8”. In the cell for the fifth week, the value -5 was entered. It is not possible for negative work to be done on a task. Rather, it represents that during the fifth week that the team identified that the effort for “Task 8” was harder then their initial estimated work. Again the initial estimated effort for “Task 8” could have been corrected, but entering the negative number during the fifth week is better. It records when the team identified the poor estimate.
The team is responsible for creating and maintaining the burndown chart. You do not have to use the Excel template that I provided, but whatever you use, it should provide all the information that my template provides. On your team website you will provide a link to download your burndown chart spreadsheet. In addition, the burndown graph should be prominently posted on your team website, such as on the website home page. To post the graph on your website you will need to use a second application, such as Microsoft Word. You copy the graph from the spreadsheet and post it into Microsoft Word as a picture. Then use Microsoft Word to export the image to a file. The PNG format is good. You do not need to save the Microsoft Word file after the export. The PNG that you have created can now be added to the website. You should keep this graph up to date weekly.
Submit on Canvas
Submit on canvas your initial app summary and burndown chart spreadsheet before you present. I will give feedback during your team presentation.
CS4760 & HU4628 Students Collaborating
Throughout the semester, students in CS4760 and HU4628 will work together developing the web application and make up a single team. Be sure to keep the students in both courses involved in the design of the app and informed on its progress. In particular, the HU4628 students are responsible for leading the effort on creating the burndown chart. The HU4628 students are also responsible for ensuring that the burndown chart is current and posted on the team website.