List and Status of Deliverables - bounswe/bounswe2023group2 GitHub Wiki

List and Status of Deliverables

Deliverable Name Delivery Status Due Date Delivery Date
1. Project Repository Delivered 04.03.2023 04.03.2023
2. Requirements Delivered 18.03.2023 21.03.2023
3. Software design documents in UML Delivered 10.04.2023 10.04.2023
4. Project plan, RAM Delivered 10.04.2023 10.04.2023
5. Milestone Report Delivered 10.04.2023 10.04.2023

Evaluation of the status of deliverables

  1. Project Repository Github repository provides us collaborative and asynchronous work area so it is a good tool to use in group work. We have used the repository created by our assistants. Our repository is named bounswe2023group2 , and we are group of 12 people who are taking CMPE352 class. We have used many features of GitHub.
  • 1.1 README.md page welcomes the users at the first sight. We provide a short description for everyone, interested to our repository, and we list the team members in there, First we just wrote our names, but we decided to put our photos since it is our first meetings. we provide wiki page links, if someone wants to learn further about the project, they can click the wiki page link provided in there.
  • 1.2 Wiki Pages: It is heart of our project. You can see the main content in the first wiki page, we have used sidebar in order to navigating between pages without any difficulties. When we try to write the same page at the same times, GitHub only keeps the one of them works. It took time to find a way to work together in the same page. Requirements, descriptions, our own profiles, to sum all the information apart from code is resides there.
  • 1.3 Wiki/Issue Templates: We wanted to create a consistent way for our work. We have created meeting note, personal page, issue templates to avoid any wrong usages.
  • 1.4 Labels and milestones: It is good to understand concept of the issue without opening it. So we focused on labeling our issues in a meaningful way (effort, urgency, status, type...). Since the project contains many subtasks in it, we used milestones for creating due dates, and reviewing our situation in the tasks.
  • 1.5 Discussion: We needed to decide many feature of our project, at first we tried to discuss them on discord but we always forgot our ideas while implementing. So we decided to use discussion for conflicts and further development. It would be great if we would decided to use discussions before.
  • 1.6: Issue Tracking: We tend to work on issues as a pair, one is reviewer and the other is assignee. But team members were not available enough to track daily the issues. So we had some delays on reviewing and closing issues.
  1. Requirements
  • 2.1 We initially created the questions to the customer, after this meeting we had a long meeting notes in notion application. After requirements, we split the tasks between team members. we had some interviews at the same time with the people who had experiences in disaster , as victims or as volunteers. We completed our first draft, but it has ceration conflicts since we wrote the parts seperately. While merging them, we resolve the conflicts and found out some missing features. So we revise the requirements couple of times. We have reliazed lots of different aspects of our project that we need to specify in the requirements while doing use cases. To conclude, we are eager to define the project clearly and comprehensively to obtain a good result.
  1. Software design documents in UML
  • 3.1 Deciding tool: we first used diagrams.net but it is not a useful tool for collaborative work. We seaarched for other tools and found lucidchart. Lucidchart has simpler usage and faster designing tools. Moreover, team members can be able to work simultaneously in the application.
  • 3.2 Use Case Diagram: We first designed use case diagrams, since we cannot work on other diagrams without completing that one. Use case diagram reveal a big problem in our app structure, first we resolved the problem and revise the requirements and continue on diagram. While writing use cases, we decided to change the view for better understanding. We used arrow colors and colorful backgrounds to better visualizing the user scope. We decided to list the use cases and then assign them between ourselves. But since use cases are not seperate completely, we work on the same document.
  • 3.3 Class Diagram: We separate the class diagram related issues according to distribution in use case diagrams. Each one of us is more knowledgeable than others so we want to keep it that way. Class diagram helped us to define entities types and enumerations.
  • 3.4 Sequence Diagram: We decided that everyone should also do the sequence of the use cases they wrote. We define some services since we will use the functions created there. While everyone worked on sequence diagrams seperately, we designed a templatestructure. for sequences so they have a consistent
  1. Project plan, RAM
  • 3.1 The group developed the sections for Project Plan and RAM in parallel with this report. Initially, we listed all the tasks that were completed by the group. Subsequently, we created an Excel sheet for RAM and each member filled in their respective columns with their past responsibilities. For the Project Plan, we elaborated on the RAM by adding more details and extending the timeframe. We used ProjectLibre, an application where we entered weekly tasks, their duration, and the contributors involved. This allowed us to create a Gantt Chart. The Project Plan encompasses all the completed tasks so far, as well as possible future tasks. We also have the Project Plan in PDF format.
  1. Milestone Report
  • 4.1 We barely finished the report. We wrote our experiences during the milestone. Some parts are duplicated, and we need to design the headers again since it is a bit confusing.