TEAM’S STRONG/WEAK POINTS David Wiggins – Remote Student 1

Team’s Strong/Weak points Strong points – STILL THEIR STRONG POINTS – Operational: Team Communications Standard end of week tag up +1 short mid-week tag up Lots of traffic with everyone CC’d Audio recordings of client interactions – Technical: Attention to technical details Really fleshing out the technical needs of the client Weak points – Operational: Attention to professional presentation details Individual proof reading – STILL NEEDS WORK Using compatible text editors – IMPROVED! – Technical: Little to no experience working with PHP or the Moodle platform Team has been actively mitigating this issue. – IMPROVED! 2

Source of Observations - NO CHANGE SINCE PREVIOUS ARB Standard end of week tag up +1 short mid-week tag up using Google+ hangouts WinWin negotiation sessions Bug tracking activities Audio recordings of interactions with the client 3

ACCEPTANCE TEST PLAN & CASES (ATPC) David Wiggins – Remote Student 4

Capability Requirements Coverage 5

Test Dependencies 6

Test Cases 7

OPERATIONAL CONCEPT DESCRIPTION Suchita Doshi 8

System Objectives The objective of the system is to provide the students with more accessible courses Single system with the ability to add more courses with an option to buy the licenses online and creating the user profile automatically. Ability to maintain the student profile and generate reports. 9

Benefits chain 10

11

System Boundary 12

System Boundary 13

Proposed Workflow 14

Core Capabilities Simple username and password for the users Flash to HTML 5 conversion Data Migration Availability of username and password immediately after buying courses Report generation Documentation/Video Tutorials Forgot Password functionality Videos in HTML 5 format User management to other Organizations Sales Website 15

Constraints and goals Goals: Cost savings Increase sales Students Satisfaction Attract more donors Ease of Maintenance Constraints: Moodle Platform PHP MySQL HTML 5 Schedule 16

SYSTEM PROTOTYPE By: Shantanu Sirsamkar & Monty Shah 17

Sales Website: Start Page 18

Sales Website: Leamos Homepage 19

Sales Website: Option Select 20

Sales Website: User Form 21

Sales Website: Payment Confirmation 22

Sales Website: Paypal Integration 23

Sales Website: Paypal Confirmation 24

Sales Website: U/P Retrieval 25

Sales Website: Login Page 26

Sales Website: Login Confirmation 27

Data Migration – MSSQL to MySQL Prototype has been created to migrate data from one to one table, one to many tables, many to one table and many to many tables. Logic has been built to ensure the data never gets copied twice. 28

Moodle-HTML5 Compatibility 29

SYSTEM AND SOFTWARE ARCHITECTURE DESIGN By :Pragya Singh 30

System Context Diagram 31

Artifacts and Information diagram 32

Use Case Diagram 33

NDI and NCS The NDI's and NCS for our system are: 1.) NDI: Application NDI : The application NDI used in our system are Adobe wallaby to convert flash files to HTML5 format. System NDI: Leamos uses Language NDI's like PHP 4.3.0, HTML5, which are language NDI's. Database like NDI's MySQL to store database of Leamos students, staff and customer organizations, Apache as Server NDI. 2.)NCS: E-learning system such as Moodle 1.9 is used as the main NCS on which the whole system will be deployed, payment services like course merchant will be used to make payment for the customer organizations. 34

Hardware Component Model 35

Software Component Model 36

Deployment Diagram 37

LIFE CYCLE PLAN Swapnil Savdekar 38

Outline Project Phases in 577b 577b Roles and Responsibilities Cost Estimation using COTIPMO Tool Iteration Plan 39

Rebaselined Foundations Phase Duration: 09 January, 12 – 11 February, 2012 Recreate team and shared vision among stakeholders Review architecture, plan, risks Milestone: Rebaselined Development Commitment Review 40

Development Phase – Construction Iteration Construction Iteration 1: 15 February, 12 – 13 March, 12 Construction Iteration 2: 14 March, April, 12 Build upon the prototypes Implement and testing Working System Milestone: Core Capability Drivethrough 41

Development Phase – Transition Iteration Duration: 04 April, 12 – 07 May, 12 Transition and Installation at Client site Testing Defect Fixing Training, User Manual, Video Tutorials Milestone: Operations Commitment Review 42

577b Roles and Responsibilities Monty Shah (Project Manager / Trainer) Primary Responsibilities: Plan and Manage Project Detailed Project Plan Record Project Progress Secondary Responsibilities: Prepare Training Schedule Preapre Training Scenario 43

577b Roles and Responsibilities David Wiggins ( Tester / QFP ) Primary Responsibilities: Identify Test Plan and Procedures Perform Testing Record Test Results Secondary Responsibilities: Assess Quality Management Strategy Configuration Management 44

577b Roles and Responsibilities New Team Member ( Life Cycle Planner / Trainer ) Primary Responsibilities: Transition Plan Support Plan Secondary Responsibilities: Provide Training Prepare User Manual, Video Tutorial 45

577b Roles and Responsibilities New Team Member (Software Architect / Builder) Primary Responsibilities: Assess System Architecture Design and Develop System Secondary Responsibilities: Develop Glue Code Integrate Components 46

577b Roles and Responsibilities New Team Member (Builder / Tester) Primary Responsibilities: Tailor Components Fix Defects Secondary Responsibilities: Create Test Plan and Test Cases Alpha and Beta Testing 47

577b Roles and Responsibilities New Team Member (Builder / QFP) Primary Responsibilities: Implement Components Perform Core Capabilities Drivethrough Secondary Responsibilities: Assess Traceability Matrix Assess Quality Management Strategy 48

Cost Estimation Using COTIPMO 49

Project Estimates 50

Project Estimates 51

Project Estimates 52

Scale Drivers 53

Scale Factors 54

EAF – Password Recovery 55

EAF – Data Migration 56

ITERATION PLAN Swapnil Savdekar 57

Iterations 2 Iterations : Construction Iteration 1 Construction Iteration 2 58

Capabilities to be Implemented 59

Capabilities to be Implemented 60

Transition Deployment of System Migrated Data and Website Testing User Manual 61

Stakeholder Roles, Responsibilities and Transition Schedule 62

FEASIBILITY EVIDENCE DESCRIPTION Monty Shah 63

Major Risks for 577B 64 1) New team members required: Most team members are not continuing to 577B Need new team members with php and MySQL expertise Mitigation strategies: Prototypes have been developed for Data Migration (SQL and MySQL), Sales Website (php, MySQL and Moodle) and HTML5 on Moodle (php)

Major Risks (continued) 65 2) Dependencies: To implement Sales website, Course Merchant will be used but it has not been implemented yet. Any bugs on the Course Merchant will affect the Sales Website development Mitigation strategies: Prototype has been developed for Sales Website using PayPal as a payment gateway. Same will be developed further till Course Merchant implementation is completed.

Major Risks (continued) 66 3) Development Environment: Need to set up a development environment replicating the Clients environment Clarity is currently facing an issue with the Leamos system. Schema and data of new database has to be shared Mitigation strategies: Prototype have been developed for data migration for the following scenarios – one to one, one to many, many to one and many to many table migration. David has installed Moodle on his website and the prototypes (sales website and HTML5 videos on Moodle) have been developed on the Moodle platform. Client has agreed to create a sandbox as soon as the Clarity issue is resolved.

NDI/NCS Feasibility Analysis Moodle – Client is currently using Moodle for the Course Management and hence all the features need to be developed on the Moodle platform. Need a tool to convert flash files to HTML5. 67

NDI/NCS Feasibility Analysis (continued) 68

NDI/NCS Feasibility Analysis (continued) 69

Level of Service Feasibility 70

Capability Feasibility 71

Cost Analysis – Personal cost 72

Hardware cost and software cost 73

Benefit Analysis 74

Benefit Analysis 75