Milestone Two – Reach Across Houston (RAH) Tuesday, June 14, Team:Matthew Edwards Thomasina Coates Michelle Graham James Henrydoss James McNicholas

 Project Summary  Development Team  Milestone-Two Deliverables  SRS  PMP

 Project Name – RAH (Reach Across Houston) Website Redesign  Project Scope - To rebuild the RAH website with extended functionalities  Client: RAH – Reach Across Houston ▪ A Non-profit organization provides job-oriented training to teens and adults in Houston area

Project Summary  Team  Matt Edwards – Team Lead  Michelle Graham – Project Manager  Thomasina Coates – Lead Analyst  James Henrydoss – Lead Architect  James McNicholas – Lead QA Tester Tuesday, June 14, 20164

 Project Status  To-Date  We are currently at the Requirements Phase of the SDLC  Project Management Plan (PMP) ▪ Risks ▪ Schedule  Software Requirements Specification (SRS) ▪ Overview ▪ Changing ▪ Lessons Learned Tuesday, June 14, 20165

 Complete SRS  Software Project Management Plan (Revised)  SRS Development Presentation

Approval and Sign-off Tuesday, June 14, SignaturePrinted NameTitleDate Matthew EdwardsTeam Lead Thomasina CoatesAnalyst Michelle GrahamProject Manager James HenrydossLead Architect James McNicholasLead QA The following presentation has been accepted and approved by the following:

 Team implemented the following two disciplined approaches to develop RAH SRS  Problem Analysis ▪ Problem Description  Requirements Specification ▪ SRS Preparation

 Team used the following software tools in the development effort  Assembla – Ticketing and Tracking the assignments and events  Microsoft Visio 2002 – UML Case and Sequence Modeling  Microsoft Project – Project Management Plan  Axure – Website GUI tree visualizing & tracking

 SRS Status and Overview  Requirement gathering interview with client, including one questionnaire.  The requirements were entered into a dynamic matrix (UIR, SR, and FR) to be used throughout the life cycle.  Section I – provides an introduction to the SRS document. It also includes the projects; purpose, background and scope. Tuesday, June 14,

 Section 2 – provides a General Description of the Products Perspective and Functions  Constraints and Risks are also identified: ▪ RAH is a NPO and does not have a large operating budget. It will be necessary for Mountain Technology to keep this in perceptive as they design the system. It should also be important to note that because of the budgeting concerns special emphasis will need to be paid to the cost of system maintainability. ▪ Users must have a web-browser and access to the internet to utilize the application. ▪ Users must have Adobe Acrobat reader installed to view.pdf forms with data. ▪ The existing RAH website is hosted on an alternate service provider. ▪ Data content for the web pages will not be identical from the existing to the redesign website. ▪ Level of expertise for the RAH staff who will support and maintain the website is not known, because the technical. ▪ Potential constraints with external interfaces such as PayPal or database builds. ▪ Project resource. ▪ Unknown software limitation or not having necessary software to design website. ▪ Unknown system limitations. ▪ The following risks may effect the project’s delivery date. ▪ Any delay or interrupt in the user requirement gathering process. ▪ Change in management or project’s key personnel. ▪ Change in company’s goal and objective

 This section also identifies Assumptions and Dependencies as: ▪ The use of the application is dependent on the users desire to receive the provided information. It is up to the client to notify potential parties about the website. Without such notification the sites success will be dependent on basic web search placement of the site. ▪ The application will be dependent on hosting services. ▪ The application will need to be maintained by the client in order to stay relevant. ▪ Users responsible for maintaining the system will have a technical understanding if web-application maintenance. ▪ It is assumed that visitors to the site will have a basic understanding of how to navigate a web-page. ▪ It is assumed that visitors will be able to read English. ▪ It is assumed that the system will be available 24/7 (except when scheduled down time for maintenance or upgrades is needed). ▪ It is assumed that all screens will meet the Rehabilitation Act Section 508 requirements. ▪ The next phase is dependent of timely user requirements gathering and business rule decisions. ▪ The successful implementation of this application is dependent upon the customer having the required hardware and software.

 Section 3 – identifies the Specific Requirements gathered from the client  Specific Requirements include: ▪ Functional Requirements, a dynamic matrix used to identify the requirement and the priority as: High, Med, and Low. For ex.

 Section 4 - provides additional requirements  External Interface Requirements to include ▪ User ▪ Hardware ▪ Software ▪ Communication

 Section 5 – Non Functional Requirements is the catch all for those requirements required but do not directly impact the development of the project.  Performance  Reliability  Availability  Security  Portability  Design Constraints  System Response Time

 Section 6 – Logical Database Design  This project’s database will be hosted by another provider  Section 7 – Change Management Process  Includes a section about the Change Control Board.  Use Cases – a pictorial of the systems functions  A Sign off of the document by all parties

SPMP  Software Project Management Plan (SPMP) ▪ Configuration Management ▪ Communication Plan ▪ Schedule ▪ Risks Tuesday, June 14,

SPMP Cont.  Configuration Management  Documents  Versions  Source Code Tuesday, June 14,

SPMP Cont.  Communication Plan  Objectives  Audiences  Delivery / Contents Tuesday, June 14,

SPMP Cont.  Schedule Tuesday, June 14,

SPMP Cont.  Risks  General Design Constraints  Design Dependencies Tuesday, June 14,

Tuesday, June 14,