Software Development Methods and Tools—CSCI-3308

Team project

Objectives

Purpose

The purpose of this project is to provide the basis for applying what you are learning in class to a software project as you learn. Group work is an essential part of computer science and help develop communication and teamwork skills.

Group Project Description

All students in Software Engineering Methods and Tools are required to complete a group project. Each group will comprise four or five people. Time will be provided during class to discuss projects. Teams will be assigned based on schedules. Teams must submit a project proposal, which must meet certain minimum standards (see Minimum Project Standards below), and have that proposal approved by the instructor.

Rules

Project ideas

Part 1 - Proposal, repository, project tracker, requirements

Due date

February 16, 2017 at 6:00 pm

A huge part of software development goes into planning, whether planning up front as in Waterfall or planning every sprint in Agile. Planning consists of the requirements for a project and project tracking software to keep track as you go (among other things).

You may opt for a Waterfall or Agile (or mash-up) approach for the project (you can change your methodology during the project as you wish).

You need to submit the URL to your repository that contains a README.md file with the following information:

Part 2 – Agile stand-up meeting, client demo, retrospective

Due date

Week of February 27, 2017

This is a 20-minute group interview grading meeting to be scheduled online. All group members must attend for credit. If you cannot find a time that works for everyone, you will need to email the instructor before the sign-up deadline to organize a different time.

One member of the team must sign up online for this meeting on Moodle. When you attend, you must present a piece of paper as you enter the meeting with your team name and a list of all members on the team (first and last name). There is nothing to submit online for this part of the project.

Standup

The first five minutes only will be the standup (you need to stand-up for the standup meeting). The purpose is to experience an Agile format daily stand-up meeting. In industry we usually take turns answer the following three questions:

  1. What did you do yesterday?
  2. What are you doing today?
  3. Are there any obstacles stopping you from doing your tasks?

We will modify this slightly to be “last week” and “next week” since you are probably not working on the project every day.

  1. What did you do last week?
  2. What are you doing next week?
  3. Are there any obstacles stopping you from doing your tasks?

These questions are not asked during the meeting. Someone just starts:

“Yesterday I worked on setting up the database so we can add the tables. Today I will be working on creating the tables we need. No obstacles.”

Then the next person goes.

Obstacles are specifically things that that someone else needs to finish as they are preventing you from completing the tasks currently assigned to you. Therefore, “I don’t know Ember.js, so I need to learn it” is not an obstacle because you can fix that. “I need the DBA to create the tables so I can start adding the data into the database” is an obstacle.

If you are late or miss the standup (the first five minutes of your scheduled meeting), you will get a zero for the standup portion. You can still get credit for the demo and retro.

Demo

The objectives for the demo are:

The first 5-10 minutes is the end-of-sprint demo. Create a presentation slide-show covering what you have accomplished so far (just 1-2 slides listing/describing/ pictures of new features) and then do a demo of the features that currently work (hopefully you have something!). Do not show code or the database – pretend your client is not a technical person!

Your whole group needs to be present in person for this demo. To experience what a remote session is like, you will create a http://join.me account and invite the grader to practice connecting a remote session. Join.me has a limit to the number of users logged in (free version) so only the TA and 1 or 2 team members will log in to Join.me. The rest of the group will look at one of their team’s screens.

Retrospective

Once you finish your sprint demo to the client, you will start the end-of-sprint retrospective. Read up on the techniques described here.

Your goal will be to have a set of team rules to use moving forward of things that worked well and what you want to improve on. Some examples may be: all team members need to use Google Hangout to easily notify the rest of the team if they are stuck or issues that arise; if a team member is more than five minutes late for a meeting, they have to bring cookies to the next meeting.

  1. Either hang a post-it on the wall or write on the whiteboard/chalk board for each category:
    • What went well (keep doing),
    • What didn’t work (stop doing), and
    • How we can improve (start doing).
  2. For the first five minutes each member will individually and quietly write out items for each category on post-it notes provided by the TAs (one note per post-it).
  3. When time is up, silently have everyone post up their note in the appropriate category.

For example, you may come up with a decision that “When a team meeting is agreed upon, all members will show up on time.” or “We get into these heated arguments, if someone calls ‘time-out’ then we will stop and focus on listing the pros and cons of each side.”

The idea at each Sprint retrospective is to help the team improve as a cohesive unit moving forward. This will totally depend on the team dynamics and every team ends up with different dynamics and different rules/guidelines.

Part 3 – Testing

Due date

April 6, 2017 at 6:00 pm

The purpose is to create two types of tests for your project:

  1. Automated test cases
    • Provide link to the tool you use to automate testing, or explain how to run the automated test cases, or schedule time with the TAs to demonstrate your automated tests.
    • Provide a copy of the output showing the results of the automated test cases running.
  2. User Acceptance Test plans

    The purpose of these tests is to have a formatted plan that you could provide to users to go through the steps in using your application and report whether it was successful or not.

    Provide at least three test cases formatted similar to the following.

    Use case name
        Verify login with valid user name and password
    Description
        Test the Google login page
    Pre-conditions
        User has valid user name and password
    Test steps
        1. Navigate to login page
        2. Provide valid user name
        3. Provide valid password
        4. Click login button
    Expected result
        User should be able to login
    Actual result
        User is navigated to dashboard with successful login
    Status (Pass/Fail)
        Pass
    Notes
        N/A
    Post-conditions
        User is validated with database and successfully signed into their account.
        The account session details are logged in database.
    

One member of your team must commit to GitHub a TESTING.md file with the following (in this order):

Part 4 – Individual interview

Due date

April 10–14 2017

This part is an individual interview meeting so we can learn about your own contributions to the project. This is required and failure to attend could get you a zero for your final project grade.

Part 5 - Presentation

Due date

May 1–5, 2017

The purpose of the presentations is to practice presentation skills, inspire your colleagues, and discuss the challenges you faced and how you got through them.

Your presentation requires all members to be present and standing up front. If you are not present for the presentation you will get a zero for the presentation portion of the project. Each team member must discuss something about the project during the presentation.

You should cover the following items in whatever creative way you wish.

You only have around 5-7 minutes (exact times announced in lecture) to present! (including setup time). Feel free to practice ensuring your computer hooks up to the projector the week or so beforehand. (Hint: to mirror displays on a mac, press cntrl-f1).

Hint: Because you have a limited amount of time to present, make use of images – remember, a picture says a thousand words! Designing good pictures/infographics can really enhance a presentation! You can show a picture of your repository or project tracker, etc. to show how you made use of the tools. Be sure to use a minimum of 20-point font for all text so everyone can read it.

Presentations should appear as if created by a single person but should clearly demonstrate that all team members were involved. A group or company should always present a unified front to a client/customer/etc. Therefore be sure there is consistency throughout your presentation (theme, colors, fonts, grammar, tense [past/present], etc).

Presentations will be during the last week of classes or so.

Please respect each other: On presentation days, please do not enter or leave the lecture room while a group is in the middle of presenting. Please wait until they finish and the next group starts setting up so as not to disrupt their presentation.

One member of your team must commit to GitHub the following:

Part 6 - Final Submission

Due date

May 4, 2017 at 6:00 pm

This last part will be graded based on the amount of effort, overall project, and use of tools and methodologies throughout the semester.

You must deploy your project and store your project source code, test cases, and documents in GitHub. To submit your project, one member of your team must submit a pdf with the names of everyone in your group and a link to these materials and access permission. The pdf document must have the following in the order provided as a list or table (not an essay!):

Be sure to:

Part 7 - Peer Evaluation & Project Reflection

Due date

May 4, 2017 at 6:00 pm

This portion of the project must be completed individually. The first part is to fill out an evaluation of your peers on the project. The second part is to answer a common potential interview question about working in teams. All members of the group must submit individually to Moodle

Project grading

Total project grade is 100 pts. Distributed as follows:

Overall effort (worthy of the size of your team) will also affect the grade. If you do not participate throughout in the project then you cannot pass the course. Your level of participation within your group will also affect your final total project grade.

Individual project grade = (sum project parts) * overall effort * individual participation

Assignment material by Liz Boese.