Guidelines for Final Project

Deadlines: Initial Design (2%): Due 7/23, Final Project (6%): Due 7/30

This is a group project (maximum 3 member teams)

Objective:

Design, develop and implement a working software system in Java. All code must be maintained on GitHub (See instructions on Canvas)

Problem Statement – Issue Tracking App

Congrats! You’re hired to create a system that mimics an issue tracking app such as Jira. This system will be used by project managersand other members of the team to keep track of the process of the whole project, individual milestones and individual issues. All users can access projects they are invited to, view/create/update issues. The project lead should be able to initialize a project, invite members to collaborate, create sprint/milestones, assign issues to members, etc.

Related Concepts / Terminology:

The main concepts used in this system are taken and simplified from Scrum, a process framework commonly used by software development teams. Here’s a quick introduction to Scrum which may help you understand these concepts better: youtu.be/9TycLR0TqFA?t=112

● Project: Each project board is composed of 3 main areas:

○ To Do: issues waiting to be assigned to a sprint, same as “product backlog” in Scrum

○ In Progress: issues in active sprints which are being worked on

○ Work Done: issues that have been resolved

● Sprint: a phase of the project development process with a fixed time frame (typically 1 or 2 week long). Each sprint contains issues to be resolved within the given time frame.

● Issue: an objective to be resolved as a part of the project (this could easily be a program you have to write). An issue could be a user story provided by a product owner, or a general backlog / task decomposed by product managers or a specific build / test / debug task created by development team members. Issues should have properties including id (unique identifiers), type (user story, task, build, test, debug, documentation, etc.), reporter, assignee, status (open, in progress, done, overdue), priority, created date, description, comments, etc.

● User: Users in this system can be all roles in a real project team. To make your work easier, we categorize users into 2 groups based on their access level:

○ Project lead: This group of users is usually product owners and product managers. They have the access to all possible activities in a project, ranging from inviting other users and modify top-level plans (e.g. the deadline of the project and each sprint) to modify all properties of each issue.

○ Team member: In a software development project, this group of users is usually designers, developers, testers, etc. They can view the project and each individual item in the project as leads can, but will only be able to create and update some properties of an issue.

Since the system is designed for users to be able to work on multiple projects, their roles are not fixed. A team member, such as a developer, in one project could become a product lead in another project. He/she can create a new project and become a project lead in the new project and invite other co-leads and team members.

System Features:

The software you are designing is intended to function as if it were actually going to be used by a project team, thus the user experience you create must be realistic. Here are some required functionalities:

User perspective:

● User should be able to register to the app by specifying username and password. Usernames should be unique.

● User should be able to log in to the app with his/her own credentials

● User is presented with main-menu style options after logging in, containing items like:

○ Notifications: view changes related to projects/issues assigned since the last log in including

■ Changes to sprints’ timeframe

■ Changes to issue assigned to the current user

■ Issues newly assigned to the current user

○ My Projects: view and update all projects the user is working on. User should be able to:

■ choose an individual project

■ View all properties of the project including project name, description, collaborators, etc.

■ View individual areas in the project including the “To Do” area, “in Progress” area and “Work Done” area. The program should display a report containing basic information of each area such as issue count, time frame of sprints, titles and statuses of issues, etc.

■ create a new issue which will be added to “To Do” area

■ View an individual issue. The program should display all properties of selected issue

■ update an existing issue in “To Do” and “Sprint” area by commenting and assign the issue to the current user him/herself

■ if and only if the current user is a project lead/co-lead of the current project, user should also be able to do the following:

● Change properties of the project such as project name, deadline, etc.

● invite other users to collaborate, assign members with different roles including co-lead of the project and remove members

● create sprints and update sprints by changing the time frame, assign issues in “To Do” area to a specific sprint

● change all the properties of issues in all areas including “Work Done” area (e.g. lead can mark an issue considered done as in progress and re-assign it to an active sprint)

● delete an issue

● delete the project

■ Create a new project

● User will automatically become the lead of that project and the new project will be added to the project list

○ Sign out: signs the current user out

System perspective:

● Notifications for related users should be generated once there’s a change to a project/issue happens

● The user will automatically get the permission of accessing a project once he/she is invited to that project. Once being removed from a project, user won’t have access to that project anymore.

● Issues should be assigned unique IDs when they are created

● After the deadline of a sprint, the sprint will be marked as finished.

● Issues not finished and overdue will be automatically copied to the next active sprint, with a new id but refers to the old issue id in the description.

● The system should be user friendly, so there should never be any confusion about what a certain action will do. This means you will probably have to print instructions to the user anytime they are expected to give user input

● Make your system user friendly by providing sufficient guidelines and help to use the system (For example: if your system is expecting any input in a specific format, be sure to specify that in the instructions as well as the Testing part of your report)

● Note: Your system must have state persistence by saving the necessary data to files. State persistence allows your system to outlive the process that created it. For example, if you add a project and/or issue to the system when you initially run it and then close the execution before running the system again, the system must be able to remember the previous project and/or issue and its state. This will allow you to use the previously entered information without having to create all users, project information, issues, etc. again and again. You can complete the entire project by storing data in files or any other persistent storage medium.

You have tremendous amount of freedom in designing this application. You are welcome to add any additional functionality to your system. Just imagine that you are an actual developer of the application.

Note: The design of a Graphical User Interface (GUI) is optional. You can also develop a command-line based system.

System Design & Development:

The final project includes two major components: Project Design and Implementation.

Design (2%): The design component will consist of the software design for the project and will include the list of all classes (member variables and functions) to be used, their relationships & collaboration, as well as databases/files. The initial design must precede any implementation. You will start by analyzing the requirements of the project and by identifying the classes required along with attributes and functionalities. A doc/docx document listing the design along with UML diagrams (Class diagrams, activity diagrams, etc.) must be submitted by the deadline on Canvas. Please include the following:

● Skeleton Code with all classes (with member attributes and member functions)

● What are class hierarchies and relationships? (in your report)

● All other data structures or files to be used (in your report)

● Group Peer evaluations are REQUIRED and it counts towards final grade. Each member is ideally required to put in equal amount of effort

● Also, setup a private repository for your source code on GitHub and add all graders as collaborators (See instructions on Canvas).

It would be beneficial for you to analyze your system thoroughly and provide detailed UML diagrams. Here are some of the questions, answering those will help you put on the good path:

• How many classes will you have and how will they interact?

• How will you store user ID, passwords, project information, etc.?

• How will you restrict users from accessing projects they are not invited to collaborate?

• How will you maintain the access level of items in a project based on user’s role?

• How will you represent the project/sprint/issue selection options and the menu?

• How will you deal with checking the due date of issues/sprints?

Implementation (6%): Once you complete the initial design, setup a private github repository and start implementing the project lead, normal user functionalities separately. Test these separately with individual drivers. Be sure to add the appropriate user-friendly menu options that would allow the user to select various actions easily. Ensure that the menu options only work when correct input is provided by the user. Test each option individually to ensure that all available functionality is properly implemented. All sourcecode must be shared amongst team members and instructors via github. 

Now imagine yourself as the user of the system (as Project lead and normal user) and observe the behavior of the system (and see how it changes). Reflect on the efficiency of your choices. Review your initial design and make the necessary changes to remove any unnecessary attributes and functions. You may have to add some more functionality that you might have missed in your initial design. Implement the updated design and report the updates to the initial design along with a discussion regarding the efficiency of your choices. A doc/docx document listing the final design including UML diagrams must be submitted along with working Source Code and video demo by the deadline. See the checklist given below.

Testing: Develop and build unit tests for each operation. Create different drivers for testing each component of the system as a Project lead, normal user separately and then integrate the entire system and test with a separate main driver. Please ensure that the complete system is properly tested before submission.

Deliverables: The following items must be submitted:

■ All source and header files related to the system implementation (on Canvas as well as github).

■ All drivers that are part of the testing as Job seeker, and Employer separated in different folders

■ A README file with any information regarding compilation and testing I need to know in order to successfully compile and run your system. Include any other files needed to compile or test

■ Source code must be properly organized, readable, and must use proper best coding practices.

■ The report file with the final design with discussion, and details of testing activities. Feel free to show additional testing you performed in the report

■ Video Demo (10 minutes long max) showing all features of your working system. Voice over is not mandatory

■ Group Peer evaluations are REQUIRED and it counts towards final grade.

■ Each member is ideally required to put in equal amount of effort

Project Checklist:

You can use the following checklist to ensure that you have submitted everything required for the project:

• Did you submit evidence of successful compilation or testing (screen captures)?

• Did you submit the instructions required to compile your code?

• Did you add all instructors as collaborators to your private github repository?

• Did you submit all files including any new header files used for compilation on Canvas (compressed as one file)?

• Did you implement user’s features: password, unique ID, notifications, etc.?

• Did you submit a report with your designs (and UML diagrams), evidence of successful testing of all features?