PMP-Team-7

1 Project Management Plan Team 7 Promise Chieka Roshani Gladson Joshua Stoneback Ethan Fennell February 13, 2024

2 Table of Contents Section/Sub-section Title Author [person(s) with primary accountability for this section] Page # 1. Life Cycle Model Roshani Gladson 3 2. Team Organization Roshani Gladson 7 3. Deliverables, Non- deliverable Products, and Milestones Joshua Stoneback 9 4. Project Schedule Ethan Fennell 11 5. Size and Cost Estimates Promise Chieka 14 6. Risk Assessment Promise Chieka 15

4 Figure 1.1 Establish outline specs: Set basic requirements from the provided technical overview, these would include outline specifications for SIS which ensures FERPA compliance. The specifications for this project include: a) No real student data will be placed in the prototype. b) No user-level documentation is required for this project. c) Develop a proof-of-concept prototype ONLY. d) For Security purposes, additional data items drawn from the security requirements to the given table will be necessary to comply with the FERPA overview.

5 Some of the basic functional components include, a) Efficiency in managing student records with functionality to add, display, delete and modify entries, except for unique SID. b) Data retrieval should allow for SID or last name, with full display of all associated data items. c) Validation rules must be applied to names, addresses and other specific fields entailing these. However, fields like phone number are optional d) It should handle searches giving multiple records and should allow for commit action for database changes. e) An error system should be implemented to handle duplicates and non-existent information. f) Sorting must be implemented to display lists for students. g) The prototype must function in the latest browser version chosen by the developer, and should follow simple coding convention Technology Environment:  WAMP (Windows, Apache, MySQL, PHP) stack for development and testing with a server of the team’s choice. Should have a front-end web server and back-end database server running the WAMP environment.  The state of hardware and software are sufficient to meet the requirements Other instructions: 1) The team will be given access to a client-owned, internet accessible server for client testing and application during final evaluation. 2) The MVC database is intentionally very limited in size for the overall development effort 3) For the initial screen, the prototype must display the development team’s name and list of members in the team. 4) For testing, the registrar’s office will use and manage the prototype, and the staff will act as student and faculty roles for testing. 5) For the test plan, an assumption should be made that the MVC staff members have some basic knowledge web application proficiency. Design prototype: Using the given established outline specs, design a prototype. Does not require it to be robust but should be functional enough to demonstrate concepts. It is made that the MVC staff have basic knowledge of operating web-based applications. Build prototype: Build the prototype based on the design prototype using the WAMP environment and the team’s choice of server. This should include front-end interface and back-end database interactions. Testing: Test the built prototype and should follow the given requirements and instructions provided by the technical overview. In this case, the environment should be initially tested by the team using their names and list of members Evaluation and feedback gathering: For final evaluation, the prototype should be tested by the registrar and the staff, simulating faculty and students. In addition, the final prototype application should be placed on the client’s server.

7 2. Team Organization [Roshani Gladson] Selected Paradigm The chosen paradigm for this project is the Open Paradigm, the main factor being its flexibility with adaptation. There are several reasons for it is popularity in many businesses today. Here are list of advantages and limitations to implementing this paradigm for this project, Benefits: 1) Flexibility: Fosters adaptability in incorporating new fresh ideas from different talents 2) Collaboration: This allows for active participation and idea sharing among team members which fosters creativity and innovation. 3) Responsiveness: Allows for quick response and feedback from the MVC staff during prototype evaluation 4) Learning from your peers: This paradigm will allow team members to learn expertise and grow from each other’s knowledge and talent. Limitations: 1) Decision-making: The project may progress slow, due to lack of clarity and hierarchy, especially if there are several opinions voiced at the same time 2) Consistency: lack of hierarchical structure may lead to design challenges which require a consistent approach. 3) Conflict: Clear authority and decision making may lead to conflicts 4) Management: Tracking responsibilities and accountability might become challenging without defined roles To solve these limitations, increased communication and coordination efforts are necessary by the team members to keep them sustainable and aligned. Selected Structure The chosen structure for this project is the ‘Structured Open Teams’. This structure is a combination of positives from both open paradigm and closed paradigm, which fosters both collaborations and hierarchical decision making. Some of the benefits include,

8 1) Team roles are formally assigned and defined 2) Roles are rotated for flexibility and learning 3) Promotes personal ownership of work products 4) Clear external accountability 5) Builds technical consensus Limitations include, 1) Complexity in Role Rotations: Role shifting may lead to disruption of work, especially short projects where learning curve can impact consistency and productivity 2) Balancing structure: open collaboration and structured decision-making can lead to confusion and conflict. 3) Overhead cost: Using this approach can lead to management overhead, 4) Accountability: It may lead to afflicting morale if not managed properly 5) Consensus challenges: Building technical consensus may lead to delay in prototyping delay, which is crucial for MVC project Table 2.1 Member Role Responsibility Promise Chieka Project Manager & Financial Officer Oversees project planning, scheduling, and progress. Ensure the budget and spending is appropriate. Ethan Fennell Lead Developer & Cyber Analyst Responsible for the technical architecture of the SIS prototype. Guides coding standards. Joshua Stoneback Quality Assurance & Tester Ensures testing strategies are applied. Manages feedback integration from prototype tests. Roshani Gladson Project Liaison Handles bulk of client communication. Teaches MVC administration about the software development process.

10 Table 3.3 Milestone Description Finalize Project Management Plan Finish writing the Project Management Plan and provide this to the client. Finalize System Requirements Specification Finish writing the System Requirements Specification and provide this to the client. Finalize System Design Specification Finish writing the System Design Specification and provide this to the client. Setup development environment Download and ensure access to a front-end web server and back-end database server running the WAMP environment. Prototype w/ basic functionality Complete development of an initial version of the prototype with basic functionality Finalize System Test Specification Finish writing the System Test Specification and provide this to the client. Successful test of prototype Internally test prototype before moving on to client testing Deliver prototype for client testing Transfer access to the client to test the prototype Gather feedback Gather feedback through client evaluation Refine prototype if necessary Refine prototype using information gained from client evaluation Document learning & requirements Document what was learned from the prototype development process to assist in future software development

11 4. Project Schedule [Ethan Fennell] Table 4.1 Milestone / Subtask Lead Start Date Duration Create & Deliver Project Management Plan Promise Chieka 02/05/24 6 days Life Cycle Model Roshani Gladson 02/05/24 1 day Team Organization Roshani Gladson 02/06/24 1 day Deliverables, Non-deliverables, Milestones Joshua Stoneback 02/05/24 2 days Project Schedule Ethan Fennell 02/07/24 2 days Size and Cost Estimates Promise Chieka 02/09/24 2 days Risk Assessment Promise Chieka 02/09/24 2 days Slack Time 1 day Project Requirements Draft Promise Chieka 02/14/24 3 days Collect information on MVC systems Ethan Fennell 02/14/24 2 days Create contract for the deliverables Promise Chieka 02/16/24 1 day Slack Time 1 day System Requirements Specification Promise Chieka 02/20/24 5 days Functional Requirements Joshua Stoneback 02/20/24 5 days Interface Requirements Roshani Gladson 02/20/24 4 days Non-Functional Requirements Promise Chieka 02/20/24 3 days Slack Time 1 day System Design Specification Promise Chieka 02/28/24 9 days Define Project Scope Promise Chieka 02/28/24 1 day Architectural Design Ethan Fennell 02/29/24 4 days Data Design Joshua Stoneback 02/29/24 4 days Software Design Ethan Fennell 03/06/24 4 days User Interface Design Roshani Gladson 02/29/24 8 days Slack Time 2 days

13 Figure 4.1 Figure 4.1 shows a Gantt Chart for with the schedule from Tables 4.1 and 4.2.

14 5. Size and Cost Estimates [Promise Chieka] Figure 5.1

16 expectations, leading to dissatisfaction and potential rework Types [ Technology, People, Organizational, Tools, Requirements, Estimation]

17 Risk Analysis [Describe why you believe the probability and effect are as you state] Risk # Probability & Reason Effect & Reason 9 High: High due to increasing cyber threats Catastrophic: Breaches can result in significant legal, financial, and reputational damage 2 High: Natural in software development, especially with new or complex technologies Tolerable to Serious: Can delay project timelines and require additional resources to resolve 3 Moderate: Change aversion is common among users adjusting to new systems Serious: Poor adoption can weaken the project's value and return on investment 6 Moderate: Frequent in project management due to internal and external dependencies Serious: Delays can erode stakeholder trust and increase project costs 8 Moderate: Changes in stakeholder expectations or unclear project boundaries commonly occur Serious: Leads to overextended resources, missed deadlines, and increased costs Probability [High, Moderate, Low] Effect [Catastrophic, Severe, Tolerable, Insignificant]

19 Risk Monitoring [whether the risks are more or less probable and how they might have changed] Risk # Indicator(s) 9 System-wide latency, suspicious logs, or unknown applications 2 Many reported technology problems, system crashes, or low user activity 3 Low user activity with the new software, increased activity with the old hardware 6 Project goals being pushed back or financial reports indicating that project spending is exceeding the planned budget 8 An increasing number of requests to add new features or budget reallocations