Th64-CSE360-Phase-3.docx

pdf

School

Arizona State University *

*We aren’t endorsed by this school

Course

360

Subject

Computer Science

Date

Feb 20, 2024

Type

pdf

Pages

Uploaded by MinisterExplorationMouse17

CSE 360 Project Report Number 3 Team Th64 Team Member Names: 1. William Adams 2. Jaden Thomas 3. Quan Nguyen 4. David Williams 5. Evan Gittens

Team Project Phase 3 Table of Contents 1. Executive Summary ............................................................................................................................... 1 2. Customer Problem ................................................................................................................................ 2 3. Concept of Operations .......................................................................................................................... 3 4. Received Requirements ...................................................................................................................... 10 5. Derived Requirements ........................................................................................................................ 12 6. High-Level System Architecture .......................................................................................................... 13 7. Requirements Analysis ........................................................................................................................ 16 8. Conclusion .......................................................................................................................................... 23 9. Appendix A: Credit Sheet .................................................................................................................... 25 10. Appendix B: Current Team Norms ................................................................................................. 26 1

Team Project Phase 3 Executive Summary 1. Executive Summary Since its inception in 2005, EffortLogger has been an indispensable cog in streamlining our customers' project tracking and management process. However, as our client’s organization burgeons and adapts to dynamic currents, a flood of new challenges have emerged, it’s incredibly clear that these challenges require our attention to ensure EffortLogger not only retains functionality, but also adapts to the clients rapidly changing environment. The upcoming challenge navigates the careful balance between insatiable appetite for increasing productivity and accuracy against the imperative of safeguarding the covert sanctuary of employee privacy. Our client aspires to improve their planning accuracy by collecting more data, all while preserving the confidentiality surrounding their workforce. Simultaneously, the ominous specter of data security casts a long shadow. The competitive arena sees rivals arming themselves with sophisticated hacking strategies with the goal of infiltrating and stealing sensitive data. The clarion call is for EffortLogger to bolster its data security bastions, creating robust barriers between threat actors and our clients precious data. Moreover, as our client faces exponential growth the indispensable need for a more robust EffortLogger grows as well. With the establishment of a Quality Assurance Engineering entity and the expansion of agile teams, EffortLogger must evolve. The envisioned enhancements include: agile framework integration for expedited poker planning sessions that include real-time data sharing amongst crew members. Additionally, the tool will include measures to enhance security by anonymizing individual effort and defect reports, this sets the tone for a secure yet productive environment. EffortLogger V2.0 is not merely an upgrade but also a strategic move towards adjusting with more modern project management tools and paradigms. This will ensure our client remains operational, running efficiently and safely in a sea of competitors. 1

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

Team Project Phase 3 Customer Problem 2. Customer Problem 2.1 Customer Problem 1: Employee Privacy and Data Security 2.1.1 Need to Find Automated Way to Identify Opportunities for Improvement Without Violating Employee Privacy ● The firm has recently been pressured for workers to provide more detail about their productivity rates, defect rates, and other data. ● This would enable the firm to reduce the size of the contingencies that must be added to deal with “surprises.” ● The online drop box used for submitting efforts and defects contain user information which concerns users. ● The firm used a third-party tool for anonymizing user information in the metadata. This provides a lack of adequate measures to protect and prevent potential risks. ● Transparency in pay raises and promotions is valued importantly in the firm. Since the system is transitioned to a data-driven system, it could negatively impact the transparency 2.2 Customer Problem 2: Confidential Information Security 2.2.1 Competitors Rumored to Employ an Array of Hacking Methods to Gain Access to Confidential Planning and Operational Data ● The entire leadership team is equally concerned about hackers gaining access to the firm’s confidential information. ● Access to this information would give unfair insights into the firm’s capabilities, competencies, and other sensitive information 2.3 Customer Problem 3: Enterprise-Scale Support for Agile and Quality ● The system solutions the customer produces have increased in size by a factor of 20 since the first EffortLogger tool was produced and delivered. Costs have gone up by a larger factor leading to the creation of a Quality Assurance Engineering organization with interesting cross-functional links to the firm’s Human Resources and Customers Services organizations. ● Need for a generic system product to address what the firm see’s as the potential for significant demand to support enterprise-scaled agile teams. 2

Team Project Phase 3 Concept of Operations 3. Concept of Operations 4. Key Operational Scenarios 4.1. Overview of the Operational Scenarios 4.1.1. The user wants to track their effort on a deliverable. ● The system will generate a spreadsheet of the user’s effort log based on the information provided. When the user is entering the project they are working on, the user will also be able to specify the stakeholder they’re working with. 4.1.2. The user is in a “planning poker” session with their colleagues ● The system will show the user relevant user stories from their backlog, sorted by their average weight based on prior user input. The user can then change weights on-the-fly to re-order the importance of these user stories. 4.1.3. The user wants to share their “planning poker” card ● Once the “share” button is clicked, the system will generate a stylized “card” that will be sent to their team’s applications as well. 4.2. Proposed Solution Summary ● Our proposed solution is to keep EffortLogger relatively similar to how it has worked in the past but add extra features such as support for enterprise scale operations, the ability to include identifying information about individuals in an entirely new user interface overhaul, improved user story based estimations, and an all new planning poker tool. We choose this specific approach due to the problems and needs given to us by the documents that were provided to us by our customers and stakeholders. 4.3. Major Processes and Functions ● Attributes Start/Stop an activity and then log it as an entry Process Name Create an Effort Log entry Purpose This process is relatively the same as it is in the original EffortLogger but now includes the ability to include identifying information about the user logging the activity and the option to include more enterprise scale information in the activity. Description The user can press the Start Activity 3

Team Project Phase 3 Concept of Operations button to start the current activity. After the activity is finished and the user has entered all relevant information to log, then the user can press the Stop Activity button to stop and log that activity. Priority High Frequency Duration of the process will continue until the user stops the current activity that they are logging. ● Attributes Edit attributes of an activity Process Name Edit an Effort Log entry Purpose This process is largely identical to the original Effort Log entry editing process but it must now include support for entering/editing more enterprise scale information about the activity. Description The user can select a Project and an Effort Log entry from said project to modify. Alternatively, they can clear all entries from a project. All attributes of the entry log should be able to be modified and then edited. The entry itself should be able to be split into two entries or deleted. Beyond this, the user should be able to return to the effort log console. Priority High Frequency This process may not occur during every use of the Effort Logger, however, it is essential for a user to be able to correct any initial errors in their log. ● Attributes Create a defect log Process Name Create a defect log 4

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

Team Project Phase 3 Concept of Operations Purpose This process is largely identical to the original effort logger but must include identifying information of the user logging the defect. Description The user can select the project that they want to log the defect to. They can then select a defect from the following drop down menu or click the “Create a New Defect” button to make a new one. The user can then establish attributes of that defect. In addition, the user may remove all defects from the defect log, delete the current defect, or return to the effort log console. Priority High Frequency This process will be used accordingly when defects pop up. ● Attributes List every log with its key attributes Process Name View all logs Purpose This process is largely identical to the original Effort Log entry viewing process, with the exception of new information that may be a key attribute. Description The user is presented with a table of every Effort Log and Defect entry for a project with 1000 rows of cells. Each row contains key details about an entry but all identifying information will be removed prior to viewing it. There is a counter for the total number of entries. When a user is done viewing the entries, there is a button to return to the console. Priority High Frequency This process will infrequently occur when it is necessary to summarize a project and 5

Team Project Phase 3 Concept of Operations its Effort Log entries, as this process does not allow the user to interact with the entries. Interaction with entries is the main purpose behind the app, and this process deviates from that. ● Attributes Prepare user stories before going into a planning poker session Process Name Planning Poker Prep Purpose This process is new, and within our scope of development for the project. Developers need to be able to quickly reference relevant user stories in their planning poker sessions. Description Prior to and during Planning Poker sessions, Developers may give user stories certain weights and assign their relevance to certain projects. This will then be reflected in the planning poker session, where only relevant User Stories will be presented, ordered by the average of their weights. Priority High Frequency This will occur relatively frequently, as it is effectively a second primary purpose of the program. ● Attributes Share Planning Poker cards with teammates concurrently Process Name Planning Poker Share Purpose This process is new and within our scope of development for the project.The developers need to be able to quickly share their Planning Poker cards with their teammates all at the same time, in 6

Team Project Phase 3 Concept of Operations order to avoid bias. Description After a planning poker session the user will have the ability to press a “share” button to create a stylized planning poker card with several statistics (e.g., range, average, discard high and low and average remainder) and then send to every member part of the system. Priority Medium Frequency This will occur probably as frequent as the planning poker prep process since usually after a planning poker session the user will want a planning card of the session. 4.1.4. Process Flow 7

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

Team Project Phase 3 Concept of Operations 4.1.5. Classes/Categories of Users ● Boundary class that will be the User Interface for the program, will group various processes and functions in a less complex and more user friendly way. ● 2 controller classes, one for creating and editing effort logs and one for creating and editing defect logs. And a third controller class for the planning poker tool. ● Entity class will be where the controller classes store and edit the logs. 5. Scenario 1 After logging their effort logs and possible defects they had while working on a specific project, the user wants to be able to track their effort on a deliverable. The user is able to go to the “view logs” page and be able to enter their project name to view their effort and defect logs from that project. The software will then load a spreadsheet containing the effort logs based on the information provided but will remove all identifying information before being accessed by the user as per requested in the “EffortLogger Supervisor Input” document. 6. Scenario 2 After prepping and creating a planning poker with their colleges, the system will show the user relevant user stories from their backlog, sorted by the average weight based on prior user input. The user will then be able to edit weights from 0 to 4(0 = no relevance, 4 = extreme relevance) whenever needed to re-order the importance of these user stories. Then finally the user will be able to press a “share” button to share a stylized planning poker card to all users in the session. The “EffortLogger User Input” document helped us understand what the customer and 8

Team Project Phase 3 Concept of Operations stakeholders wanted from a planning poker tool, so we developed our idea for the solution based on that. 7. Scenario 3 After a planning poker session, usually the user will want to generate a stylized planning poker card and then have that card be sent to their team’s applications as well. They can do this by pressing the “share” button after their session. Doing so will create the planning poker card that’ll be stylized after a poker card and will contain several statistics(e.g. range, average, discard high and low, and average remainder). Then it will prompt the user if they are sure they want to share the card, if they click yes, it will be sent to all members of the session, if they click no, the prompt goes away and nothing happens. We based this solution on the customer and stakeholder wants from the “EffortLogger User Input” document. 9

Team Project Phase 3 Received Requirements 4. Received Requirements 5.1. Source 1 - EffortLogger Customer Need V2-0 Document V1-1 5.1.1. User Story 1 As the chief information security officer, I want to ensure that our confidential information is kept safe and secure from hackers, so as to prevent competitors from gaining unfair insights into our firm's capabilities. ● Data security should be a core feature of EffortLogger V2.0 ● Proactive measures must be taken to avoid known security weaknesses ● The firm must be able to respond to ongoing threats while maintaining design integrity and traceability across all key work products 5.1.2. User Story 2 As a member of upper management, I want EffortLogger V2.0 to include support for the key attributes of enterprise-scaled agile-based development so that our company can better adapt to the growth it’s been undergoing. ● EffortLogger V2.0 should offer extensive support for detailed user-story-based estimations ● It should be easy to trace issues that occur later in the development process back to inadequate user stories ● EffortLogger V2.0 should be more suited to enterprise-sized applications ● EffortLogger V2.0 should support use by diverse cross-functional teams ● EffortLogger V2.0 should support projects with multiple cross-functional teams 5.2. Source 2 - EffortLogger Supervisor Input 5.2.1. User Story 1 As a first-level supervisor, I want EffortLogger V2.0 to nurture our company's culture of privacy, transparency, and honesty, so that our employees feel comfortable providing necessary performance data. ● All individual-identifying information should be removed prior to being accessed by any team, project, program, or organizational analysis tool ● When not enough reports are received to ensure anonymity, access to the source must not be provided and summary data must not be displayed ● The process flow of information must be transparent and how privacy is ensured must be clearly specified in terms that both technical and non-technical people can appreciate. ● EffortLogger V2.0 should implement professional role levels(e.g., developer 1, engineer 3, supervisor 2) 10

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

Team Project Phase 3 Received Requirements 5.2.2. User Story 2 As a team manager, I want all of our company's teams to have access to a wide array of past performance data, so that both workflow and communication can be improved. ● Data should be available for specific teams/groups ● There should be a way to identify underperforming groups that need predictability improvement ● There should be a way to gather best-practice information from over-performing groups that exceed expectations 5.3. Source 3 - EffortLogger User Input 5.3.1. User Story 1 As someone who’s responsible for overseeing team meetings, I want the new version of EffortLogger to have an interface for setting up Planning Poker sessions. This is so we can spend less time choosing important items and more time discussing them. ● Prior to the poker session, there should be a way to list items that shouldn’t be discussed at the meeting ● For items that pass the screening, there should be a simple way for users to weigh them from 0 to 4(0 = no relevance, 4 = extreme relevance) ● A weighted average of story points should be calculated 5.3.2. User Story 2 As a senior software engineer, I want an interface that can be used during Planning Poker sessions to display and manipulate collected data. This will make discussing outlying estimates much more efficient. ● There should be a tool that shows the contribution of every item ● There should be a “quick look” button that lets users see details of a specific item ● The “quick look” button should also let users change item weights ● Story point weighted average should be recalculated after each weight change 5.3.3. User Story 3 As a junior software engineer, I want the Planning Poker application to have some design elements from a real game of poker. This will make Planning Poker a more enjoyable exercise and hopefully increase productivity during meetings. ● Interface should include a “Share” button that’s stylized after a poker card ● “Share” button should be colored based on the user's story point weighted average ● After pressing share, the user's card should show up on the screen of every member a part of the session ● There should be a section containing several statistics(e.g., range, average, discard high and low and average remainder) 11

Team Project Phase 3 Derived Requirements 5. Derived Requirements 5.1. Security 5.1.1. Source 1 - Received Requirements 5.1.1. ● Passwords should be required to enter the EffortLogger application and access certain functionalities - Missing authorization checks are a major security weakness ● An encrypted password file should be stored separately from the application - This is a powerful proactive measure to improve security ● EffortLogger data should be stored on a database server - This will allow the company to cut off remote access, change vulnerable passwords, or disconnect the database from the internet in the case of a cyber-attack 5.2. Data Collection and Analysis 5.2.1. Source 1 - Received Requirements 5.1.2. ● Within the database, each project should have a list of teams associated with it, and each team should have associated user stories, effort reports, defect reports, etc. - This will make it easier to track down inadequate user stories ● The database server should have lots of storage - An extensive database server will be necessary to store the large amounts of data associated with scaled enterprise agile development(e.g., user stories, effort reports, defect reports, team info, and project info) 5.2.2. Source 2 - Received Requirements 5.2.1. ● Our team will have to determine the number of reports required to ensure employee anonymity 6.2.3. Source 3 - Received Requirements 5.2.2. ● Our team will have to determine some metrics for measuring if a team is underperforming or overperforming 5.3. User Interface 5.3.1. Source 1 - Received Requirements 5.3 ● The EffortLogger and Planning Poker applications will have to be run on a web application server - This will allow the applications to send data to and receive data from the database server - This will also allow employees to interact with each other’s screens during planning poker sessions 12

Team Project Phase 3 High-Level Architecture 6. High-Level System Architecture 5.1. Architectural Overview In the vanguard of project management and agile development, our tool emerges as a paradigm of comprehensive excellence, meticulously architected to orchestrate a transformative user experience characterized by unparalleled efficacy and robust security protocols. The architectural landscape unfolds as a carefully curated symphony of interwoven components, each a purposeful entity contributing to the seamless fusion of functionality and user-centric precision. 5.1.1. Integrated Project Management and Agile Support: ● Seamless User Interface Symphony: Harmonizing the disparate elements of Effort Log, Defect Log, and Planning Poker, our user interface stands as a cohesive tapestry utilizing JavaFX. It is not merely a dashboard; it is a digital nexus empowering project managers and agile teams to navigate the complexities of project evolution with a symphonic blend of finesse and ease. ● Agile Prowess at Core: At the centric of our architectural tapestry lies an agile engine, with User Story Management serving as a robust foundation for the creation, organization, and tracking of user stories. At the same time, Poker Session Management, orchestrates Planning Poker sessions, infusing the estimation process with a collaborative precision akin to a finely tuned symphony. 5.1.2. Data Security and Privacy Bastion: With the use of Java ● Anonymization: In meticulous adherence to the most stringent data privacy standards, our tool employs anonymization techniques.; This not only shields sensitive data but also erects an impregnable bastion of ethical and legal fortitude. ● Security Privacy: The Security Layer shrouding data in an impenetrable cloak of secrecy during the transmission and storage of information. 7.1.3. Data Management: Linked List ● Data Nexus Mastery: The Data Management component, akin to a technological nexus, embraces cutting-edge data storage solutions, establishing a secure repository for information. Simultaneously, the retrieval Data functionality empowers users with the agility to extract pertinent data. 13

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

Team Project Phase 3 High-Level Architecture 5.2. Draft Architectural Diagram 5.3. Architectural Element 1: User Interface 5.3.1. Architectural Purpose: Quality Attribute 5.3.1.1. Purpose (Quality attribute, Reuse, or Other purpose): ● Provide an intuitive and user-friendly interface for users to interact with. ● Facilitate the creation, editing, and viewing of effort logs, defect logs, and planning poker sessions. 5.3.1.2. Rationale: ● Utilized JavaFX for the design of User Interface ● A well-designed user interface system is crucial for user satisfaction and system usability. ● Facilitating an easy interaction with the system’s core functionalities enhances user productivity. 5.4. Architectural Element 2: Data Privacy Layer 5.4.1.1. Purpose (Quality attribute, Reuse, or Other purpose): 14

Team Project Phase 3 High-Level Architecture ● Ensure data privacy and confidentiality by applying anonymization and access control measures. ● Provide users with privacy settings to manage their data privacy preferences. 5.4.1.2. Rationale: ● Data privacy is a crucial concern for users and stakeholders, and ensuring data privacy helps in building trust and compliance with legal requirements. 5.5. Architectural Element 3: Data Management 5.5.1.1. Purpose (Quality attribute, Reuse, or Other purpose): ● Centralize data storage, retrieval, and management to ensure data accuracy and consistency across the system. ● Provide a reliable and efficient means of managing data to support the system’s core functions. 5.5.1.2. Rationale: 6. Centralized data management facilitates easier maintenance, better performance, and enhanced data integrity. 7. Efficient data management is crucial for supporting real-time interactions and ensuring the reliability of the system. 15

Team Project Phase 3 Requirements Analysis 7. Requirements Analysis 7.1. Data Semantic Map To first start a planning poker session, 3 things need to be imported and provided to the Setup phase, Historical Data, Keywords, and a User Story. The Setup provides the description of the user story and a list of historical projects to the first round of planning poker which is then started. During the first round, the end user will use this information to remove irrelevant historical items from what will become the round estimate. The end user uses that estimate to create physical Planning Poker Cards to share with the others and then the round concludes. If all participants agree on the number of story points for the user story, then they go into the Finalization stage, if not, they have another planning poker round which can include previously excluded historical items. The Finalization stage allows the user to make final updates to the user story and/or keywords, make additional notes, and save results for potential future use. Highest Priority Data Items 1-8: 7.1.1. User Story 7.1.2. Historical Data 7.1.3. Keywords 7.1.4. Setup 7.1.5. First Planning Poker Round 7.1.6. Round Estimate 16

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

Team Project Phase 3 Requirements Analysis 7.1.7. Planning Poker Card 7.1.8. Subsequent Planning Poker Rounds 7.1.9. Finalization 7.2. Storyboards supporting Architectural and Detailed Designs 7.2.1. EffortLogger V2 Storyboard 1 (there might be more than just 1) 7.2.1.1. Overview (A single textual paragraph of the purpose of the storyboard) This storyboard gives a simplified overview of what using EffortLogger would look like. It includes, a start page that prompts the user if they want to start an Effort or Defect log or edit an Effort or Defect log, a login page that the user must pass in order to access specific EffortLogger functionality, and after being successfully logged in, the user can use the features of EffortLogger as shown in the images below. 7.2.1.2. Storyboard (Images with very short title text for each image) EffortLogger Start Page EffortLogger Login Page EffortLogger Create Effort Log Console EffortLogger Create Defect Log Console 17

Team Project Phase 3 Requirements Analysis Spreadsheet that Lists Editable Activities After Clicking on an Activity it will List All Details the User Can Edit 7.2.1.3. Explanation ● In the Effort Logger Console, Stop Activity is dotted because it won’t be available until an Activity is started ● In the Defect Console, Clear Defect Log is dotted because it won’t be available a Defect is selected 7.2.2. Planning Poker Storyboard 1 7.2.2.1. This storyboard follows a Product Manager as they log into EffortLoggerV2, add a new User Story to a project, and then host a Planning Poker Session. This graphic will serve as an example for how to (1) implement received requirements into the Planning Poker user interface(poker cards, quick look, group statistics, etc.) and (2) properly structure Planning Poker sessions so that they will go smoothly for both the moderator and the estimators. 7.2.2.2. Storyboard 1. Logging In 2. Creating New User Story 18

Team Project Phase 3 Requirements Analysis 3. Creating Session 4. Successfully Hosting Session 5. Selecting User Story + Team Poker Cards 6. Reshuffle + Quick Look At Outlier 7.2.2.3. Explanation ● In image 5, the moderator has used the scroll down menu to select a user story. This displays the user story on the screens of everyone in the session and allows then to start creating estimates and submitting their poker cards. ● In image 6, the moderator decided to reshuffle or start another round of planning poker because the user story point estimates were too spread out. Then the moderator selected the last poker card to take a quick look at its historical data. Finally they entered an effort estimate of 10 because the team reached a consensus. 7.2.3. Planning Poker Storyboard 2 7.2.3.1. This storyboard follows a team member who logs into EffortLoggerV2 and then joins a live Planning Poker session. This graphic will serve as an example for how to (1) display personal historical data so that employees can quickly estimate their own effort and (2) display group historical data so that teams can efficiently discuss disagreements. 19

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

Team Project Phase 3 Requirements Analysis 7.2.3.2. Storyboard 1. Logging In 2. Joining Session 3. Selecting Personal Historical Data 3. Submitting Personal Poker Card Estimate 7.2.3.3. Explanation ● In image 3, the team member scrolls through their relevant personal historical data and selects items that will help them make an effort estimation for the user story selected by the moderator. They are unable to see the poker cards of other team members until they submit their own card. ● In image 4, the team member has submitted their poker card estimate. They are taking a quick look at one of their team member poker cards. 7.3. Risk-Reduction Prototypes 7.3.1. Primary Effort Logger User Interface 7.3.1.1. None of our team members have used JavaFX to develop a product before. This means that, with the exception of being able to go to certain members for basic knowledge, we need practical experience to develop the user interface driving Effort Logger. 20

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

Team Project Phase 3 Requirements Analysis 7.3.1.2. Risk-Reduction Prototype ● William Adams is responsible for this prototype ● The prototype will lay out a working skeleton of the final Effort Logger product’s UI. This prototype will use dummy data, since there is no proper back-end for the app yet. ● This prototype will provide the practical experience necessary for our team members to feel confident with JavaFX. It will also help mitigate any risk of a clunky user experience, as we will have the prototype UI developed early enough that we can significantly polish it. 7.3.2. Robust Log-in System Prototype 7.3.2.1. None of our team members have developed a successful and secure log-in type system. In order to satisfy our security requirement we need to gain experience with coding secure solutions. 7.3.2.2. Risk-Reduction Prototype ● David Williams is responsible for this prototype ● This prototype will be the new log-in system that the final Effort Logger product will have to insure employee security and privacy. It will act as a typical log-in system that will require the user to log in to perform certain Effort Logger functionality. It will also require robust usernames and passwords in order to register and allow users to sign in with factors such as long character length and case sensitivity. ● This prototype will provide experience in creating robust log-in systems and reduce the system insecurity since having the log-in prototype developed early enough will allow us to refine it and debug possible exploits. 7.3.3. Definitions Page Prototype 7.3.3.1. None of our team members have developed an application that can reference definitionsof recorded projects, life cycles, and other related details. This will mitigate that risk by teaching the team user input and displaying recorded data. 7.3.3.2. Risk-Reduction Prototype ● Jaden Thomas is responsible for this prototype ● The prototype will enhance the Effort Logger tool, adding intuitive user interface elements and providing users with an in-depth understanding of its tailoring capabilities. This includes an interactive definitions tab where users can specify the names of projects, life cycles, and other related details. This tool will automatically populate the effort log and defect console based on the user inputs. ● This prototype will make Effort Logger more user-friendly by allowing its users to more accurately log and track their project activities. As a result they can make more informed 21

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

Team Project Phase 3 Requirements Analysis decisions to further improve their efficiency as software developers and mitigate the risk of decreased productivity. 7.3.4. Activity Screen and Timer Prototype 7.3.4.1. Risk ● The risk is the required level of coding experience regarding making this Activity Screen work smoothly and without as much lag as possible. There will be a need for proper functions and algorithms setup so the buttons and tabs will operate coherently. 7.3.4.2. Risk-Reduction Prototype ● Quan Nguyen is responsible for this prototype ● The prototype will focus on the user experience during the sessions, by providing helpful tabs and buttons such as Start and Stop buttons, current user information tab, title of session, etc. This will help improve the session quality and cut unnecessary setup coming from the person hosting prior to the session. ● For this, each of the key functionalities will be stored in separate functions and safe variables for prevention of race conditions for buffer overflow/underflow. A further precaution step can be an implementation of threading and queue, which is the use of locks. 7.3.5. Log Prototype 7.3.5.1. Risk ● Since we will be dealing with 1000’s of entries for multiple projects, there is a risk of them being displayed improperly and/or being difficult to navigate through. 7.3.5.2. Risk-Reduction Prototype ● Evan Gittens is responsible for this prototype. ● This prototype will include (1) a loop that generates thousands of entries that mimic the kind of data that would be entered into EffortLogger and (2) a very long page that stores that data and that can be easily navigated through. ● This prototype will mitigate risk by testing the functionality of separating and displaying large amounts of data. It will also test different ways to efficiently navigate through the data (scrolling, project tabs, search criteria, etc). 22

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

Team Project Phase 3 Conclusion 8. Conclusion 8.1. The most important conclusions 8.1.1. Data Semantic Map for EffortLogger: The necessity of a clear and comprehensive semantic map to ensure alignment among all stakeholders and clearer development process. ● Data items like User Story, Historical Data, and Keywords play a pivotal role. ● The Planning Poker session’s iterative nature ensures rigorous user story evaluation. 8.1.2. EffortLogger V2 Storyboard Overview: An essential visual representation that aids in visualizing the user’s experience and flow. ● The start page helps users decide their action (start, or edit an effort/defect log). ● The login page safeguards specialized features of EffortLogger and maintains user security. 8.1.3. Importance of Prototypes for Risk Reduction: Early identification and addressing of potential challenges ensure product quality and security. ● Specific prototypes like the Effort Logger User Interface and the Robust Log-in systems. ● Assigning responsibility to team members ensures focused development and accountability. 8.2. Upcoming Important Activities 8.2.1. Effort Logger UI Development: A crucial next step in creating a user-friendly interface for the product. ● Use dummy data to create a working prototype. ● Feedback collection and refinement to enhance user experience. 8.2.2. Robust Log-in System Creation: Addressing the security concerns and ensuring user data protection. ● Implementing a system requiring robust usernames and passwords. ● Continual test and debugging to ward off potential security breaches. 8.3. Parking Lot for Items we need to address moving forward 8.3.1. Deep Dive into JavaFX: Given the team’s unfamiliarity, more exploration and training sessions are required. ● Organizing team workshops or external training sessions. ● Regular updates on JavaFX best practices and new features 8.3.2. Enhancing the Security Framework: Given the utmost importance of user data, a constant review of security measures is required. ● Vulnerability testing. 23

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

Team Project Phase 3 Conclusion ● Patching and updates. 24

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

Team Project Phase 3 Credit Sheet 9. Appendix A: Credit Sheet Team Member Name Contributions Quan Nguyen Executive Summary High-Level System Architecture Requirement Analysis: Storyboards and Prototype William Adams Team Norms UI Mockup (effort Logger console and defect console) UI Prototype Copying Old Phase In Evan Gittens Planning Poker Storyboards 1 and 2 Prototype 5 David Williams Robust Log-in System Prototype Requirements Analysis 7.1.-7.1.9., 7.2.1. Jaden Thomas Conclusion Definitions Page Prototype 25

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

Team Project Phase 3 Current Team Norms 10. Appendix B: Current Team Norms Team Norms (Th64) https://drive.google.com/file/d/1Qnkm8RHfKUr1U7AdqQGyj2LmRGIHDsVK/view?usp=drive_ link Team Norms (Th64) Introduction This contract specifies the terms by which group Th64 , formed of the five members: 1. William Adams 2. David Williams 3. Evan Gittens 4. Quan Anh Nguyen 5. Jaden Thomas agree to work as a team through the development process of the CSE 360 Fall 2023 Group Project. This contract consists of 5 sections: 1. Goals 2. Communication Norms 3. Work Norms 4. Decision-Making Norms 5. Signatures Goals 1. Score high on deliverables. 2. Improve individual communication and collaboration skills. 3. Apply topics learned in class in a practical environment. 4. Build a cohesive and communicative team. 5. Maintain respect between all members of the team. Potential Obstacles to Goals, With Solutions 1. One or multiple members become incapacitated - Acute Solution: The work originally placed upon that member will be distributed across the remaining available members to lessen the impact. - Preemptive Solutions: - All members of the team are expected to openly communicate any blocks in their schedule where their availability will decline from the status quo. - All members of the team are expected to work on their assigned section of an assignment ahead of the due date. This will lessen the impact if a member is incapacitated near the due date of an assignment. 2. There is a significant decline in team morale 26

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

Team Project Phase 3 Current Team Norms - Solution: The team will regularly meet in person as well as online to maintain internal relationships. 3. Communication is poor or sparse - Solution: Communication will be made as frictionless as possible with frequent meetings and communication through Discord/Slack. 4. Meetings or individual work is plagued with distractions - Solution: Meetings will be scheduled ahead of time so members may remove any distractions they know of ahead of time. 5. The team experiences harsh internal conflicts - Solution: Internal conflicts will be raised early. Team members are expected to maintain respect with each other in the event of a conflict. If it is not able to be handled individually, the team will put it up to a vote. Communication Norms 1. There will be a fifteen minute informal in-person meeting after class each Thursday. 2. Supplementary meetings, averaging about thirty minutes each, will be scheduled as needed throughout the week between members collaborating on their assigned section of an assignment. 3. Communication will primarily take place over discord, in a designated server to parse through relevant discussions and maintain a log of our communications. 4. Members are expected to show up to meetings as they are available. 5. Members are also expected to contribute significantly at these meetings for a full grade in both the “attended meetings” and “contributes to group discussions” category. Work Norms 1. The number of individuals assigned to a section in a deliverable will vary based on the complexity of the deliverable. - The "complexity" of the deliverable will be determined by the length in pages, as well as how many section prerequisites it requires at a given point in time. Complexity is greater the greater the length is in pages. Complexity is lower when it has more incomplete prerequisites. - For example, a twelve-page section would have many people assigned to it, unless it could only be completed at the end, in which case it would gradually have more people assigned as sections got completed. 2. The informal due date we will hold ourselves to is Saturday at twelve pm (noon). Any changes made past this due date must not affect the work of those who have declared they're done working. In order to get full points in the “work completed on time” category, team members need to complete their work by this time or communicate ahead of time why it will take them until later. 3. If any member(s) has an issue with another member(s) lack of communication or the speed at which they're getting an assignment done, they will bring it up through three stages: 1. Individually 2. With the team as a whole 3. With a TA 27

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

Team Project Phase 3 Current Team Norms Escalation from stage two to stage three will only occur if no explanation or improvement has been provided after the next two deliverables. 4. Members are expected to make significant contributions to the project while maintaining a positive attitude in communications with the team in order to receive full points in the “contributions were significant to the team’s success,” “maintained a positive and cooperative attitude with teammates” and the “work met or exceed the team’s agreed-to norms and expectations” categories. Decision Making Norms 1. Conflicts require the consensus of everyone who will be directly affected by the issue at hand. - e.g. If one member has an issue with the spacing in a section, they should discuss it with their section collaborators. If they have an issue with the format of the deliverable as a whole, it must be brought up to the team as a whole. 2. If one person cannot let go of an individual idea, it will go to a group vote. 28

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

Th64-CSE360-Phase-3.docx

Related Documents