This is part one of three for a project I'm struggling on how to do a lot of the documentation I have included the code for the game it's self any help would be appreciated ill add more files if needed
Assignment 1 CST8333 PROGRAMMING LANGUAGE RESEARCH PROJECT – ASSIGNMENT 1 CST8333 PROGRAMMING LANGUAGE RESEARCH PROJECT – ASSIGNMENT 1 CST8333 Assignment 1 < project="" name=""> < your="" name=""> < date="" submitted=""> All material prepared for this assignment was produced by the author. Material from all third parties has been cited and referenced. CST8333 PROGRAMMING LANGUAGE RESEARCH PROJECT – ASSIGNMENT 1 CST8333 PROGRAMMING LANGUAGE RESEARCH PROJECT – ASSIGNMENT 1 2 Table of Contents 1Introduction3 1.1Objectives3 1.2Scope3 1.3Timeline3 1.3.1Milestones and Deliverables4 1.4Risks4 1.5Assumptions5 1.6Technical Constraints5 1.7Budget5 2Requirements7 2.1Introduction7 2.2Business Requirements7 2.3Technology Requirements8 2.4Compliance Requirements9 2.5Security Requirements9 2.6Requirements Traceability Matrix10 3Feasibility11 3.1Introduction11 3.2Alternative Solutions11 3.2.1Solution 111 3.3Recommendation12 3.4Conclusion12 4Design13 4.1Introduction13 4.2System Architecture13 4.2.1Network Architecture (e.g., see example below)13 4.2.2Server Architecture (e.g., see example below)13 4.2.3Process (data flow) (e.g., see example below)13 4.2.4Security (e.g., layered architecture with critical assets in inner layers)14 4.2.5Availability (e.g., include redundant components)14 4.2.6System Partitioning: (e.g., partition subsystems and optimize communication between system components, as well as users and the system)14 4.2.7Database Schemas (e.g., database structure)14 5References15 6Appendix A: Module 2 Checklist16 7Appendix B: Module 3 Checklist19 8Appendix C: Module 4 Checklist20 9Appendix D: Assignment Grading Rubric22 Introduction In this section background information on the project is provided, including the reasons for undertaking the project, specifically the business problem to be solved and how the proposed system will solve it, as well as the key stakeholders who will benefit from the project results. Objectives In this section measurable project objectives, business outcomes to be derived from achieving the objectives, and the measurement criteria to be used to confirm that an objective and the outcome have been achieved are listed. Table 1: Objectives and Business Outcomes (example) No. OBJECTIVE BUSINESS OUTCOME MEASUREMENT CRITERIA 1 Solve < state="" the="" problem="">> Users are able to < state="" user="" capabilities="">> Reduction and/or increase in < state="" criteria="">> 2 3 Scope In this section the features and functions that characterize the product, service, or result to be delivered by the project are described. That is, the major activities that must be completed to complete the project are listed. Activities that are out of scope for the project also are listed to reduce ambiguity. Table 2: Project Scope (example) ACTIVITIES IN SCOPE ACTIVITIES OUT OF SCOPE 1. Assignment 1 1. Apply for business financing 2. 2. 3. 3. Timeline In this section the project timeline is illustrated. The project duration is based on the CST8333 course calendar. Tasks included in the timeline are based on checklists included in CST8333 course modules. It is understood that unforeseen events and changes may result in revisions to the project timeline. Table 3: Project Timeline (example) Please find, below, a template for a project timeline. Milestones and Deliverables In this section significant events in the project and their associated deliverables are defined. Table 4: Project Milestones and Deliverables (example) MILESTONE DATE DELIVERABLES 1. Assignment 1 complete October 8 2020 Written report and slide presentation 2. 3. Risks Project risks are uncertain events or conditions that, if they occur, have positive effects (opportunities) or negative effects (threats) on one or more project objectives, such as scope, schedule, cost, and/or quality. In this section the principle project risk is identified (e.g., schedule slippage, requirements inflation, conflicting requirements, deliverables quality) the likelihood it will occur is estimated (high, medium, low), its impact if it occurs is estimated (high, medium, low), and mitigation strategies are described (how likelihood and impact will be minimized). Table 5: Project Risks (example) No. RISK DESCRIPTION PROBABILITY (H/M/L) IMPACT (H/M/L) MITIGATION 1. Schedule slippage M H Track project scope and timeline Assumptions Assumptions are factors that you believe to be true, although they are not confirmed to be true. Assumptions add risk to a project since it is possible that they will turn out to be false. Assumptions can impact any part of your project life cycle and resulting solution implementation, so it is important that they be documented. In this section the principle project assumption is identified. Table 6: Project Assumptions (example) No. THE FOLLOWING IS ASSUMNED 1. Fundamentals of new programming language will be learned and put to use, timely, to complete project Technical Constraints Constraints are fixed boundary conditions or limits on what you can do. They are the things you cannot change but that you need to be aware of and manage to. Technical constraints focus on architecture decisions that may limit your solution design. They tend to be inflexible and unchanging and may impact your solution implementation. They include areas such as development languages, hardware, other infrastructure, and software that must be used for your project. In this section the principle technical constraint is identified. Table 7: Technical Constraints (example) No. TECHNICAL CONSTRAINTS 1. Programming language selected does not accommodate all of the functionality desired in the solution Budget The project budget is a tool that is used to estimate all the costs that are likely to be incurred before the project is completed. In this section a preliminary budget is estimated. Only in-scope items, as identified in section 1.3 above, are included. Out of scope items are excluded. It is understood that unforeseen events and changes may result in revisions to the project budget. Table 8: Project Budget (example) Notes 1. It is not expected that you will incur out of pocket expenses to complete the project. As such, it is acceptable that the budget includes only level of effort estimates. 2. Please find, below, a template for a project budget. Requirements Introduction Requirements define the characteristics or features of a desired solution. They must be actionable, measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for solution design. Categories of requirements include the following. Business Requirements: The behaviours of the solution, including functionality, performance, and audit/reporting requirements. Technology Requirements: The architectural elements of the solution, including network connectivity, system communications, user interface, hardware specifications, and operational/support needs. Compliance Requirements: The legislation, regulations, and/or policies to which a solution is subject and with which it must comply. Security Requirements: The security features that will be implemented to mitigate attacks. Each category of requirement is discussed in the sections that follow. Requirements in each category are defined using the following parameters. 1. Number 2. Name 3. Description 4. Subcategory 5. Driver a. Mandatory b. Desired c. Optional As pertains to records retention requirements, records shall be kept in storage according to legislative, regulatory, and policy requirements, whichever is most strict. Business Requirements Business requirements mirror the business drivers of the solution. Subcategories of business requirements include functional, performance, and reporting requirements. Table 9: Business Requirements (example) NUMBER NAME DESCRIPTION SUBCATEGORY DRIVER B-01 Accept service requests Capture service request data Functional Mandatory B-02 Concurrent users Accommodate 200 concurrent users Performance Mandatory B-03 Manage service requests Post status to dashboard (active, closed, pending) Reporting Mandatory Notes 1. Performance requirements can be broken out in terms of items that include but are not limited to the following: response times; transaction volumes; remote performance; data throughput; etcetera. Technology Requirements Technology requirements are related to the information systems aspects of solutions. Subcategories of technology requirements include application, hardware, data, interface, availability, and maintenance requirements. Table 10: Technology Requirements (example) NUMBER NAME DESCRIPTION SUBCATEGORY DRIVER T-01 User interface Function across multiple platforms Application Mandatory T-02 Servers Redundancy built-in to architecture Hardware Mandatory T-03 Data format Process multiple data formats Data Mandatory T-04 Authentication Credentials must be validated to gain system access Interface Mandatory T-05 Business continuity Systems fail over immediately upon declaration of disaster Availability Mandatory S-06 Data backup Daily incremental and monthly full backups Maintenance Mandatory Notes 1. Application requirements address technical aspects of implementations including, among other things, user account management, data input, data processing, and user interfaces. 2. Hardware requirements can be itemized by specifications, configuration, and the environmental, mechanical, electrical supporting system requirements. 3. Data requirements including, but are not limited to details about data formats, file size limitations, naming conventions, access controls, and storage. 4. Interface requirements speak to the flow of data between systems (“internal” and “external”) the explanations of which may be supported using diagrams. 5. Availability requirements address not only system “up time” and outages, but also business continuity requirements. 6. Maintenance requirements include specifications around data backup, archival, restoration, and recovery. Compliance Requirements Compliance requirements articulate the legislative, regulatory, and policy requirements to which a solution is subject and with which it must comply. Individual laws and/or policies may be considered subcategories of compliance requirements Table 11: Compliance Requirements (example) NUMBER NAME DESCRIPTION SUBCATEGORY DRIVER C-01 Personal Identifiable Data (PID) consent form Users provide consent to collect PID General Data Protection Regulation (GDPR) Mandatory Notes 1. Compliance, typically, is assessed via regular, periodic, formal audits in which process documentation and artifacts are evaluated against established standards. As such, it is critical that records reflective of process implementation (e.g., documented approvals of account creation and deletion requests) be routinely generated, reviewed, and stored for the required length of time. Security Requirements Security requirements speak to the measures to be taken to protect data confidentiality, integrity, and availability (CIA). Subcategories of security requirements include physical security and logical security. Table 12: Security Requirements (example) NUMBER NAME DESCRIPTION SUBCATEGORY DRIVER S-01 Lockout User lockout after 5 failed logins Logical Mandatory Notes 1. Physical security requirements speak to controls around access to facilities, spaces within facilities, and equipment hosted in those spaces and include measures such as closed-circuit television monitoring, security guards, key card access, inactivity timeouts on workstations, and environmental controls, such are raised floors in server rooms, uninterruptable power supplies, and fire suppression systems. 2. Logical security requirements include access management controls, such as authorization, authentication, roles-based permissions, audit logging and monitoring, systems protection mechanisms (e.g., intrusion prevention and firewalls) and data protection mechanisms (e.g., anti-malware software and data encryption). Requirements Traceability Matrix This initial version of that requirements traceability matrix is the first step in the process identifying the tests that will be performed to validate whether documented requirements have been achieved. Table 13: Requirements Traceability Matrix (example) NUMBER CATEGORY REQ’T TEST EXPECTED RESULT ACTUAL RESULT PASS/FAIL COMMENTS S-01 Security User lockout after 5 failed logins Enter invalid credentials 5 times in succession Error message displayed directing user to contact support for password reset TBD TBD TBD Feasibility Introduction The objective of the feasibility study is to determine how successful the proposed project will be. Specifically, to determine if a proposed software program will work as anticipated and generate the projected revenue or anticipated cost savings. The study also will accomplish other objectives that will vary depending upon the reason for the study, but generally they will revolve around customer needs, your company's strengths and the financial viability of the project (e.g., determine if will enough customers will buy the new product at a price sufficiently high so that you can make a profit). In this section solutions to the problem that users experience with < state="" the="" problem="">> are evaluated and a preferred solution is identified. Business, technical, and cost data are presented to help answer the following questions. 1. Given the developer’s current skills and experience is it reasonable to expect? a. The project will be completed within the time allowed. b. The new system will perform adequately. 2. Are there any environmental factors that need to be considered before undertaking the project (e.g., other private and/or professional commitments)? 3. Are there sufficient knowledge and technical resources available to complete the project and then maintain the system after it goes live? 4. Will the results of the feasibility study be used as inputs in the decision to design and implement the system? Alternative Solutions In this section each alternative solution is explained in terms of its technical, operational, and economic feasibilities. < use="" the="" following="" format="" for="" each="" alternative="">> Solution 1 The first solution is __________________. Further explain the solution. Economic Feasibility The economic feasibility is the total cost of the solution, including all the costs involved: materials, staff, operating costs, etcetera Structural Feasibility The structural feasibility is the fit of the solution into the existing architecture, including servers, databases, networking, etcetera. Operational Feasibility The operational feasibility is the fit of the solution into the existing processes/operations. For instance, the need to train existing staff, or hire additional staff. Recommendation In this section recommendations are prioritized according to the results of the analysis of the alternatives, beginning with the preferred alternative (emphasize the solution’s benefits according to its technical, operational, and economic feasibilities). < use="" the="" following="" format="" for="" each="" alternative="">> My first recommendation is Solution ABC. Solution ABC is (elaborate on why you ranked the solution as your first recommendation; end with the benefits of the solution). Conclusion The purpose of this feasibility research report was to address the problem of < state="" the="" problem="">>. This report offered < state="" the="" number="">> alternative solutions to the