Cap

Copyright 2011

All rights reserved.

ACKNOWLEDGEMENTS

Individual contribution to a fast-paced group project can lend value in a variety of ways, some non-traditional.

TABLE OF CONTENTS

EXECUTIVE SUMMARY ……………………………………………………………….. 1

SECTION ONE: INTRODUCTION …………………………………………………… 3

PROJECT VISION ……………………………………………………………………….. 3

OVERVIEW STATEMENT ……………………………………………………………… 4

A Problem ………………………………………………………………………… 4

A Solution ………………………………………………………………………… 4

Stakeholders ………………………………………………………………………. 6

Benefits ……………………………………………………………………………. 6

Nonfunctional Requirements ……………………………………………………… 7

PROJECT FEASIBILITY ………………………………………………………………… 10

TEAM STRUCTURE AND CAPABILITIES ……………………………………………. 12

SECTION TWO: PROJECT PLANNING AND DESIGN …………………………… 15

PROJECT MANAGEMENT ……………………………………………………………… 15

Project Plan ………………………………………………………………………... 15

Risk Analysis ……………………………………………………………………… 17

Problem Analysis …………………………………………………………………. 22

System Metrics ……………………………………………………………………. 23

DATA FLOW DIAGRAMS …………………………………………………………..….. 25

SYSTEM INTERFACES AND DESIGN ………………………………………………… 29

Visualization ………………………………………………………………………. 30

Efficiency …………………………………………………………………………. 32

Functionality ………………………………………………………………………. 33

Database …………………………………………………………………………… 35

Prototype …………………………………………………………………………... 36

Sponsor Feedback …………………………………………………………………. 37

CLASS DIAGRAMS AND DATABASE DESIGN ……………………………………… 39

QUALITY ASSURANCE ………………………………………………………………… 41

System Testing ……………………………………………………………………. 41

Defect Tracking …………………………………………………………………… 42

Technical Reviews ………………………………………………………………… 42

Change Control …………………………………………………………………… 43

SECTION THREE: PROJECT CLOSEOUT …………………………………………. 44

IMPLEMENTATION ……………………………………………………………………... 44

History …………………………………………………………………………….. 44

Status at Delivery …………………………………………………………………. 46

Working with Third-Party Service Providers …………………………………….. 47

DEFECT REPORT ……………………………………………………………………….. 50

FINAL USABILITY REPORT …………………………………………………………… 51

LESSONS LEARNED ……………………………………………………………………. 54

Project Management ………………………………………………………………. 54

Systems Development …………………………………………………………….. 59

REFERENCES …………………………………………………………………………… 62

APPENDICES ……………………………………………………………………………. 65

Appendix A: Interviews …………………………………………………………… 65

Appendix B: Client Agreement …………………………………………………… 72

Appendix C: Scope, Complexity and Work Plan Estimates ……………………… 74

Appendix D: Project Schedule ……………………………………………………. 81

Appendix E: Task Assignments …………………………………………………… 83

Appendix F: Test Plan …………………………………………………………….. 87

Appendix G: Test Results …………………………………………………………. 93

Section 1: Technical Review Results ……………………………………… 93

Section 2: Unit Level Test Results (Sample) ……………………………… 98

Section 3: System Level Test Results ……………………………………. 104

3.1: Integration Test Results ………………………………………. 104

3.2: Browser Compatibility Test Results …………………………. 110

3.3: Usability Test Results ………………………………………… 114

Section 4: Acceptance Test Results ………………………………………. 119

Section 5: Defect Log …………………………………………………….. 123

Appendix H: Data Dictionary …………………………………………………….. 125

Appendix I: Sample Source Code ………………………………………………… 128

Appendix J: Directory Structure ………………………………………………….. 130

Appendix K: Configuration Files …………………………………………………. 132

Appendix L: Meeting Minutes ……………………………………………………. 133

Appendix M: School Event Coordinator User Guide …………………………….. 149

Appendix N: Site Administrator User Guide ……………………………………… 169

Appendix O: Faculty Presentation ………………………………………………… 186

LIST OF FIGURES

Figure 1: Projected High-Level Schedule ………………………………………………… 21

Figure 2: Ticket Purchaser Data Flow Diagram ………………………………………….. 26

Figure 3: Event Coordinator Data Flow Diagram ………………………………………… 27

Figure 4: Site Administrator Coordinator Data Flow Diagram …………………………… 28

Figure 5: Home Page ……………………………………………………………………… 31

Figure 6: School Control Panel ……………………………………………………………. 32

Figure 7: Adding an Event ………………………………………………………………… 34

Figure 8: Adding a Ticket …………………………………………………………………. 34

Figure 9: Configuring an Account ………………………………………………………… 35

Figure 10: Class Diagram …………………………………………………………………. 40

Figure 11: Code and Design Review ……………………………………………………… 94

Figure 12: Browser Compatibility Test on Internet Explorer 8 …………………………… 110

Figure 13: Browser Compatibility Test on Google Chrome 10 …………………………… 111

Figure 14: Browser Compatibility Test on Mozilla Firefox 4.0 ………………………….. 112

Figure 15: Browser Compatibility Test on Safari 5.0.4 …………………………………… 113

Figure 16: Usability Test Survey ………………………………………………………….. 115

Figure 17: Directory Structure …………………………………………………………….. 131

LIST OF TABLES

Table 1: Analysis of Potential Risks to SchoolTicketsOnline.com ………………………. 18

Table 2: Usability Survey, Question One Results ………………………………………… 116

35

EXECUTIVE SUMMARY

Without question, the Web has transformed the way organizations gather and disseminate information. It has also changed the way they operate, behave and provide their goods and services (Turban et al., 2008). This is true for all sizes of business and levels of government. The Web has not only impacted daily commerce, for example, it has perhaps changed our expectations of it. Where the debit card was largely a convenience five years ago, today’s cash-only merchants will likely suffer from an emerging cashless society if they do not embrace this seemingly irreversible technological trend.

The growing expectation of how we purchase and retrieve entertainment tickets is also evident. The online resale market for commercial tickets is growing rapidly. Estimates of annual sales over websites like StubHub, eBay, Craigslist, RazorGator, TicketsNow, Ticket Liquidator, and others is expected to reach $4.5 billion by 2012 (Kirkman, 2009). With this in mind, SchoolTicketsOnline.com is an attempt to meet a growing trend that economically and resourced-strained public schools are generally unable to meet: the use of web-based technologies to sell and distribute tickets to school events in a manner that facilitates the communication of event limitations, monitors demand, and enables secure transactions. This problem is paradoxically troublesome for extracurricular activities such as sports, music, theatrical, and festival events, which require ticket sales for their sustainment.

A solution that may meet a demand in a strained economic climate as well as solve challenges associated with traditional ticket sales is to provide any primary or secondary public school with a free Software as a Service platform designed with an efficient, flexible and portable method to administer and sell tickets online to any identified school event. SchoolTicketsOnline.com was designed with proven and commonly used technologies, which provide flexibility in hosting the website, ease of enhancements and simplified maintenance. The use of HTML, CSS, PHP and MySQL, for example, are supported across multiple platforms by numerous vendors. More importantly, approved School Event Coordinators gain a stable and secure web-based application, which was designed to operate with commonly used database technologies to mitigate risk throughout the lifecycle.

Given this Capstone necessitated a disproportionate focus on time, the design approach centered on a carefully scoped base-set of features to meet the deadline for the successful launch of the application. Though the project did not ultimately benefit from the full potential of every team member, all features were delivered on time and exceeded sponsor expectations. Sound project management, careful coding, diligent test planning, and thorough documentation ensured that the project team delivered a fully functioning service with the best quality possible. There were also enough interviews conducted to suggest that a user community exists for this service, and it is eager.

With the project now complete, it is hoped that the sponsor will use SchoolTicketsOnline.com to fill – free-of-charge – a needed gap for financially and resource-strained public schools. This website will, in turn, provide an eventual vehicle for revenue opportunities, primarily through advertisements, sales of user listings and add-on merchandise. Most importantly, students, parents and alumni will be presented with an alternative, safe, and secure method for finding, purchasing and retrieving event tickets that is in keeping with well-known and accepted Web and database technologies, proven third-party vendors, risk management best practices and, perhaps, existing expectations.

SECTION ONE: INTRODUCTION

VISION STATEMENT

To provide any primary or secondary public school with a free Software as a Service platform designed with an efficient, flexible and portable method of administering and selling tickets online to any identified school event. The application, which is registered and functioning as SchoolTicketsOnline.com, is a service that can be used by an unlimited number of schools through one easy-to-use website. Each participating school will have its own interface as well as a private area on a centrally managed server where transaction data is secure and available on-demand through third-party service providers. It is hoped that resource strapped public schools will benefit the most from this service. The site owner can, in turn, benefit from advertising and other revenue opportunities once the website gains a broad acceptance.

OVERVIEW STATEMENT

A Problem

In today’s strained economic climate, public schools typically struggle with shrinking budgets and far fewer available resources. This problem is especially troublesome for extracurricular activities such as sports, music, theatrical, and festival events. In addition to common fundraisers, ticket sales often sustain these activities. The traditional way for schools to sell tickets is either by collecting money from students prior to the event or by collecting money at the event. Both of these methods pose challenges. Collecting money from students prior to an event requires them to act as promoters, collectors, and distributors. Peer pressure, bullying, and discrimination among students could result from these activities (Clasen & Brown, 1995). Collecting money at the event, moreover, can lead to security concerns such as those sometimes posed by angry parents when an event sells out unexpectedly. In both cases, the handling of cash is required, which brings in additional concerns.

A Solution

This project will provide any interested primary or secondary public school with a free Software as a Service platform designed with a flexible method of administering and selling tickets online for any school event. SchoolTicketsOnline.com is intended to be a mutually beneficial service that can be used by multiple schools through one easy-to-use website. The availability of a third-party ticket sales website offers schools relief from the financial and resource burdens of managing their own. It also relieves students from the pressures associated with collecting, distributing, buying, and managing tickets at or before an event. The website can also facilitate event communication, monitor demand, and enable turnout estimates.

After conducting interviews with the project’s sponsor and other potential stakeholders, the design approach centered on the following minimum base-set of features that was required the meet the deadline for a successful launch of the application under the inherent time constraints of this Capstone. See Appendix A: Interviews and Appendix C: Scope, Complexity, and Work Plan Estimates for further details on how the scope was molded and how the following requirements where subsequently gathered:

· A simple yet effective website design, which will include a home page, registration page, login page, terms of service page, and privacy policy page

· All pages, graphics, coding, design and work to run the site, including approximately 40 programmatically generated web pages

· Installation of the application on one web-hosting provider with a virtual hosting environment

· Search for school and event using state, city, and zip code or school ID

· Shopping cart that allows the purchase of school event tickets via PayPal

· Email confirmation of all orders

· Backend management area for schools to enter events and tickets

· No more than two reports for the School Event Coordinators

· Backend management area for Site Administrator to manage member schools

· Adequately document database and web interface design for flexibility, maintainability, and portability

· Documentation for the installation, daily operation, and troubleshooting of the website application

· An ability to conduct full and partial backups

Stakeholders

The primary stakeholder for this project was Mr. Jeff Martin, who was also its sponsor. He is the Director of Application Development at an insurance company located in Scottsdale, Arizona. His employer is active in the United Way Campaign and the American Red Cross, as well as heavily involved in community outreach programs like the Boys and Girls Clubs of America and local food banks. Mr. Martin, who is, by extension, also an active participant in the local community, brought expertise in business process engineering to this project that was aimed at helping public schools in historically tough economic times.

Once the project concludes, the sponsor intends to immediately offer the website and its underlying services. Two major groups of users also served as stakeholders. The first group consisted of School Event Coordinators from their respective schools. These coordinators will use the system via a specified interface to set up the ticket sales for their events. The second group of users was those who are assumed to purchase tickets, which includes parents, relatives, alumni, and friends of the students involved. See Appendix A: Interviews for a description of the two interviews conducted with Mr. Martin, as well as detailed summaries of each.

Benefits

It is important that SchoolTicketsOnline.com provides the types of services that will directly benefit participating schools as well as make it easy for ticket purchasers to find and purchase tickets to school events. There are several benefits of providing Software as a Service to the primary stakeholder and both groups of users. The primary stakeholder may fill a needed gap for financially drained public schools, which will, in turn, provide the website owner an eventual vehicle for revenue opportunities. (The latter is outside the scope of this project.) Software as a Service lowers costs for organizations by utilizing software over the Internet rather than purchasing licenses for the needed application on every hardware device. School Event Coordinators will gain a stable and secure web-based application, which was built and run on proven web and database technologies to mitigate risk for either party (Lewis, 2007). In addition, ticket purchasers will be presented an alternative method for finding and purchasing event tickets from their respective schools. School Event Coordinators may even be able to account for the influence of promotional efforts on ticket sales, which could help the sponsor with adjusting advertising fees and rates (Putler & Lele, 2003).

Nonfunctional Requirements

Generally speaking, when examining the requirements of website functionality, a client may be interested in, for example, whether the navigation of the website should be intuitive or deliberate, how fast a page should display when complex graphics are desired, and the overall availability of the website during estimated peak usage (Heim, 2008). These aforementioned examples of non-functional requirements were no less applicable to SchoolTicketsOnline.com. When practical and possible, desired and/or recommended non-functional requirements were incorporated and quantified. For example, uptime of the website as well as bandwidth and disk space usage can be measured and adjusted as SchoolTicketsOnline.com matures in the marketplace. SchoolTicketsOnline.com is hosted by HostGator.com, which claims to have a 99.9% uptime guarantee (2011). HostGator.com also claims to have unlimited bandwidth and unlimited disk space for the selected price point.

Given the initial lack of sponsor-desired robustness, performance was not optimized. Therefore system metrics were not used. Although high traffic and click volumes were not initially anticipated, the project team felt an obligation to pay attention to the security of any user who interacts with SchoolTicketsOnline.com. It was also important that the project team deliver, at the very minimum, adequate backend supportability to ensure that the Site Administrator has the proper set of tools available to facilitate website functionality and sustainability. This was accomplished through system level testing. For example, security best practices require passwords to be hashed (non-reversible) with unique hash "salts" (Whitman and Mattord, 2009). This prevents the use of "rainbow" tables from being used to crack passwords in the event that the database is compromised. Since no credit card data or sensitive personal data will be gathered at the site, Secure Sockets Layer (SSL) encrypted pages are not required. Database access will be password-protected and configured in the application configuration file.

While there was no requirement for high availability, the system needed to support full and partial backups as part of a routine operation provided by the web host. Monitoring of any type was not within the scope of this project. The system did not need to send administrative emails or alerts except as part of the ticket purchase function. Upon completion of all web development, the project team transferred all work over to its sponsor. This consisted of all source code, project documentation and support documentation, including a data dictionary, directory structure, and configuration files. Documentation or a description of documentation delivered to the sponsor, including a sample of the source code can be found in the Appendices of this report. It is understood by the sponsor that this project team will not provide support post-delivery. (See Appendix B: Client Agreement for further details.)

Other non-functional requirements, while not specifically requested by the sponsor, were delivered either indirectly through the selected third-party web host or incorporated into the application at the discretion of the project team:

· Efficiency: HostGator.com claims to have unlimited bandwidth and disk space. The site owner for SchoolTicketsOnline.com anticipates low click volumes. Thus design principles centered on simplicity. Developers used File Transfer Protocol (FTP) and web tools to upload and download web files.

· Flexibility: HostGator.com offers increased functionality via a wide range of scripting languages, databases, templates, pictures, software tools, and fonts. The project developers used MySQL for scalability, as well as CodeIgniter and JQuery. HostGator.com also offers easy web administration, including traffic reports and manual backups of both the website and database.

· Maintainability: SchoolTicketsOnline.com was coded in HyperText Markup Language (HTML), Cascading Style Sheets (CSS), PHP (which originally stood for personal home page), and JavaScript. The scripting languages used will not require an administrator to compile the code, which makes for simple integration. Asynchronous JavaScript (AJAX) works with HTML and CSS code, using JavaScript to display information accessed directly from the database (Wilder, 2007).

· Portability: SchoolTicketsOnline.com was designed with HTML, PHP, MySQL, and CSS. These technologies are industry standards and are supported across multiple platforms by numerous vendors. The application supports different web browsers, including Microsoft’s Internet Explorer, the most commonly found browser in terms of market share, as well as two of the most popular browsers in terms of the number of downloads, according to cnet.com: Mozilla Firefox and Google Chrome (2011).

PROJECT FEASIBILITY

The development of a computer-based information system will likely be plagued by a scarcity of needed resources and difficult delivery dates. With regard to the latter, this project was not an exception. It was, therefore, both necessary and prudent to at least informally evaluate the feasibility of SchoolTicketsOnline.com within the first week of its proposed genesis and update said feasibility once sponsor requirements became firm. The team’s Project Manager and its Principal Developer were especially cognizant of scope when examining economic, technical, and even legal feasibility, as these were critical areas that could have led to underestimating the scope of the project (Schwalbe, 2006). One potential sponsor for a different project idea, for example, had immediate concerns with intellectual property rights and protection, so the group passed on what was an interesting opportunity.

The team analyzed several potential problems during the project’s selection, initiation, and planning stages. Given the fast nature of the project (ten weeks from concept to delivery of a fully functioning and documented system), the biggest concern was that of inadequate requirements definition and scope changes. The team mitigated both by working with a willing and understanding project sponsor. In the interest of time, the team made assumptions about the requirements of ticket purchasers as a user group. Interviews provided enough detail to understand the overall vision of the application and needed objectives. In addition, central to risk mitigation was the deliberate utilization of proven technologies to both develop and deliver functionality (Lewis, 2007). The analysis of skill sets and experiences enabled the alignment of applications and technologies that are not only common but were familiar to the project team members (Dennis et al., 2005).

Though it may be argued that a formal feasibility study was not warranted for this project given the minimally associated financial costs and relatively low technical risk to achieve the vision of SchoolTicketsOnline.com, the project team and its sponsor were wary of time and scope. The team assumed that the website will eventually provide a business value. The team also assumed that if the service was built and delivered as agreed, end users would be responsive. The residual concern was the project’s technical feasibility. In other words, could it be built in time? (Dennis et al., 2005). Though carefully managed, technical scope creep invariably posed risk to development timelines and the project team’s subsequent ability to deliver an error-free product. (See “Implementation” on page 44 for further information.)

TEAM STRUCTURE AND CAPABILITIES

The project team consisted of five members, each contributing to a collective and productive balance of skill sets and professional experiences that were directly applicable to the project. Each member averages 14 years of experience with information systems and technologies. Additionally, nearly every member holds multiple professional and relevant IT certifications. Each member was highly effective offering (albeit only initially) the team their respective skill sets, experiences, strengths, and limitations through resumes and frank discussion. Early and efficient group dynamics greatly facilitated role and task assignments.

Eric Clifford served as the Project Manager. Mr. Clifford is a Certified Information Systems Security Professional, Certified Secure Software Lifecycle Professional, Network+, and Project + certified professional with 17 years of program, project, facility, and personnel management experience as a contractor to the Departments of Defense and Homeland Security.

George Hubert filled the pivotal role as the project's Principal Developer and sponsor interface. He is an action-oriented strategic and tactical information technology leader with a proven track record of managing a broad range of IT teams and projects. With 22 years of experience, inclusive of areas in web and eCommerce development, vendor management, and database design, Mr. Hubert, a Microsoft Certified System Administrator, Technology Specialist, and System Engineer, also served as the project team's Client Advocate.

Serving as Mr. Hubert's design and programming deputy was Ryan Huynh, who brought over 20 years of network engineering experience in the fields of system design, cryptography, and programming on U.S. Navy shipboards, submarines, and network operating centers. Working in high-stress environments and on highly complicated systems, Mr. Huynh is equipped with a wealth of collective knowledge and skills in nearly 100 programming languages, hardware platforms, applications, protocols, and operating systems. He also holds multiple certifications, including those vetting expertise with Windows, Cisco, Linux, and embedded computing.

Christian Larsen is a Cisco Certified Network Associate. Mr. Larsen, who is also a Microsoft Certified System Engineer, as well as certified A+, Network+ and Security+ by CompTIA, is experienced with local and wide area network management, server configuration and administration, network cabling, user administration, security, and system analysis and optimization. As such, Mr. Larsen, utilizing his skills as a technical writer, served the project team as its Quality Assurance Manager.

Each team member initially posed no significant limitation since project tasking was quickly identified and assigned based on skill set, experience, and relative strengths and weaknesses. A good example of this approach was the team’s fifth member, Walter Egeler, who demonstrated a willingness to learn and take on responsibility. Mr. Egeler, who works at the team's very own National University, is experienced with graphics applications and technical writing. He was to play a role in crafting and presenting final deliverables to the project sponsor, but fell short. To that end, he was asked to aid Mr. Larsen's Quality Assurance efforts, but fell short there, too. In an effort to maximize Mr. Egeler’s contribution, the Project Manager focused his efforts on providing lessons learned, if any.

Group dynamics were generally positive and productive throughout the project. Every member stayed engaged, though two consistently strayed from tasking. The Project Manager demonstrated clear communication styles and expectations. After a deliberate inventory of skills for the project, it was determined early that the project team was not deficient in any skill or area. To highlight this conclusion, Mr. Hubert demonstrated extensive experience with database design, PHP 5.3 for the project's development platform, MySQL 5 with the CodeIgniter 2.0 framework, JQuery JavaScript library, and CSS to control the style and layout of multiple web pages. Working in concert with all development efforts, Mr. Huynh used his experience with HTML, FrontPage, Dreamweaver, JavaScript, PHP, and MySQL, as well as his knowledge of HTTP, TCP/IP, SMTP, FTP, and Internet Explorer, and Firefox to comment on progress. Since the planned web host for the project was HostGator.com, the configuration of the hosting environment was not part of this project. (See Appendix E: Task Assignments and Appendix L: Meeting Minutes for further detail.)

SECTION TWO: PROJECT PLANNING AND DESIGN

PROJECT MANAGEMENT

Project Plan

Project management is the art of adequately balancing communication, knowledge, skills, risk, technologies, tools, and techniques in the hopes of delivering a project as agreed upon or as expected. Project management must also account for competing demands, including the project’s goals as articulated through scope, almost certain time constraints, planned and unplanned financial costs, and quality – regardless of its measurement. While project management is an art that must adjust to constraints, project planning is, comparatively speaking, black and white. Known as the “quadruple constraint,” the project manager must choose which of the four constraints – scope, time, cost and quality – are the most important and adjust accordingly (Schwalbe, 2006).

The nature of this Capstone necessitated an unordinary and disproportionate focus on scope and time. In short, the group chose to emphasize scope and time over cost and, to a degree, quality if it hoped to be relatively successful. The group managed the project’s scope through statements (e.g., vision and feasibility), by quasi-formal work breakdown structures via detailed tasking and through continuous requirements analysis. Time was managed primarily through milestones, Gnatt-like charts, critical-path scheduling, and fast tracking. The latter technique shortens project schedules by doing activities in parallel that one would normally do in sequence (Schwalbe, 2006). Fast tracking was also utilized by encouraging group members to design and write based on assumptions. (See Appendix E: Task Assignments for further detail.)

Project planning and execution enabled quick adjustments to task slips. The project did not suffer from any deviation from its vision or feasibility. Early, strong planning may have actually strengthened it. All functional and non-functional requirements were initially identified from the outcome of the interviews with the sponsor as to the look, navigation, and output of the system. While there were also no deviations from the project’s project plan or work plan estimates, the project did slip during Milestone Three, when web interface development did not show needed progress by the end of the fifth week. Since interface design simplicity was central to the project’s scope, the goal by the end of Milestone Two was to have a pre-existing, template-driven site enabled for functional prototyping. These templates, save for minor adjustments, also served as the final layout.

Finally, while there were changes to areas of responsibility assigned to two group members at the conclusion of Milestone Two, work plan estimates remained accurate. Where some members fell short in level of effort, understanding, and/or quality of work required to realize these estimates, others were effective in filling subsequent gaps. This was also evident during system testing when test cases were not written as planned or produced when needed. (See Appendix L: Meeting Minutes for further information.)

The project size stayed in line with provided timelines to include an absolute inability to miss specified delivery dates. Project alignment remained evident throughout its life. In short, SchoolTicketsOnline.com was delivered on time and the design exceeded stakeholder expectations. The Principal Developer and Quality Assurance Manager provide high quality and exhaustive contributions. See “Implementation,” p. 44 for the project’s history and implementation status at delivery. Also see the project’s “Final Usability Report,” p. 51, which details the likelihood of the presence of minor system errors at delivery and recommended improvements based on end user testing.

Risk Analysis

The analysis phase of the system development life cycle is arguably the most important. Ensuring as early as possible that the right requirements are captured is critical to a project’s success. If, in the end, a developed information system or application does not meet the user’s needs, the project will likely be considered a failure, even if some derivative value is gained (Bandara et al., 2005). Once requirements are gathered, the analyst can create logical models, such as activity or class diagrams, to depict entities, activities, enablers, and relationships between them without being distracted with implementation details (Dennis et al., 2009). From this point, a risk analysis can be conducted.

The risks associated with this project were classified as they related to scope, time, cost, and/or quality (Galway, 2004). Scope-related risks included additional features requested by the project sponsor and additional functional and non-functional requirements realized by the project team during the development phase of the web application. Time-related risks included deadlines for each milestone and related tasking therein, high-level schedule, and overall time management. Cost-related risks covered all concerns relating to budget and allocation of funding. Quality-related risks included system development factors and the measurable worth of the final product, including the performance, security, maintainability, fulfillment of end user requirements, and final delivery of an error-free system.

Analysis of the identified potential risks utilized the Failure Mode Effects Analysis Methodology (Lewis, 2007). Table 1 outlines each risk that was identified, the probability of the risk occurring (P), the measure of risk severity (S), the ability to detect the risk (D), and the risk probability number (RPN). The level of risk was defined by the RPN, which was calculated by multiplying the P, S, and D. Higher RPN correlates with greater risk.

Table 1

Analysis of Potential Risks to SchoolTicketsOnline.com
Identified Risk	P	S	D	RPN
Failure to meet final deadline	3	10	4	120
Failure to complete each phase according to schedule	3	7	3	63
Improper time allocation for each task	6	4	4	96
Loss of team member	2	6	6	72
Other time management failures	4	3	4	48
Project running over budget	2	7	3	42
Loss or change in funding expectation	1	6	3	18
Non-delivery or delayed receipt of funding	1	5	3	15
System does not provide required functionality	3	9	3	81
System does not perform are required level	2	8	3	48
Presence of security vulnerabilities	3	9	4	108
Inability to maintain system after delivery	3	6	4	72
Presence of system errors upon delivery	4	7	6	168
Design does not meet stakeholder expectations	3	10	5	150
End user requirement deviations from initial scope	2	7	5	70

The following list contains the five potential risks determined to have the highest risk probability number, as outlined in the preceding analysis:

1. Presence of system errors upon delivery

2. Design does not meet stakeholder expectations

3. Failure to meet final deadline

4. Presence of security vulnerabilities

5. Improper time allocation for each task

The probability of any one of these five risks occurring was relatively low. Given that the project team had appropriately scoped the project, they were considered in the project implementation plan as well as the risk mitigation strategies, outlined below, due to the high level of severity associated with each. The risk mitigation strategy was particularly important for those risks determined to have a low level of detectability.

Identified risks were managed at each phase of the project in order to maintain the perspective required to regulate each risk. The following are the risk mitigation strategies (e.g., risk avoidance) that focused on each major risk identified in the previous section. Central to each of these strategies is the use of proven technologies to both develop and deliver functionality, as well as the incorporation of best practices for testing (Lewis, 2007).

a. Presence of system errors upon delivery

Mitigation of this risk relied on adequate planning of scope and system design, followed by thorough and timely technical reviews and robust testing. At the beginning of Milestone Three the project team conducted a formal Code and Design Review to identify potential design flaws or coding errors, as well as to verify that the web interface design was consistent with group consensus and sponsor expectations. Testing was conducted throughout the system’s development and delivery and consisted of unit testing, system level integration and usability testing, and acceptance testing. Every aspect of the system was adequately tested, with a focus on the isolation of underlying systems flaws and errors, optimal usability, and delivery of an error-free system that would meet stakeholder expectations.

b. Design does not meet stakeholder expectations

The primary source of this risk was the potential ambiguity in defining system requirements. Project risk mitigation strategy relied on having a clear understanding of what the specific system requirements were and challenging assumptions and scope creep along the way. Fully understanding – and perhaps molding – stakeholder expectations augmented this process. The requirements were understood and agreed upon by stakeholders and the project team. The end user requirements were identified and clarified through end user and stakeholder interviews and used as the basis for system design, beginning with the initial planning phase. System testing included analysis of the system against the initial requirements provided to ensure each requirement was met. A minimum level of acceptable functionality was established, as the release of this product had to occur within the time parameters provided. Early design reviews by the project sponsor were critical and played a key role in avoidance of this risk.

c. Failure to meet final deadline

Mitigation of this risk depended on effective time management during each phase of the project. Failure to complete each phase according to schedule would have increased the level of risk associated with failing to meet the final deadline. Careful and deliberate project management was essential to meeting deadlines. The project team's ability to meet the final deadline was gauged at each phase in the system’s development and adjustments were made as required, to ensure that each milestone was completed according to schedule.

The projected high-level schedule, as determined during the initial risk analysis, is provided in Figure 1. This graph illustrates the completion percentage at each stage of the project (Galway, 2004). This estimation indicated that the project would be 60 to 80 percent complete by Week Six, with the final work and correction of any errors isolated from systems testing to be completed between the sixth and eighth weeks (the end of Milestone Four). This estimation proved to be accurate.

Figure 1: Projected High-Level Schedule

d. Presence of security vulnerabilities

Security concerns were addressed during initial planning and the technical review. They were further addressed through system testing. The bulk of this risk was avoided through the use of an established third-party web hosting provider as well as a leading third-party payment gateway. The database and web interfaces are sufficiently protected against unauthorized access, using proper error handling methods, hashing of passwords, and user login/logout capability.

e. Improper time allocation for each task

Each phase of the project was composed of discrete and defined tasks. Accurate planning and time estimation were essential. Amendments were made to the project plan to offset the impact of any delays in task completion, which lessened the impact on subsequent deadlines. Additionally, this risk was mitigated by careful and deliberate project management, which included regular meetings, followed by minutes of those meetings, detailed tasking, and adjustments when needed. (See Appendix E: Task Assignments and Appendix L: Meeting Minutes for further detail.) During Milestone Two, for example, efforts to enhance the website’s interface design (beyond the templates the project ended up using) were suspended due to lack of production, a common misunderstanding of tasking, and the unforgiving deadlines of this Capstone.

Problem Analysis

Organizational

Since this project was largely entrepreneurial, there were no traditional organizational issues such as size, construct, or culture. “Organizational” constraints were instead geared toward National University faculty, project team members, and the expectations management of all project stakeholders. Problems related to team structure as they corresponded with faculty and team members included the incorrect assignment of or assumptions about roles, including inaccurate consideration of skill sets, academic capability, alignment of those achievements with each task, and, ultimately, faculty feedback. Full resumes of each team member were reviewed, and after careful consideration of individual skill sets, appropriate role assignments were agreed to at the conclusion of Milestone One. (See “Team Structure and Capabilities,” p. 12, for further detail.)

Team Members

The possible loss of a team member during this project could have had serious implications on the schedule. In the event that a team member was to be absent for any reason, the remaining team members agreed to fulfill that individual's responsibilities. Cross-training and sharing of duties minimized potential negative impacts that this problem presented. In addition, the desire for effective communication by all team members was paramount. The Project Manager facilitated all meetings, created an easily understood project schedule (with detailed milestone tasking), presented ideas clearly and concisely, and kept discussions on track (Schwalbe, 2006). Moreover, the Project Manager tried to account for the lack of a common culture (i.e., not all team members were as technically proficient), unclear expectations, and the lack of motivation (Lewis, 2007).

Environmental

Potential concerns stemming from environmental factors included the ability to launch the product in a live environment. Each factor or element that would come in contact with this product was considered. Protection against unforeseen environmental problems was accomplished through adequate system backups and an effective recovery plan. Systems testing related to performance was conducted in a simulated live environment. The Project Manager led this effort, with assistance from the development team, the Quality Assurance Manager and the project’s Client Advocate. As advertised, the system runs on commonly accepted hardware and software and it requires minimal technical support. It is easily accessible by the sponsor and is secure from unauthorized users.

System Metrics

System metrics are reference points that are used to determine system performance. System metrics are particularly beneficial for system-of-systems engineering constructs, when emergent behaviors are expected to manifest but are unknown at the time of design (Hu, 2007). This project was not sufficiently complicated to warrant the use of systems metrics. SchoolTicketsOnline.com was scoped entirely around achieving certain interface designs and desired functionality. Performance measures and demands were transferred to a third-party web hosting provider and a third-party payment gateway. Performance claims are assumed to be true or at least within a reasonable range. HostGator.com, the web-hosting provider, for example, claims to have 99.9% uptime. They also claim to have unlimited bandwidth and unlimited disk space for the selected price point (2011). PayPal, the third-party payment gateway, claims to be the leading global online payment company, with more than 94 million active registered accounts, and is available in 190 markets (2011). Adequate performance can be inferred and predicted.

DATA FLOW DIAGRAMS

The premise of the Ticket Purchaser Data Flow Diagram (DFD), Figure 2, centers on SchoolTicketsOnline.com’s utilization of PayPal as the purchasing interface to execute monetary exchanges. The customer is an entity with two inputs and three possible outputs. First, the customer creates an order by accessing the website. He or she then searches the website for the desired school, then the event that corresponds with the selected school. Once an event is chosen, an event order can be created. By viewing the orders the customer has completed, the website gives the customer the power to view an interface at a level corresponding to their own sense of understanding. In other words, the customer will be involved with the website in a way that appeals to their sense of style and their way of doing business. The website allows a customer to interact with the event purchasing process in a manner that is considerate of the customer’s concerns pertaining to a ticket/event purchase.

Once a customer has created an event order through the website, the transaction is securely generated through PayPal, which is the chosen third-party payment gateway. The customer knows the order is complete when a confirmation of acceptance is returned. A customer can subsequently view his or her order. At the same time, ticket information has been sent to the ticket database. PayPal then sends information to the event database. Finally, the tickets are created and sent to the customer. This can be accomplished by one of two methods: the tickets can be picked up at the respective school’s ticket window or the customer can print the tickets when and where he or she chooses.

The entity for this DFD is the customer. It is the only entity, and it has a priority level of A. In short, the customer is an essential part of the system operation. The pre-condition for this DFD is a created event. The post-condition is met when a customer has acquired a ticket to a specified event. Triggers do not exist for this project. In sum, the actors for this DFD are the customer (ticket purchaser), ticket database, PayPal, and tickets. There were no consequential deviations, modifications or omissions from the set of diagrams presented at the project’s first milestone.

Figure 2: Ticket Purchaser Data Flow Diagram

The Event Coordinator DFD, Figure 3, can view and manage orders as well as events. This DFD is very similar to the ticket purchaser DFD, previously described. Both manage orders and have their own backend database. Unlike the ticket database, the event database has information pertaining to events. This information must be kept separate from the ticket database. They are different entities. The event database will hold data such as number of tickets sold and number of tickets available for a specified event. Event information such as date, time, performance, and location are necessary and must also be housed.

The event database is where this information will be kept, and the School Event Coordinator is the person responsible for maintaining this information. The Event Coordinator entity will have a priority of A since it is essential to the website. The pre-condition for the Event Coordinator DFD is an event. The post-condition is met when said event has been established with the website. Triggers do not exist for this project. In sum, the actors for this DFD are Event Coordinators and the event database. There were no consequential deviations, modifications or omissions from the set of diagrams presented at the project’s first milestone.

Figure 3: Event Coordinator Data Flow Diagram

The Site Administrator, Figure 4, will be the coordinator for the schools that wish to become a member of the program’s database, enabling schools to engage in the ticket/event website. The Site Administrator can update schools (e.g., add and drop) as well as view reports concerning the school event scheduling, statistics, etc. This database will have all information pertaining to each individual school.

The Site Administrator entity will have a priority of A, as it is essential to the website. The pre-condition for this DFD is a school that wishes to add and/or drop membership with the site. The post-condition is met when a school has been added or dropped as a member. Triggers do not exist. In sum, the actors for this DFD are the Site Administrator and the database. There were no consequential deviations, modifications or omissions from the set of diagrams presented at the project’s first milestone.

Figure 4: Site Administrator Coordinator Data Flow Diagram

SYSTEM INTERFACES AND DESIGN

The dominating force the Internet has had on transforming ways organizations gather and disseminate information is unquestionable. This is true for all types and sizes of business, academia, and government. Social scientists have already started studying how the Web is altering human-to-human interaction (Turban et al., 2008). This emerging field is examining the implications of the Web on social fabrics, intercultural communication, and even anthropology. The subsequent ubiquity of computing devices and easy access to networks demands a fresh look at how end users will interact with these devices and ultimately each other.

Website design is of particular importance to this issue. As a whole, websites have become cluttered, laden with dense graphics, and void of focus and meaningful content. It is imperative that designs not only target a website’s core users; they should do so in a clean and readable manner without unneeded animation, extraneous information, or other distractions. Given the competition for finite time, intellect, varying levels of skill and experience, and multivariate expectations of millions of potential users, website designers should use as many crutches as possible to help website visitors accomplish their tasks (Clifford, 2010).

The web interface design for SchoolTicketsOnline.com included the creation of a brand logo; selection of uncomplicated, template-driven backgrounds; commonly used fonts (that also display well on mobile interfaces); and the usage of design principles such as Gestalt’s concepts of proximity and surroundedness (Heim, 2008). In short, the design centered on creating simple interface elements to ensure timely delivery. The interface design for SchoolTicketsOnline.com ultimately follows three basic design considerations – visualization, efficiency, and functionality (Beaird, 2010). Through these elements, SchoolTicketsOnline.com is comparatively easy to search for schools and events, as well as to purchase, track, and retrieve tickets.

Visualization

A screen layout with minimal images, icons, and text objects makes SchoolTicketsOnline.com attractive and simple to navigate. To this end, one important concept that was incorporated is mapping (Beaird, 2010). Mapping can increase the usability of an interface by making visual connections between two or more things. It can also be extended to many of the Gestalt design principles, two of which are called “proximity” and “similarity.” These principles assert that objects that are close together and that have similar visual characteristics will seem related and therefore automatically be visually grouped together (Heim, 2008). Figure 5 illustrates this concept.

The project’s sponsor requested that a user be able to search for a school and event by three different search criteria. This was accomplished through the consistent use of drop-down menus and text boxes for input, all of which are found in a column on the right side of the Home Page. The grouping of three different search criteria allows for a more intuitive search experience.

Figure 5: Home Page

Another principle used to design SchoolTicketsOnline.com’s Home Page is the Gestalt surroundedness (sic) principle, which states that an area that is surrounded will be seen as the figure and the surrounding area will be seen as the ground (Heim, 2008). This principle is used to direct the user to see related groupings. Many of the Gestalt principles can be used to steer designs away from unintended visual distractions resulting from haphazard layouts. Simplicity relies on the use of heuristic evaluation, particularly with respect to grouping (Heim, 2008). In addition to placing on the Home Page only what was absolutely needed, the design also utilized white space to create meaningful groups of information that describe what SchoolTicketsOnline.com is and, more importantly, how to use it.

Efficiency

The Home Page was designed to be simple for students of most ages and parents with varying computer literacy. Similar sites are cluttered with far less relevant event calendars, news, and links to other websites. These are less relevant because it is assumed that, save for School Event Coordinators and the Site Administrator, users who access the main page are more likely to be first-time or at least infrequent visitors. Simplicity not only enables easier and quicker understanding of core information and how it is accessed, it presents a better marketing tool if the target audience is deliberately narrow. Anything added to the Home Page that does not have a scoped purpose may cause the end user unnecessary delays. It may have not been a design consideration.

Figure 6: School Control Panel

By narrowing the gap between what the user wants to do and the action needed to complete the task, the interface becomes more efficient. Steven Heim defines this “gulf” as the inefficiency that results from the gap between what an end user believes to be true (based on perception and experience) and the actual physical components afforded to meet this perceived reality (2008). One of the main tenets of an efficient design is simplicity. A cluttered website, however, may be viewed by some as overly complicated because of the possibility of delayed response times, while others may see a robust site as easier to navigate. There are arguably fewer instances of menu-driven navigation required. When viewing Figure 6, one can see a design driven by direct uses of pans and frames. They provide a visual grouping of related functionality that is not confusing or annoying for users.

Functionality

The main features of SchoolTicketsOnline.com were centered on a minimally evasive ability to locate a school event and purchase tickets. The tools used were a combination of drop-down menus and text entry fields. Menus are the lifeblood of Windows-based operating systems. They are helpful for the experienced user and essential for the novice end user. Without menus, finding a desired location or function can be extremely difficult. Experienced and novice users alike would depend on reference guides that are consistent with command-line interfaces. This would especially hold true if a Windows environment lacked appreciable GUI controls (e.g., list boxes, buttons, and the ability to scroll). Moreover, the menu structure must adhere to the principle of progressive disclosure (Beaird, 2010). Appropriate grouping, coupled with progressive disclosure and simplicity, makes the need for memorization less important.

Another aspect of functionality is predictability. While the design team showed great interest in keeping the interface simple, studies have shown that overly simple screens can actually become less useful, especially if the drive for simplicity leads to providing less functionality (Heim, 2008). The selection of design templates that ultimately served as SchoolTicketsOnline.com’s final look ensured that needed functionality stayed consistently available. Figures 7, 8, and 9 illustrate template-driven consistency among three different places within the site: adding an event, adding a ticket, and configuring an account.

Figure 7: Adding an Event

Figure 8: Adding a Ticket

Figure 9: Configuring an Account

Database

In order to determine the requirements of a database entry interface, an analyst may need to examine the processes, functions, objects, and people that are involved (Heim, 2008). A database entry interface should be as efficient and simple as possible, even at the risk of suffering usability (Clifford, 2010). A database query is not as complicated as an order tracking task (which requires additional information) or an inventory control (which may require multiple information systems and knowledge thereof). While the backend database management system and databases may be complicated in both its design and administration, the entry interface does not need to be and should cater to nearly any cognitive ability. In other words, the most important elements of this type of interface should be plainly visible, simple to use, and, most importantly, ensure errors are prevented (Whitman & Mattord, 2009).

When we look at making purchases via the Web, for example, the design of an order-tracking interface should also account for the need to be consistent with other retailers. This design principle would follow one of Jakob Nielson’s ten heuristics for interface design – consistency and standards (Heim, 2008). While it may be nice to tailor an order-tracking interface to customer behavior, not accounting for the need to be flexible (i.e., cater to both inexperienced and experienced online shoppers) may pose unintended challenges and frustrate some users. There may be more value in adopting physical designs that are easily recognizable, memorable, and consistent with other retailers in grouping, screen location, and use of text boxes and drop-down menus for order tracking (Beaird, 2010).

Prototype

The least expensive method to demonstrate that a product is working as designed is by building a prototype (Dennis et al., 2005). A prototype provides an opportunity to gather feedback and save cost in production. The prototype of SchoolTicketsOnline.com utilized a web browser as a human-computer interface. By using web browser technology, a user is able to access the website from almost any computer platform, including Linux, UNIX, and Windows. Save for, perhaps, a plug-in, no additional application is required. To demonstrate the public-facing, end user interface as well as the interface for the School Event Coordinator, the following functions were chosen to be in the prototype:

End User:

· Search function for school by state/city/zip code/school ID and event

· Pick and purchase event tickets

· Link to PayPal for payment of event tickets

School Event Coordinator:

· Management area for schools to manage events and tickets

Sponsor Feedback

During Milestone Two, the sponsor was given a copy of the project team’s first milestone report, which included a brief overview of progress made to date. He was also shown a working prototype of the website section for ticket purchasers and School Event Coordinators. The sponsor was impressed with the progress and specifically called out the Home Page for its ability to support searching for schools by three different methods. During the review, the sponsor asked how the School Event Coordinators would be able to verify that only one copy of a ticket was used to enter an event.

During the discussion, it was brought up that the initial plan was to have a printout of all of the tickets sold for a specific event. This printout would be used as a checklist when ticket purchasers arrived at the event. The specific ticket would be matched to the list and checked off the list. No additional entries to the event would be allowed by anyone with a copy of that same ticket. The specific deliverable in this case was to allow School Event Coordinators to print off a list of tickets that were generated. This additional requirement was addressed later in Milestone Three. Management of the ticket list after being printed is outside the scope of this project.

The website prototype was also shown to a School Event Coordinator that could potentially be an end user and advocate of the service. The user showed a generally positive attitude toward using the existing features of the website and was easily able to understand how to find their school. Comments were made about some of the color choices and the font size on the event page. The user liked the flow and the simplicity of the site.

The information provided by the site owner (project sponsor) and the potential School Event Coordinator was a positive indication that the prototype was headed in the right direction to allow for ease of use in the performance of its intended duties. However, there was still more work to be completed in the design of the interface related to the overall look of the website.

Below are the web pages used as the prototype for the project:

Main Web Page:

Provides the ability to search for schools by State/City, by Zip Code and by School ID.

http://www.SchoolTicketsOnline.com/index.php

Data entered into the test database include the following:

For "Search by City/State"

State = Alabama

City = Phoenix

School = Camarillo Cavaliers

For "Search by Zip Code"

Zip Code = 91234

For "Search by School Code"

School Code = 1234-5678

School = Reseda High School

Event Pages/Ticket Purchasing Pages: Any of the above searches take the ticket purchaser to the "Select Your Event" page. Selecting an event launches the actual event page, where the ticket purchaser can enter the number of tickets to purchase for each event date and ticket type. Submitting the ticket form launches the "Purchase Your Tickets" page and adds tickets to the shopping cart, where they can be removed or finally purchased.

Event Coordinator Pages: These pages allow the Event Coordinator (School) to log into the system and manage their events (add, modify, delete) as well as generate reports.

http://SchoolTicketsOnline.com/index.php/school/login

Email = [email protected]

Password = tickets

Once the School Event Coordinator logs in, the list of existing events is shown in a table layout. These events can be deleted or modified and reports can be generated. New events can also be added.

CLASS DIAGRAMS AND DATABASE DESIGN

The database development for the project proceeded quickly and was carefully managed due to time constraints inherent to the structure of this Capstone. Since the first release of the class diagram, only one modification was made to accommodate the requirements of the application. At the time of delivery, the database was designed to run on a MySQL 5 server. The configuration of the database for this project did not include the use of foreign key constraints within the database. All business logic constraints, including foreign key constraints, were managed programmatically in the source code. Both unit testing and system integration testing insured that proper constraints were maintained. See Appendix G: Test Results and Appendix H: Data Dictionary for further detail. The class diagram for the project is depicted in Figure 10.

Figure 10: Class Diagram

QUALITY ASSURANCE

System Testing

Earlier assessments concluded that the project team might have to produce a product with lesser quality because not all team members reached their full potential. Despite the resultant setbacks, extensive system testing and documentation, which was led by Christian Larsen, enabled the delivery of a high quality system that met all user requirements as specified by the stakeholders.

Additionally, system testing focused on optimizing the performance and design of SchoolTicketsOnline.com in order to gain sponsor acceptance of the completed system and confirm that all expectations were met. A description of the testing methodology used is outlined in the system Test Plan, which can be found in Appendix F. In addition, each test case outlined the test inputs, the conditions under which the test was conducted, and the expected outcome (Kaner, 2003).

The Test Plan, as executed, covered the following:

· Description, goal, and focus of each test

· System components and features tested

· Description of testing approach

· Entry and exit criteria

· Environmental considerations

· Testing schedule

· Format of test cases

· Defect reporting and tracking procedures

· Estimated time required to perform system testing

Defect Tracking

All defects identified during the technical review and during each phase of testing were entered in a Defect Log, which can be found in Appendix G: Test Results. This log was used to document a description of each defect, the discovery date, corrective actions taken, and the final status. After corrective measures were completed, re-testing was conducted, and the results were recorded in the Defect Log as well. Once the applicable re-test was passed, the defect status was listed as “RESOLVED” and no further action was required for that particular defect. This tracking method was used for each defect identified within the system. The Quality Assurance Manager maintained the Defect Log, with necessary updates performed by the Principal Developer. The final status of the documented defects is also included in the Defect Report.

Technical Reviews

The primary technical review of this system focused on code and design. The project team conducted it in a group setting during Milestone Three. The use of a detailed checklist enabled a thorough review with focus on every aspect of system design and coding (Microsoft, Inc., 2011). The Code and Design Review was the first formal, documented analysis of the system database structure and website design. The review was given structure by a checklist of predefined items, which was a modified version of that provided by Felke-Morris (2010). The reviewers discussed the potential defects they identified and submitted comments or questions based on their assessment.

The technical review proved to be very valuable in isolating and correcting flaws early in the system development, resulting in fewer required modifications throughout the system’s development and final delivery of a high quality system. Early identification of design flaws also reduced the amount of re-testing required later in system development and contributed to the enhanced maintainability and overall quality of the final product (Greenspun & Grumet, 2009). A full report of this review was made available to the sponsor. (See Appendix G, Section 1: Technical Review Results.)

Change Control

Proper change control methods were essential in maintaining accuracy of system documentation. Much of the documentation contained diagrams, tables, and written text that was extremely dynamic in nature. The project team utilized Google docs to achieve precise version control for certain project documents. Google docs is a free, web-based data storage service. Formal project reports were managed by the Project Manager and updated at the conclusion of each milestone. Near the conclusion of each milestone, each project team member was accountable for submitting the current version of all applicable documentation relating to his area of responsibility. After the Project Manager finalized each milestone report, the current version of each section of the report was included in the finalized milestone report. Change control for documents that were edited exclusively by one member of the project team remained the sole responsibility of that team member.

The development team was responsible for management of source code change control. The Principal Developer maintained control of the current version of source code, while other members of the development team utilized shadow copies while working on user interface design and performing other modifications. Once a change was made, the Principal Developer was required to approve the change before it was incorporated into the system source code.

SECTION THREE: PROJECT CLOSEOUT

IMPLEMENTATION

History

During Milestone One, all functional and non-functional requirements were identified from early formal interviews with the sponsor and informal interviews with specified user groups. Each requirement was either expressly stated by the sponsor or derived by the project team as the project progressed. Other requirements were added or modified by the team on behalf of the stakeholders. (Very few requirements evolved into a function or feature that was not initially identified.) The project’s web and database development team, led by George Hubert, completed the first draft prototype for demonstration to the sponsor. Development work involved extensive database design and cursory web interface design choices via pre-existing templates to demonstrate functionality.

During Milestone Two, the client reviewed the project team’s agreement and was initially satisfied, albeit certain portions regarding report generation were found to be too ambiguous. (See Appendix B: Client Agreement for further detail.) The sponsor also determined that the School Event Coordinators needed the capability to print a list of tickets to be used as a checklist at the event. The client eventually provided specifications on the types of reports and agreed that there would be no more than two reports for the School Event Coordinators. Since feedback during this milestone led to only minor adjustments, work plan estimates remained accurate and the feasibility did not change. The project size also continued to be in line with provided timelines, to include an absolute inability to miss the specified delivery date.

One area of constant concern with regard to time and quality was ensuring that all database linkages functioned correctly. A data model was developed to handle the flow of data in and out of the database. To mitigate these concerns through design, the web interface utilized PHP as a scripting language to interface with the MySQL database as well as display the data back into the web interface. For example, as designed, every search for school by state, city, zip code or school code is a called by a PHP script that processes each request and calls the database to retrieve the data and display it back to the web interface. Since the project development team was very familiar with technologies like PHP, the risk was mitigated.

During Milestone Three, the project team benefited from an internal reassessment of all project features, to include all explicit functional and non-functional requirements. The team also came to an agreement on derived and implied tasking and expectations. Assumptions were challenged and clarifications were made. Portions of the project’s requirements, from which success can be quantifiably measured, can be found in the “A Solution,” “Non-Functional Requirements,” and “Sponsor Feedback” sections of this project report. When deciding on test methodologies and writing testing cases, however, the need to compile all requirements in one comprehensive and easily referenced list became apparent.

At the conclusion of Milestones Three and Four, the project team anticipated delivering every identified requirement, though high quality could not be guaranteed at the time. While there were no deviations from the project’s vision, feasibility, project plan, or work plan estimates, the project did not benefit from the full participation and/or work quality of all of its members. Initial skill assessment and subsequent division of labor based on skills and experiences did not materialize as hoped. The biggest impact to projected implementation was the website’s human-computer interface design. Though the project team desired a tailored design, it was instead forced to use existing templates (with minor modifications) as part of final delivery. Though it was identified very early that interface design was not a priority, the reliance on templates, while sufficient for the project sponsor, did not adequately demonstrate early design goals.

Secondly, during Milestone Three, group dynamics and the project scheduled suffered from slow development of system level test cases. The Project Manager, with the help of the Quality Assurance Manager, decided to rebalance and reallocate resources so system level testing could catch up and stay on schedule. With the test team at less than full strength, the benefit of an exhaustive analysis of testing requirements and results became less likely. The presence of minor errors upon delivery, therefore, remained probable through Milestone Four. System errors were identified as this project’s biggest risk during Milestone One, albeit no specific reasons were identified. (See “Risk Analysis,” p.17.)

Status at Delivery

At time of delivery, SchoolTicketsOnline.com was designed to run on commonly accepted hardware and software and require minimal technical support. HostGator.com claims to have unlimited bandwidth and disk space. It also offers increased functionality via a wide range of scripting languages, databases, templates, pictures, software tools, and fonts. The project developers used MySQL, CodeIgniter, and JQuery for scalability. HostGator.com also offers easy web administration, including traffic reports and manual backups of both the website and database.

SchoolTicketsOnline.com was designed with HTML, PHP, MySQL, and CSS. These technologies are industry standards and are supported across multiple platforms by numerous vendors. The application supports different web browsers, including Microsoft’s Internet Explorer, the most commonly found browser in terms of market share and two of the most popular browsers in terms of the number of download according to cnet.com: Mozilla Firefox and Google Chrome. The scripting languages used will not require an administrator to compile the code, which makes for simple integration. AJAX works with HTML and CSS code, using JavaScript to display information accessed directly from the database.

In sum, all requirements were met. Neither the incorporation of “free” tickets through the site (where there is no checkout process) nor the ability to offer additional items for sale with each purchase (e.g., programs, flowers, and items with a school logo) were delivered. Both were “nice to haves” and should be included in a follow-on release. The project team also did not design or deliver Site Administrator reports as indicated in the “Data Flow Diagrams” section of this report. These were not fully defined by the sponsor, so the requirements were adjusted to reflect. Both the sponsor and the team believe the use of third-parties such as Google Analytics will suffice. The results from the Usability Test also list five recommendations made by end users, one of which was included in the final delivery.

Working with Third-Party Service Providers

To grow SchoolTicketsOnline.com, risk management and security planning should, first and foremost, be handled as a managerial problem before considering which technologies are best suited. Technology selection and implementation should never usurp objectives or present unintended dangers to trusted information, even if these technologies are remotely administered by otherwise “trusted” third-party service providers. As many types of organizations and initiatives decide to utilize third-party services to manage software, platforms, or even the entire enterprise via web services (i.e., offload business operations to a third-party over the Internet), the risk associated by computing in the “cloud” has considerations yet to be fully vetted or perhaps understood.

When SchoolTicketsOnline.com selected its third-party web hosting provider and third-party payment gateway, it voluntarily transferred control of sensitive transactional data and, in a sense, control of the website itself. SchoolTicketsOnline.com will be at the mercy of disparities in the quality of service due to usage spikes, outages, and service attacks as an indirect consequence. Though SchoolTicketsOnline.com may be able to theoretically tolerate compromise of its information or losses to its availability, either instance could have irreversible effects on reputation to an otherwise promising service if it is not addressed before it happens.

If no consideration is given, vulnerabilities such as quality of Service Level Agreements (SLA), regulation, and enforcement; network configuration errors; poor network monitoring; and the inherent technical vulnerabilities of the Internet (e.g., TCP/IP protocol stack), will become magnified (Whitman & Mattord, 2009).

In a recent Verizon Business report detailing data breach investigations, Verizon showed that current compromises to globally connected data and information are the result of malware, hacking, misuse, deceit, and physical thefts (Verizon, 2009). The Verizon report further states that while key loggers, spyware, backdoor exploits, SQL injections, abuse of system privileges, and unauthorized access via default credentials were the biggest percentage of breaches, packet sniffers, key loggers, spyware, backdoor exploits, and SQL injections continue to have the broadest reach to all records (2009).

As SchoolTicketsOnline.com embraces new web technologies, security mechanisms, ubiquitous computing platforms, and popular service models, it must eventually engage in some form of risk and security management. It does not have to be formal. The National Institute of Standards and Technology (NIST) offers a sufficient framework, although it is not necessarily reflective of new models of conducting business on and by the Internet, web services, and third-party service providers (2002).

The transfer of information technology and daily business operation to third-party providers, while necessary to effectively and, in some cases, legally operate, has advantages and disadvantages. Given the diversity and likelihood of cyber-based threats and the fact that security models are just now being written and tested to combat the large scale of cascading attacks, an organization should, through qualitative analysis, conclude that the risks inherent to cloud computing should be enough to at least sway the organization from putting intellectual property or competitive sensitive data on any server save the ones it directly controls.

Though asset identification, valuation, and prioritization are still a critically important part of the risk and security management process, threat identification, likelihood, and vulnerability identification will become exponentially more complex if an up-start initiative like SchoolTicketsOnline.com chooses to not take promises of security at face value. Risk assessments must go beyond SLAs. Moreover, risk control strategies must not only ensure the use of benchmarks and best practices as a matter of due diligence, but so too must the third-party service providers (Bayuk, 2009).

Despite the vast potential of cloud computing, particularly by the public schools that either want to keep operating budgets trim or do not wish to be side-tracked from their core competencies, there are concerns relating to the loss of control, security, integrity, privacy, and availability. As SchoolTicketsOnline.com engages in risk and security management processes on behalf of its customers, it must understand that security models and standards are still emerging, and best practices still have a significant role to play.

DEFECT REPORT

In accordance with previously outlined defect reporting procedures, each defect discovered during system testing was reported and tracked through resolution by way of the Defect Log. The system testers identified 21 defects by means of predefined unit and system level testing activities. The defects identified include spelling and grammar errors, minor web browser compatibility issues, and other errors relating directly to the functionality of system features. A full record of each defect is found in the Defect Log. Each defect was reported to the development team and was successfully resolved. To the best knowledge of the project team, no unresolved defects were present at system delivery.

Due to the comprehensive nature of the system testing performed, the probability of remaining undiscovered defects within the system has been determined to be very low. The functionality of each system feature was meticulously examined during various test activities focusing on the individual components, as well as the interoperability of such components. The comprehensive set of test results was made available to the project sponsor during project closeout. See Appendix G: Test Results for further detail.

FINAL USABILITY REPORT

The assessment of the overall usability of SchoolTicketsOnline.com is based on the analysis of the usability test results, which can be found in Appendix G, Section 3. The usability testing was completed by a group of 16 potential end users. Each potential end user was asked to perform several common tasks on the finalized website and to then complete a survey designed to gauge user experience.

The goal of this testing was to engage a sufficient number of potential end users of varying backgrounds and skill levels to determine the level of ease of navigation and the overall effectiveness of the user interface design. Experts recommend the use of at least ten participants for such an experiment, as too few contributors would lead to inaccurate results and more than this number of participants tends to become too expensive for most organizations (Dennis et al., 2009). Given the parameters of this project, a test group of 16 individuals was determined to be sufficient. The testing was conducted in one-person sessions, each tester interfacing directly with the website. The instructions for each task to be performed were given with minimal detail to encourage the participants to use their own method of choice to complete each task.

The overall usability of the completed website, as determined by the analysis of the Usability Test results, was measured at a very high level. Each of the 16 participants reported that locating a specified school, the first step in the ticket purchasing process, was easy and clear to complete. Additionally, 87% of this group reported the subsequent steps in the ticket purchasing process, locating the specified event and adding the correct tickets to the shopping cart, were also easy and clear to perform. Regarding overall site navigation, 10 of 16 group members expressly commented that the site was clear and easy to navigate: 81% rated overall site navigation as either “easy” or “very easy.”

In addition to the comments relating to the level of ease and clarity, much constructive feedback was also gained regarding areas of the site that could be modified to enhance the ease of use. The project team reviewed the feedback: It was concluded that certain changes would be implemented prior to system delivery, while other, more extensive changes would be provided to the project sponsor as recommendations for future implementation. A total of five recommended changes were identified, one of which was made prior to delivery, and four of which have been recommended for future implementation.

Nearly every member of the group surveyed reported that locating contact information for the Site Administrator was unclear and difficult. Suggestions were made by many members of the test group to add a “Contact Us” link in the page footer. This link was added and takes the user to a web page that provides an email address for the Site Administrator.

In addition to making the comprehensive usability test results available to the project sponsor, the following website modifications are recommended for future implementation, focusing primarily on those changes that would have the greatest impact on overall site usability:

· Move the “Find Your School” section of the Home Page to the far left side and the “School log in” to the right side. Based on the end user survey, these modifications will add clarity on where to purchase tickets once they initially enter the website. Alternatively, the “School log in” field could be moved to the top right of the page header, allowing more space on the Home Page to be devoted to the end user.

· In order to make events easier to locate, add an additional column for the event title or display the event title in bold text to prevent it from appearing to be part of the event description.

· Add a space between each event to make them easier to identify.

· Add global site navigation links to the page footer of the school event management interface (logged in as School Event Coordinator view).

LESSONS LEARNED

PROJECT MANAGEMENT

Organizational Effectiveness

Project oversight and organization structure

The project's first order of the day was concerned with scope. There was great effort made in the first two weeks to evaluate what could and what should not be handled. There was consideration of another project, but it was dropped because of problems pertaining to intellectual property rights that had developed early. There was a temptation to pick a project quickly and run with it. The Project Manager was, however, steadfast and made sure not to select a project too quickly, which could have led to problems later on.

All project goals had been met until Milestone Three witnessed some work productivity and scheduling lapses. First, instead of creating a tailored human-computer interface, it was decided to use a template design when it became apparent that not all team members would or could contribute equally to the project. Second, a slip in system level test cases delivery was reallocated and resources were rebalanced so that system level integration testing could stay on schedule. These decisions, whether right or wrong, kept the project on schedule. The project team did not benefit from a similar project to view in order to derive scope at a more precise level.

As project selection was at hand, the project team decided to go with SchoolTicketsOnline.com since its scope value seemed the most attainable. It was also a good idea. The team understood that despite careful planning and attention to performance, scope creep does occur and corrective action can keep the project on schedule. This project was a three-month long tour, and it was quite involved. Selecting the project early was a key factor, while still considering scope as an issue.

Rearranging the project schedule to reflect a more realistic outcome may have diverted some consideration from the scope slip. A dynamic approach to scope design from the very beginning may have been more ideal. Taking early pitfalls into consideration, every project must adjust and allow time to recover. Instead it was decided to approach the project from a more "static" point of view, which is common for new upstarts. This is not to say that one method is better than the other, but experience cannot be bought. Despite the diverse technical backgrounds, a few team members still had much to learn. This should be expected.

Communication with stakeholders

Overall, the interviews accomplished the goals of the project team. They provided the group the information necessary to start and, more importantly, finish the project. The requirements and work plan estimates were derived from the information gathered during early interviews. Although communication with the stakeholder was ultimately sufficient for project success, all projects can benefit from more time with their stakeholders.

Defining roles and responsibilities

Roles for the project team fell into place almost immediately. Once qualifications were identified, assignment of responsibilities also became easy. Eric Clifford assumed the position of Project Manager and swiftly assigned duties. This was not only a quick process, but also an unusual phenomenon. Due to the nature of this project and the inexperience of "working as a group," the team was fortunate to be in this position early. The qualifications of the team's members are quite extensive and the Project Manager was able to recognize and delegate responsibilities accordingly.

Though all team members were in agreement, it came too early for some members, in part due to the team’s desire to get started with the project. The team found a good niche and was willing to "go" with it. This was because of the natural tendency of being eager. The roles each member assumed worked well up to a point. More definition on each individual’s assumed role early on would have been prudent. It is easy to criticize now and was hard to define then.

Team Building and consensus building techniques

Team building is not an individual sport. A few team members grappled at times, because they did not know each other previously. It was hoped that the extensive individual experience of our group members would overcome the discrepancies associated with being unfamiliar – and it did. The team agreed on the complex issues because of experiences each member had. This might have been an oversight. Perhaps more time getting to know each other at a professional level would have been beneficial to the project’s cause. This type of interaction, given the tools at our disposal, was not possible, however. A more structured team building approach to consensus building techniques in order to improve project quality and member involvement would have been optimal.

Project Initiation

Defining and communicating the goals of the project

Definitions of goals, which also can be stated as project requirements, had been well stated since Milestone One. They were clearly posted and well numbered. This has been true throughout the project. Goals are the key to success. Without a set of goals, an individual, group, or project cannot grow and be successful. A project must have milestones to cite progress and give the project direction. This project was a very involved endeavor. Each milestone had a great deal of information. A few informal, less weighted milestones could have helped. Shorter milestones could have given perspective on the tasks at hand and given the group something to discuss. Perhaps this would have also helped with the tendency to make and act on assumptions.

Time and cost estimates

Estimates for the time distribution and execution were handled by the Project Manager and were agreed upon by the group in the name of establishing a work foundation so that the group could move forward from a starting point. The format used to document the project team’s progress was a simple two-dimensional graph listing task due dates. Task redistribution occurred rapidly when projects were not meeting scheduled deadlines. Though team members disagreed on the value of this reasoning, it was the group’s consensus that the action taken was necessary and just.

Expediting the initiation process

The project team spent the first two weeks talking exclusively about scope. The team was not too hasty in starting the project. The team could have benefited from an additional week of discussing scope and creating a schedule that was more dynamic in nature and reflective of a more real perspective of the project at hand. Other team members disagreed and believed the manner in which the project ran was quite acceptable.

Project Planning

Identifying and obtaining resources needed

The project’s biggest vendor decision was selecting its web-hosting provider, HostGator.com, which was established in 2002. They offered a 99.9% uptime guarantee and claimed to have unlimited bandwidth and unlimited disk space for the selected price point. HostGator.com has grown from a small hosting company to a world leading hosting provider. The computer technology game seems to have these Cinderella stories. Upstarts such as Twitter, Facebook, Google and even Microsoft all have humble beginnings. To gain some knowledge on how these companies become successful is a lesson learned in itself.

Project plan development

The project plan was devised to focus on quality. How one measures quality is a subjective issue. Substance over quantity has been this group's mantra and it paid off. Despite differences in approach on how to achieve the ultimate goal, setting timelines, and meeting deadlines, the project finished on time and will likely be a success. The project team has learned that despite differences, teams can grow, and because of that they become stronger and better people.

Stakeholder involvement

The involvement of the stakeholder in this project was minimal. More interaction between group members and the stakeholder would have been beneficial. More communication would have given both the stakeholder and the team a greater vision of project goals. In turn, productivity may have improved due to being motivated by having greater vision.

Execution/Control

Quality Assurance

The Quality Assurance element of the project proved to be of great importance in guaranteeing the delivery of a high-quality system that met the expectations of the project sponsor. Initially, many of these functions, such as system testing, were assigned exclusively to the Quality Assurance Team. However, as the project progressed, each member of the team was able to become involved and added valuable insight to the analysis performed on the system, as well as the resulting system modifications made. Adequate focus was provided to such activities, each being carried out in a thorough and well-documented manner.

Schedule and cost control

Cost control was a small, if not, an inconsequential issue. From the beginning, it was understood that the deliverable was to be a free interface. This made the cost issue a matter of fulfilling our obligations. This is where scheduling came in. Execution of the schedule was done very much by the book. There was no room for error. Without scope creep, following the schedule as expected was possible.

SYSTEMS DEVELOPMENT

System Analysis and Requirements Development

Requirements and user needs

The job of a system requirements document is to generate all necessary requirements for software development. This is typically accomplished by having clear communication between a customer (stakeholder) and the project team. SchoolTicketsOnline.com’s requirements document is reflective of this definition. This was also an influential starting point for the project. It was done well enough for the project to effectively start. Attention to detail at the requirements gathering stage can save headaches later in the development process.

Prototyping

The prototype of SchoolTicketsOnline.com utilized a web browser as a human-computer interface. By using web browser technology, the user was able to access the website from almost any platform, such as Linux, UNIX, and Windows. A good way to see how a project’s functions are progressing with comparatively little financial cost is to build a prototype. This way the information yielded can give insight and confidence that what a project is doing is correct and not heading off on a tangent.

Acceptance Process

For the sake of getting started early there was an immediate need to select a project. With scope in mind, many of the proposed projects were dropped quickly. The project team was pressed to either agree and select the project or drop it from consideration. The selection process resulted in tough decisions, because this project presented itself well. Once the team agreed on what the project would be, it quickly moved on. However, some members did not keep up with the speed of the group. The acceptance process is a group process and could have been more carefully handled.

Development/Implementation

Implementation strategies

Through Milestone Two, all planning went according to schedule. Milestone Three saw some changes. It was necessary to take corrective action in order to keep on schedule. Individual duties had to be reassigned. This decision was made by the Project Manager and approved by the group majority. The decision to do this was justified in the name of adhering strictly to what the schedule dictated. Staying on course was of paramount importance.

Testing approaches, plans, and checklists

Testing was well-planned and provided thorough assessments of the system at various stages of its development. The first formal technical review of the system’s code and design was conducted during Milestone Three. Further testing was divided into unit level, system level, and user acceptance. System level testing was further broken down into system integration, browser compatibility, and usability testing.

Additional time for testing would have been beneficial. The system level testing (usability testing in particular) had to be performed on the system once it was complete. It was therefore scheduled near the end of the project. Although all system testing was successfully completed according to schedule, an additional eight to ten days between the website’s completion and the project delivery would have been ideal. This additional time would have accommodated more comprehensive usability testing on the finalized system, allowing sufficient time to make the recommended changes and conduct a second round of usability testing prior to delivery.

References

Bandara, W. et al. (2005). Factors and measures of business process modeling: model building through a multiple case study. European Journal of Information Systems. Vol. 14, pp. 347–360.

Bayuk, J. (2009). Vendor Due Diligence. ISACA Journal for IT Governance. Vol. 5, pp. 34 – 38.

Beaird, J. (2010). The Principle of Beautiful Web Design (2nd ed.). Canada: SitePoint Pty. Ltd.

Clasen, D. and Brown, B. (1995). The Multidimensionality of Peer Pressure in Adolescence. Behavioral Science Journal of Youth and Adolescence, Volume 14, Number 6, pp. 451-468.

Clifford, E. (2010). CIS 606: End User Information Systems. Week 2 Assignment. National University, 23 January 2010.

CNET.com. (2011). Most popular in Browsers. Retrieved March 4, 2011 from the World Wide Web: http://download.cnet.com/windows/browsers/most-popular/3101-2137_4-0-1.html

Dennis, A., Tegarden, D., and Wixom, B. (2009). System Analysis and Design with UML Version 2.0: An Object-Oriented Approach (2nd ed.). New Jersey: John Wiley & Sons, Inc.

Felke-Morris, T. (2010). Web Design Best Practices Checklist. Retrieved February 17,

2011 from the World Wide Web: http://terrymorris.net/bestpractices/

Galway, L. (2004). Quantitative Risk Analysis for Project Management: A Critical Review. Retrieved February 6, 2011 from the World Wide Web: http://www.rand.org/pubs/working_papers/2004/RAND_WR112.pdf

Greenspun, P., and Grumet, A. (2009). Software Design Review. Retrieved March 1, 2011

from the World Wide Web: http://philip.greenspun.com/software/design-review

Heberling, G. (2011). Human Factors and HCI. Lecture Notes. Retrieved March 1, 2011 from the World Wide Web: http://www.personal.psu.edu/glh10/ist110/topic/topic08/topic08_02.html

Heim, S. (2008). The Resonant Interface: HCI Foundations for Interactive Design. Massachusetts: Pearson Education, Inc.

HostGator.com. (2011). Home Page. Retrieved February 26, 2011 from the World Wide Web: http://www.hostgator.com/shared.shtml

Hu, G. (2007). Systems Engineering II: Network Centric Systems Architecting and Engineering. American Institute of Aeronautics and Astronautics. Long Beach, CA, 14 September 2007.

Kaner, C. (2003). What is a Good Test Case? Retrieved February 24, 2011 from the World Wide Web: http://www.kaner.com/pdfs/GoodTest.pdf

Kirkman, C. (2009.) Who needs tickets? Examining problems in the growing online ticket resale industry. Federal Communications Law Journal. Vol. 61, Nbr. 3.

Laudon, K.C. & Laudon J.P. (2006). Management Information Systems: Managing the Digital Firm (6th ed.). New Jersey: Pearson Prentice Hall.

Lewis, J. (2007). The Project Manager's Desk Reference (3rd ed.). New York, NY: McGraw-

Hill.

Microsoft, Inc. (2011). Guidelines for Conducting Design and Code Reviews. Retrieved February 8, 2011 from the World Wide Web:

http://msdn.microsoft.com/en-us/library/ms182019(v=vs.80).aspx

PayPal. (2011). Press Center. Retrieved March 13, 2011 from the World Wide Web:

https://www.paypal-media.com/who

Putler, D. and Lele, S. (2003). An Easily Implemented Framework for Forecasting Ticket Sales to Performing Arts Events. Marketing Letters, Volume 14, Number 4, pp. 307-320.

Schwalbe, K. (2006). Information Technology Project Management (4th ed.). Canada: Thompson Course Technology.

Stellman, A. (2010). Understanding Nonfunctional Requirements. Retrieved March 1, 2011 from the World Wide Web:

http://broadcast.oreilly.com/2010/02/nonfunctional-requirements-how.html

Turban, E., Aronson, J., Liang, T. and Sharda, R. (2007). Decision Support and Business Intelligence Systems (8th ed.). New Jersey: Pearson Prentice Hall.

Turban, E., Leidner, D., McLean, E., and Wetherebe, J. (2008). Information Technology for Management: Transforming Organizations in the Digital Age. USA: John Wiley & Sons, Inc.

Turbit, N. (2006). Developing a Test Plan. Retrieved February 20, 2011 from the World Wide Web: http://www.projectperfect.com.au/downloads/Info/info_test_plan.pdf

Verizon Business. (2009). 2009 Data Breach Investigations Supplemental Report: Anatomy of a Data Breach. Retrieved on March 23, 2011 from the World Wide Web: http://www.verizonbusiness.com/resources/security/reports/rp_2009-data-breach-investigations-supplemental-report_en_xg.pdf

Whitman, M., and Mattord, H. (2009). Principles of Information Security (3rd ed.) Canada: Course Technology.

Wilder, E. (2007). Ajax Tutorial. Retrieved March 11, 2011 from the World Wide Web:

http://www.ethanwilder.com/projects/ajaxtutorial/index.php

APPENDIX A

INTERVIEWS

The primary stakeholder of this project was Mr. Jeff Martin, who is the Director of Application Development at a regional insurance company in Scottsdale, Arizona. During two initial interviews, a co-located project team member gathered an overall description of the proposed application within days of the project team’s formation. Additional, less formal interviews were held with potential users on behalf of the primary stakeholder to gather additional functional requirements from both a School Event Coordinator and a ticket purchaser perspective. The project team provided preliminary validation of its ability to complete the project within the allowable timeframe and used this information to allow assignment of primary roles within the group, based on advertised skill sets and experiences. This information was also used as the basis for gathering detailed requirements and work plan estimates.

The second interview with the primary stakeholder was conducted in a question and answer format by using a set of pre-established questions to ensure the project team had a full set of functional and non-functional requirements. The intent was to gather detailed information about the problems the application must solve, as well as a more detailed view of the objectives of the application. Some questions were designed to drill down into the details of certain objectives to ensure the team had a complete understanding of specific requirements. Other questions were designed to gather information on elements of the application that were not previously described in the initial interview.

In the interest of time, assumptions were made by the project team about the requirements of ticket purchasers, as well as any gaps that were found during usability testing. The primary interview provided enough detail to understand the overall vision of the application and the main objectives that were eventually met.

Initial Interviews

Interviewee: Jeff Martin, Project Sponsor

Interviewer: George Hubert, Principal Developer

Interview Date: February 1, 2011

During the primary interviews, Mr. Martin provided an overview of the problems he wanted to solve, the gap in available school resources, and his vision of the application he believed would solve this gap. He drilled down into a few project highlights and set some high-level expectations. The details of the interview are outlined below:

Problem Statement: There are several challenges that schools and parents face when schools sell tickets to school events.

· Selling tickets at the event provides no insight to parents or School Event Coordinators of potentially sold-out events. This leads to angry parents unable to attend these events.

· Collecting money at the event poses logistical issues with gathering money, making change, securing cash, and accepting alternate methods of payment.

· Selling tickets prior to the event requires students to perform several tasks including taking home and distributing "flyers,” collecting money, and distributing tickets.

· These processes are highly inefficient, which lead to lost revenue, lost tickets, heavy student and parental responsibility, and an inability to predict turnout.

Additional information provided by Mr. Martin included the following:

· Only a base-set of features would be required for a successful launch of the application.

· Additional features could be added post-launch to add more value to the application.

· Only one payment system needs to be provided at launch (PayPal) but additional payment systems could be added at a later date.

Secondary Interview

Interviewee: Project Sponsor

Interviewer: Principal Developer

Interview Date: February 7, 2011

Primary design points:

1. Schools can be found by State/City/School drill down. Schools can be found by zip code/School drill down. Schools can be found by special school-code/School drill down. Schools can be provided with a direct link to their "landing" page that lists all current events. They include:

2. Credit cards will not be taken directly on the site due to PCI compliance-related issues. Payers will be sent to PayPal to enter either their credit card information or their PayPal account information to make a payment. This will require all schools to have a PayPal account and is acceptable for the initial launch phase of the project.

3. Not all users will need to have a PayPal account, as users can enter credit card information without signing up at PayPal. This is a merchant-configured setting and is another requirement that the application will put on schools. PayPal will send information back via IPN. This will require common but specific settings at PayPal. IPN is PayPal's way of sending back payment transaction information to a site without the need of the purchaser to click on a "return to site" link. When the customer purchases a ticket, they will not provide any information directly on the application website. This information will be provided via the IPN notification from PayPal.

4. All communication between the Site Administrator and the School Event Coordinators will be done outside of the application via email links. All communication between the School Event Coordinators and ticket purchasers will be done outside of the application. The ticket purchaser, along with any other site visitor, can contact the Site Administrator via contact information on the site's contact page.

5. The Site Administrator will need a sign-up report (list of school sign-ups). Other reports and statistics can be added to the site using third-party products such as Google Analytics but are not part of this project.

6. Site Administrators can reset passwords, suspend accounts and change email addresses of School Event Coordinators but will not be able to manipulate event information.

7. School Event Coordinators can upload a school logo, set up PayPal information, and provide text information for the school, as well as for events. The system will show reports of numbers of tickets sold by event and amount of revenue for event. School Event Coordinators can communicate with potential customers by providing a contact email address in the event description. The data model contains the following relationships:

· One School Event Coordinator per school, but multiple School Event Coordinators in the future (supported by current db design)

· Multiple events per school

· Multiple ticket types per date (balcony, standing, orchestra, bleacher, etc.)

· Sales related to ticket types

· Sales items (tickets) related to sales

8. Quick relational map (each lower item relates to the higher item (in a one-to-one or many–to-one relationship)

Mary Smith (coordinator)

Ridell High (school)

School Carnival (event)

Sound of Music Musical Saturday at 4:00 (event)

Balcony seats at $5.00 (ticket type)

Orchestra seats at $10.00 (ticket type)

Sale to John Smith for $30.00 (sales)

Sale of balcony seats qty 2

Sale of orchestra seats qty 2

Sale of a program qty 1

9. Ticket types are used to limit the number of tickets sold in a given area (such as a seating area) and can be used to differentiate pricing between tickets. Each ticket can have up to three (3) prices. It was confirmed that the program would be hard-coded at three price levels per ticket type. This will allow ticket prices for the same ticket type to be offered with a student price, general admissions price, and a senior citizen price (or other pricing structures configured by the school).

10. The system should be able to offer additional items for sale with each purchase. These are items that are not directly related to a ticket type but to the event. Examples are selling programs, flowers, and items with school logos, etc. These items can be entered per event. This is a nice-to-have feature that may be added at a future release.

11. Ticket purchasers can enter a student (or other special) ID to give credit for the sale to a certain individual or group. This will be tracked with the sale and a report will be available with aggregate numbers for each event. This is a nice-to-have feature that may be added at a future release.

12. All screens will have individual help on the page, pop-up help for more detailed information and a Frequently Asked Questions (FAQ) page (no FAQ page for Site Administrators). A full description of the site’s features is required as part of the signup process for School Event Coordinators.

13. There is no requirement for high availability, but the system must support daily and weekly backups as part of a routine operation provided by the web host. Monitoring of any type is not part of the project. The system will not send emails or alerts. The web host for the project will be HostGator.com, as the configuration or operations of the hosting environment is not part of this project. The approved development platform is PHP 5.3 or newer and MySQL 5 with the CodeIgniter 2.0 framework, JQuery, JavaScript library, CSS based layout and all major browser support.

14. The application will not be set up as a revenue generating website at this time. All services are provided at no cost to School Event Coordinators and ticket purchasers. The Site Administrator may decide to create a revenue stream from the site in the future, but it is not part of this project.

15. Security elements require passwords to be hashed (non-reversible). As no credit card data or personal data will be gathered at the site, no SSL encrypted pages are required. Database access will be password protected and configured in the script.

APPENDIX B

CLIENT AGREEMENT

This is an agreement between …

1. SERVICES RENDERED. TEAM agrees to perform following Web design services:

· Website design

· Simple graphic design including logos, navigation bar, buttons, etc.

· Home page, sign-up page, login page, terms of service page, privacy policy page

· Website application that allows for the sale of school event tickets to the public

· Search for school and event using state and city, zip code or school ID.

· Shopping cart that allows the purchase of school event tickets via PayPal

· Email confirmation of all orders

· Management area for schools to enter events and tickets

· Management area for Site Administrator to manage schools

· All pages, graphics, coding, design and work to run the site including not more than 40 programmatically generated web pages

· Database design

· Two Reports for the School Event Coordinators

· Documentation for the installation, daily operation and troubleshooting of the website application

· Installation of application on one web hosting provider virtual hosting environment

The services described are to be provided by TEAM in accordance with commonly accepted standards and practices of the web development industry. This includes the use of PHP, MySQL, HTML4, CSS, Javascript, jQuery and CodeIgniter as principle technologies in the development of the website.

Services that will not be performed or provided include the following:

· Monitoring

· Backup services

· Credit card processing

· Charting

2. COST. The services described in this agreement will be provided free of charge.

3. ADDITIONAL SERVICES. The terms and conditions set forth in this document constitute the sole agreement between CLIENT and TEAM regarding this website. Any additional work not specified in this contract must be authorized in writing. Should the client desires additional standard Web pages beyond the original number of pages specified above, CLIENT must renegotiate for those specific services.

APPENDIX C

SCOPE, COMPLEXITY AND WORK PLAN ESTIMATES

The scope and complexity of SchoolTicketsOnline.com centered on the strength of the Project Manager’s ability to facilitate communication and documentation, the sophistication of the actual web interface design, and the technical skill sets needed for the actual web and database development and testing. The biggest technical challenge was linking the database into the web interface and doing so securely. The estimate stood at 160 hours for actual web development and 97 hours for database development. Estimates were very conservative, given the extremely compressed time afforded to complete the project. Project planning would have been incomplete, communication between team members would have been relatively inefficient, and unexpected changes in the design would have caused multiple delays (or even feature cancellation) if large amounts of slack were not built into the estimates of every functional area.

Estimates to Complete Analysis, Design, and Construction

Requirements Definition

· No credit card information will be taken directly on the site due to PCI compliance-related issues. Ticket purchasers will be sent to PayPal to either enter their credit card information or enter their PayPal account information to make a payment.

· Schools will be found by State/City/School drill down. Schools will be found by zip code/School drill down. Schools will be found by special school-code/School drill down. Schools will be provided with a direct link to their "landing" page that lists all current events. This link can then be used by schools in their communications of their events (such as in emails, on the school website, etc.).

· All communication between the Site Administrator and the School Event Coordinators will be done outside of the application via email links. All communication between the School Event Coordinators and ticket purchasers will be done outside of the application via email links.

· The ticket purchaser, along with any other site visitor, can contact the Site Administrator via contact information on the site's contact page. The Site Administrator will need a signup report to see the schools that have signed up.

· Other reports and statistics can be added to the site using third-party products such as Google Analytics but are not part of this project. The Site Administrator should be able to reset passwords, suspend accounts and change email addresses of School Event Coordinators but will not be able to manipulate event information.

· School Event Coordinators can upload a school logo, set up PayPal information, and provide text information for the school as well as events.

· The system will show reports of number of tickets sold by event and amount of revenue for each event.

· School Event Coordinators can communicate with potential customers by providing a contact email address.

· Schools may offer "free" tickets through the site where there is no checkout process. Free tickets can have a limit per email address and an overall ticket limit. This is a nice-to-have feature that may be added at a future date.

· The system will be able to offer additional items for sale with each purchase. These are items that are not directly related to a ticket type but to the event. Examples are selling programs, flowers and items with school logos, etc. These items can be entered per event. This is a nice-to-have feature that may be added in a future release.

· All screens will have individual help on screens, pop-up help for more detailed information and a FAQ page (no FAQ page for Site Administrators). A full description of the website’s features is required as part of the signup process for School Event Coordinators. The application will not be set up as a revenue generating website at this time.

· All services are provided at no cost to School Event Coordinators and ticket purchasers. The Site Administrator may decide to create a revenue stream from the site in the future, but it is not part of this project.

Database Design

The following activities for this system’s database design covered requirements gathering, domain analysis, creating domain models, and creating database documentation. The approved database platform was MySQL 5. It was used to build the database tables and indexes and was populated with appropriate data to validate the application requirements and the appropriateness of the web interface through testing. Data elements included the name of the school, city, state, zip code, and school ID.

Interface and Graphic Design

This covered the work in creating a site logo, background, photos, artwork, and font selection to fit the theme of each section of the website. However, the requirements for this project were to create simple graphic design and interface elements to ensure timely delivery of the project. Therefore, less required effort was anticipated in this area during Milestone One and was realized in Milestone Three. Photos and artwork were not incorporated.

System Documents and Procedures

The development of necessary system documents and procedures to cover all screens will have individual help on screens, pop-up help for more detailed information, and a FAQ page (no FAQ page for Site Administrator). A full description of the website features is required as part of the signup process for School Event Coordinators. In addition, there was documentation for the database design.

Estimate Breakdown of Programming Business Logic

	Section	Page	Hours
	Main	Home page	4
	Main	School	3
	Main	Event	3
	Main	Ticket	3
	Main	Cart	4
	Main	Thank You	2
	Main	Print ticket	1
	Main	Signup	2
	Main	Signup thank you	1
	Main	School login	1
	Main	School reset password	1
	Main	School password reset	1
	Main	Terms	1
	Main	Privacy	1
	Main	Contact	1
	Main	Help	1
	School	Home page	2
	School	School edit	3
	School	Admin edit	3
	School	Event list	1
	School	Event add	2
	School	Event edit	3
	School	Date list	1
	School	Date add	2
	School	Date edit	3
	School	Ticket list	1
	School	Ticket add	2
	School	Ticket edit	3
	School	Ticket type list	1
	School	Ticket type add	2
	School	Ticket type edit	3
	School	View sales	2
	School	View visitors	2
	School	Help	1
	Admin	Home page	3
	Admin	Site settings	3
	Admin	School list	1
	Admin	School edit	3
	Admin	Admin list	1
	Admin	Admin edit	3
	Admin	View signups	2
	Admin	View traffic	2
	Admin	Help	1
	Email	Email school password	2
	Email	Email admin password	2
	Email	Email ticket order	2
	Transaction	Paypal IPN	5
			Total Hours: 97 + 160 hours for web design, integration and unit testing

Estimates to Complete Overhead Functions

Project Management

Total: 138 hrs

 

I. Initiating (Total: 5 hrs)

    A. Mission / Group Statement (1 hr)

    B. Determine / assign roles and responsibilities    (3 hrs)

    C. Identify skill set gaps and fill  (1 hr)

 

II. Planning (Total: 25 hrs)

    A. Hold project kick-off meeting    (2 hr)

    B. Help mold vision statement and project scope (1 hr)

    C. Prepare schedule

        i. Determine task resources (2 hrs)

        ii. Determine task durations (2 hrs)

        iii. Determine task dependencies (2 hrs)

        iv. Create project Gantt chart (4 hrs)

        v. Create detailed tasking by milestone (10 hrs [2 hrs each])

    D. Help identify, discuss, and prioritize project risks (2 hrs)

 

III. Executing (Total: 30 hrs)

    A. Hold meetings; take and disseminate minutes and action items (24 hrs [3 hrs / 8 weeks])

    B. Align stakeholder / user inputs with developer, analyst, vision and scope (6 hrs)

 

IV. Controlling (Total: 60 hrs)

    A. Milestone Report 1 - 12 hours

    B. Milestone Report 2 - 12 hours 

    C. Milestone Report 3 - 12 hours

    D. Milestone Report 4 - 12 hours

    E. Milestone Report 5 - 12 hours

 

V. Closing (Total: 18 hrs)

    A. Final Report - 10 hours

    B. Final Presentation - 5 hours

    C. Lessons Learned - 3 hours

Code and Design Reviews

The review of code and design provided a thorough examination of raw code and design plans during early stages of the design phase, before the system had been fully integrated and assembled. This review was coordinated by the Quality Assurance Manager and was conducted in a group setting, allowing input from each member of the project team. The review process followed a checklist, which included end user requirements and other necessary considerations. Any issues were noted and discussed with the Principal Developer before further work was completed. Recommendations gained from the review were provided in writing to the developers and were included with the final project documentation. Total estimated time was 16 hours.

Integration and System Level Testing

Testing of the comprehensive system, including integration and system level testing, was conducted during the final stage of the design phase. The overall purpose of these testing procedures was to verify final system usability and could have only been effectively performed on a completed system. Further details on integration and system level testing, to include method and schedule, were provided in the Test Plan. Total estimated time was 36 hours.

Quality Assurance Activities

System requirements were clearly understood and agreed to by the project team and the sponsor prior to commencing work on the application. Any changes to the preliminary approved scope were initially to be submitted in writing as formal Change Requests in order to minimize deviation from the original user requirements. During the planning and analysis phases, project team members conducted extensive interviews to gain complete understanding of user requirements, enhancing the project team's ability to provide a high quality product to the stakeholder. Other quality assurance activities included systems testing, analysis of various use case scenarios, and design/code review as previously discussed. Total estimated time was 56 hours.

APPENDIX D

PROJECT SCHEDULE

	Start Date	End Date
Initiation (Milestone One: 1/31 - 2/12)	31-Jan	9-Feb
Select Collaboration Tools	1-Feb	9-Feb
Strategy	1-Feb	5-Feb
Vision	5-Feb	9-Feb
Planning (Milestone One: 1/31 - 2/12)	2-Feb	12-Feb
Scope	2-Feb	12-Feb
Determine project scope	8-Feb	12-Feb
Secure project sponsorship	3-Feb	7-Feb
Resource allocation	1-Feb	7-Feb
Initial Data Flows	4-Feb	12-Feb
Initial risk analysis	6-Feb	12-Feb
Initial problem analysis	6-Feb	12-Feb
Feasibility	3-Feb	9-Feb
Draft Client Agreement	7-Feb	12-Feb
Design (Milestone Two: 2/13 - 2/26)	13-Feb	26-Feb
Develop functional specifications	13-Feb	26-Feb
Non-functional requirements	13-Feb	26-Feb
Identify interfaces	13-Feb	20-Feb
Up-date data flows	13-Feb	26-Feb
Class diagrams	13-Feb	20-Feb
Data model	16-Feb	20-Feb
Draft prototype based on functional specifications	22-Feb	26-Feb
Identify system documentation	13-Feb	23-Feb
Stakeholder review	22-Feb	24-Feb
Quality Assurance (Milestone Two & Three: 2/13 - 3/12)	13-Feb	12-Mar
Defect Tracking	20-Feb	12-Mar
Technical Reviews	27-Feb	12-Mar
Code and design review	27-Feb	6-Mar
Change Controls	12-Feb	26-Feb
System Metrics	20-Feb	12-Mar
Coding & Testing (Milestone Two - Four: 2/13 - 3/26)	13-Feb	26-Mar
Initial development of code and web interface	20-Feb	6-Mar
Unit testing	7-Mar	13-Mar
Primary debugging	7-Mar	9-Mar
Modify code	10-Mar	11-Mar
Re-test	12-Mar	13-Mar
Integration and system level testing	16-Mar	23-Mar
Integration testing (system operability)	16-Mar	18-Mar
Modify code	17-Mar	17-Mar
Re-test	18-Mar	18-Mar
Usability testing (user interface/navigation)	19-Mar	23-Mar
Modify code	20-Mar	21-Mar
Re-test	22-Mar	23-Mar
Acceptance testing	23-Feb	25-Mar
Close Out (Milestone Four & Five)	13-Mar	9-Apr
Write system documentation	27-Mar	9-Apr
Develop Help specification	27-Mar	2-Apr
Develop Help system	3-Apr	9-Apr
Develop User Manuals specifications	27-Mar	2-Apr
Develop User Manuals	3-Apr	9-Apr
Develop other System and Archival specifications	27-Mar	2-Apr
Develop other System and Archival documents	3-Apr	9-Apr
Defect Report	27-Mar	9-Apr
Final Usability Report	27-Mar	9-Apr
Lessons Learned	3-Apr	9-Apr
Presentation (Weeks 11 - 13: 4/10 - 4/30)	10-Apr	30-Apr
Finalize prototype	10-Apr	16-Apr
Draft outline	10-Apr	13-Apr
Final PowerPoint	13-Apr	25-Apr
Faculty review	18-Apr	28-Apr

APPENDIX E

TASK ASSIGNMENTS

Milestone 1: Project Definition WHO DUE STATUS

(as of 2/12/11)

Idea generation Group 3 2/4 CLOSED

Sponsorship Group 3 2/4 CLOSED

Draft client agreement George 2/11 CLOSED

Determine clients meetings George 2/11 CLOSED

Vision / Capabilities / Scope George / Ryan 2/9 CLOSED

Data flow diagrams Walter / George 2/9 OPEN

Identify stakeholders Walter / George 2/6 CLOSED

Feasibility Walter 2/11 OPEN

Problem Analysis Chris 2/11 CLOSED

Known constraints Group 3 2/4 CLOSED

Assumptions Group 3 2/4 CLOSED Interview stakeholders George 2/11 CLOSED

Nonfunctional Requirements Ryan 2/11 CLOSED

Complexity Estimates George / Ryan 2/11 CLOSED

Work Plan Estimates Eric 2/9 CLOSED Project management Eric 2/9 CLOSED

Data flows Walter 2/9 OPEN

Database design George 2/9 CLOSED

Interface and graphic design Ryan 2/9 CLOSED

Code and design reviews Chris / George 2/9 CLOSED

Integration and system testing Chris / Ryan 2/9 CLOSED System documentation Walter / Chris 2/9 CLOSED

Quality Assurance Chris 2/9 CLOSED

Team structure and capabilities Eric 2/11 CLOSED

Submit resumes Group 3 2/4 CLOSED

Assign roles and responsibilities Group 3 2/5 CLOSED

Determine needed skill sets Group 3 2/5 CLOSED

Project Plan

High level for term Eric 2/11 OPEN

Specific for Milestone One Eric 2/4 CLOSED

Specific for Milestone Two Eric 2/11 OPEN

Risk Analysis Chris 2/11 CLOSED

Milestone One Report

Version controls Eric 2/9 CLOSED

Peer review technical Group 3 2/10 CLOSED

Peer review draft final Eric / Group 3 2/12 CLOSED

Milestone Two: Design WHO DUE STATUS

(as of 2/26/11)

Finalize requirements George / Ryan 2/16 CLOSED

Design

Up-date data flow diagrams Walter 2/23 OPEN

Review of system interfaces Ryan 2/20 CLOSED

Finalize Class diagrams

Identify classes George 2/16 CLOSED

Identify relationships George 2/16 CLOSED

Identify attributes George 2/16 CLOSED

Finalize Database design

Data model George 2/20 CLOSED

Data dictionary George 2/20 CLOSED

Review functionality

For prototype George / Ryan 2/20 CLOSED

For delivery George / Ryan 2/20 OPEN

Implementation

Quality Assurance

Identify documentation Walter 2/16 OPEN

Defect tracking

Determine method Chris / Group 3 2/20 CLOSED

Put process in place Chris - OPEN

Technical reviews

Code/Design reviews Group 3 2/20 CLOSED

Documentation/report Chris 2/23 CLOSED

review results/findings

Test plans

Draft test plan Chris 2/20 CLOSED

Draft test cases Walter 2/20 OPEN

Schedule testing Chris / Group 3 2/20 CLOSED

Document control

Determine method Chris / Group 3 2/20 CLOSED

Put process in place Chris / Eric 2/25 CLOSED

Source code control

Determine method Chris / Group 3 2/20 CLOSED

Put process in place Chris / Eric 2/25 CLOSED

Project Plan

Up-date high level for term Eric 2/20 CLOSED

Specific for Milestone Three Eric 2/25 CLOSED

Up-date feasibility estimates Eric 2/2 CLOSED

Comment on deviations Eric 2/23 CLOSED

Identify slippage Eric 2/23 CLOSED

Up-date project risk analysis Chris 2/23 CLOSED

Milestone Two Report

Peer review technical Eric 2/20 CLOSED

Peer review draft final Eric / Group 3 2/25 CLOSED

Milestone Three: Design and WHO DUE STATUS

Implementation (as of 3/12/11)

Finalize client agreement George 3/2 OPEN

Design

Up-date data flow diagrams Walter 3/2 CLOSED

Finalize system interfaces Ryan 3/2 SUSPEND

Unit testing

Begin debugging George 3/9 CLOSED

Begin code mod George 3/11 CLOSED

Review functionality

For prototype Group 3/6 CLOSED

For delivery Group 3/6 CLOSED

Review report Eric 3/9 CLOSED

System Documentation

Outline User Manual Ryan 3/9 CLOSED

Outline Archival (source code George 3/11 OPEN

Directory structures, architecture

And engineering diagrams, and

Configurations files)

Implementation

Specific for Milestone 4 Eric 3/9 CLOSED

Comment on deviations Eric 3/9 CLOSED

Identify slippage Eric 3/11 CLOSED

Quality Assurance

Finalize other testing Chris 3/2 CLOSED

Test cases Walter 3/6 REASSIGN

Code and design review Group / Chris 3/6 CLOSED

Begin defect tracking Chris / Eric 3/11 CLOSED

Project Management

Up-date project feasibility Eric 3/11 CLOSED

Comment on deviations Eric 3/9 CLOSED

Up-date project risks Chris 3/11 CLOSED

Comment on system metrics Chris 3/9 OPEN

Milestone Three Report

Submit assigned sections Group 3 3/11 CLOSED

Peer review draft final Group 3 3/12 CLOSED

Submit final to Faculty Eric 3/12 CLOSED

Milestone Four: Implementation WHO DUE STATUS

and Testing (as of 3/26/11)

Testing

Follow-up / fix ‘Code and George 3/20 CLOSED

Design Review’ results

Finish unit testing

Document results Chris 3/19 CLOSED

Modify code / design George 3/20 CLOSED

Retest George 3/23 CLOSED

Finish system level testing

Document results Chris 3/19 CLOSED

Modify code / design George 3/20 CLOSED

Retest Chris 3/23 CLOSED

System Documentation

Finish Site Admin User Guide Ryan 3/23 OPEN

Finish Event Coordinator Ryan 3/23 OPEN

Admin User Guide

Outline Archival Package George 3/25 CLOSED

Quality Assurance

Complete Technical Review Chris 3/2 CLOSED Results

Complete Unit Level Test Chris 3/25 CLOSED

Results

Complete System Level Test Chris 3/25 CLOSED

Results

Complete Risk Analysis Chris 3/25 CLOSED

Project Management

Reassess project requirements Eric 3/23 CLOSED

Comment on slip and Eric 3/25 OPEN

deviations

Comment on system metrics Eric 3/25 CLOSED

Finalize feasibility Eric 3/25 CLOSED

Finalize project plan Eric 3/25 CLOSED

Milestone Four Report

Submit assigned sections Group 3 3/25 CLOSED

Peer review draft final Group 3 3/26 CLOSED

Submit final to Faculty Eric 3/26 CLOSED

APPENDIX F

TEST PLAN

Objectives

The purpose of the Test Plan was to ensure the delivery of a high quality system that met all user requirements, as specified by the stakeholder and recommended by the project team. Additionally, the testing outlined within this plan focused on optimizing the performance and design of SchoolTicketsOnline.com in order to gain stakeholder acceptance of the completed system and ensure that all expectations had been met.

This Test Plan covered the following:

· Description, goal, and focus of each test

· System components and features to be tested

· Description of testing approach

· Entry and exit criteria

· Environmental considerations

· Testing schedule

· Format of test cases

· Defect reporting and tracking procedures

· Estimated time required to perform system testing

Testing Methodology

Testing Methods

1. The Code and Design Review was the first analysis of the system’s database structure and website design. The project team performed this review using a checklist of predefined items based on the web design principles and system requirements. The use of a detailed checklist guaranteed a thorough review, focusing on every aspect of system design and coding. The reviewers noted any potential defects they identified, any deviation from outlined system requirements, and any other comments or questions based on their assessment. A full report of this review was made available to the stakeholder. A full report of this review is found in Appendix G, Section 1: Technical Review Results.

2. Unit testing was performed by the development team and consisted of a comprehensive assessment of database functionality, website coding, and the integration of these two elements. The scope and results of this testing were documented by the Quality Assurance Team, which was led by Christian Larsen. See Appendix G, Section 2: Unit Level Test Results for a sampling of the project’s unit test cases and test results.

3. System level testing was performed on the completed system in the form of integration and usability testing. Integration testing confirmed that the different components of the system operated correctly as an assembled, complete system and focused on overall quality, functionality, and performance. Usability testing was directed toward enhancement of system interfaces and ease of usability. The usability testing involved a group of potential end users of varying skill levels and backgrounds completing common tasks on the web site and providing feedback in the form of a brief survey. Both quantitative and qualitative analysis was performed on the data obtained from the survey, and recommendations were made to the project team based on the findings. The goals of these tests were to validate system features and to confirm that all system requirements were met. The final usability report was based on the results of these tests. The final usability report is found in Appendix G, Section 3: System Level Test Results.

4. Acceptance testing took place with members of the development team, Quality Assurance Manager, and the stakeholder present. This testing was used to document final system delivery and to verify that stakeholder expectations were met. This test demonstrated the operability of each system component and specifically covered all outlined system requirements. A full report of this review is found in Appendix G, Section 4: Acceptance Test Results.

Items Tested

Each component of the system was tested, including each web page and the system database. Additional attention was given to each feature outlined as a user requirement, user interface design, and system performance.

Approach

Each member of the project team, as well as several independent contributors, performed testing. The scheduled dates and time allotted for each test were based on the schedule for system development and completion. The schedule for each testing phase allowed sufficient time to document test results and to correct errors or design flaws identified, if any, before entering the next phase of system development.

Entry and Exit Criteria

The conditions outlining the test inputs and expected outputs were provided in each test case or test script. These conditions, when compared to actual test results, were used to determine if the test had passed. When actual test results varied from the expected result, the test had failed. If a test failed, the tester was responsible for recording the reason for failure in the Defect Log.

Testing Environment

System level testing was performed on a live system over the Web. Environmental considerations included the use of several different web browsers and other performance variables, such as connection speed. Testing of the system’s interface with PayPal, the payment gateway, utilized its Sandbox Test Environment. Use of this specialized test environment allowed testers to examine the full ticket purchasing process, from beginning to end.

Test Schedule

	Start Date	End Date
Technical Reviews	27-Feb	12-Mar
Code and design review	27-Feb	6-Mar
Unit Testing	7-Mar	13-Mar
Primary debugging	7-Mar	9-Mar
Modify code	10-Mar	11-Mar
Re-test	12-Mar	13-Mar
System Level Testing	16-Mar	23-Mar
Integration testing (system operability)	16-Mar	18-Mar
Modify code	17-Mar	17-Mar
Re-test	18-Mar	18-Mar
Usability testing (user interface/navigation)	19-Mar	23-Mar
Modify code	20-Mar	21-Mar
Re-test	22-Mar	23-Mar
Acceptance Testing	23-Feb	25-Mar

Test Cases

The system level integration testing was defined by the use of test cases. Each test case outlined the test inputs, the conditions under which the test was conducted and the expected outcome. Additionally, each test case detailed the steps required to complete each test. To ensure procedural consistency, testers used the test cases as the primary guideline for conducting each required system level integration test.

Defect Reporting and Tracking

All defects identified during technical reviews and formal testing were entered in a Defect Log. This log documented each defect, the discovery method and date, the tester who identified the defect, and corrective actions taken. Each action to correct the defect included the person who completed the correction and the date. After corrective measures were complete, re-testing occurred and the results were recorded in the Defect Log. Once the applicable re-test was successfully passed, the defect status was listed as “RESOLVED” and no further action was taken. This tracking method was used for each defect identified within the system. The Defect Log was maintained by the Quality Assurance Manager and used to generate the final Defect Report. (See Appendix G, Section 5: Defect Log.)

Testing Workload Estimation

Test Activity Tester(s) Hours

Code and Design Review	Project Team	4
Documentation of Results	QA Team	4
Unit Testing
Database	Development Team	6
Website/User Interface	Development Team	6
Documentation of results	QA Team	4
System Level Testing
Integration testing (system functionality)	QA Team	8
Usability testing (user interface/navigation)	QA Team/Independent	12
Other testing, as required	QA Team/Other	12
Documentation of results	QA Team	6
Acceptance Testing
Acceptance test (with stakeholder)	Development/QA Teams	4
Final usability report	QA Team	4
Total workload estimation for all testing activities	70

APPENDIX G

TEST RESULTS

Section 1: Technical Review Results

A technical review of code and design was conducted by a review team comprised of all members of the project team, according to the schedule outlined in the Test Plan. The central focus of the review was to isolate potential system defects, identify deviations from established system requirements, and provide an analysis of the design techniques in use. The review was structured around the code and design checklist, which is included at the end of this section. It also relied on explanations by the Principal Developer. Additionally, the Principal Developer provided clarification on technical points and answered questions from the review team relating to design and coding choices. The checklist used for this review, Figure 11, is based on web design principles and the specific requirements of this system.

Figure 11: Code and Design Review Checklist

Interface Design

It was determined that site navigation was in line with the “three click rule;” design was simple and concise, as desired; navigation links were clear and consistent; and use of different colors was kept to a minimum, with consistent use of colors allowing each to remain distinguishable. The text, menus, and links were organized in such a way that user attention was drawn to the most commonly accessed features first.

By design, the administrative areas of the website, which is to be used by Event School Coordinators and the Site Administrator, utilized an interface different in appearance from the other areas of the site. Each of these interfaces also utilized concise and effective design principles, focusing on ease of usability.

Items that were addressed during system level testing included:

· Verification of logo consistency later in the system’s development

· Automated check for spelling and grammatical errors near system completion

Database Design

The Principal Developer explained to the review team design choices relating to database structure. Class diagrams and the data dictionary for this database fulfilled the requirement of the project to provide adequate database documentation to the stakeholder. Both support system maintainability. Database structure was determined to be logical and consistent, supporting both current required functionality and scalability.

Code

The search mechanics for school functionality, such as “Search by Zip Code,” employed AJAX technologies, which eliminates the need to reload the web page to view search results. For example, when a user types the first four digits of the zip code, a list of schools interactively populates the drop-down menu. As the fifth digit of the zip code is entered, the list is further refined, including only schools within that five digit zip code. AJAX works with HTML and CSS code, using JavaScript to display information accessed directly from the database. This design enhances site usability by preventing too many items from being displayed in the drop-down lists. This feature also increases the ease of searching for a school by not requiring a page reload after the zip code has been entered. It was further determined that the code used throughout this site conforms to commonly accepted standards.

Browser Compatibility

The design and code choices for SchoolTicketsOnline.com were found to be compatible for use with various web browsers. At a minimum, the site displayed as intended and designed using Internet Explorer versions 7 and higher; Google Chrome versions 9.0 and higher; Mozilla Firefox versions 3.0 and higher; and both the Mac and Windows versions of Safari 2.0 and higher. (More complete browser compatibility testing was performed during system level testing. See Appendix G, Section 3.2: Browser Compatibility Test Results.)

System Requirements

Independently designed interfaces were present for the customer, School Event Coordinators, and the Site Administrator. The interfaces for School Event Coordinators and the Site Administrator provided a secure login, which fulfilled the system requirement to provide protected management interfaces. The Site Administrator had access to the Administrator Control Panel, providing access to activate or deactivate school accounts, approve accounts, and perform other necessary administrative functions.

Schools had the ability to provide a link directly to the landing page and provide potential ticket purchasers with their school code, simplifying the search process. Customers of SchoolTicketsOnline.com had the ability to contact the Site Administrator if necessary, using an email link provided on the home page.

Requirements addressed during system level testing included:

· Confirmation emails, sent by the system, for all ticket purchases

· School Event Coordinators’ access to view number of tickets sold, visitor tickets, and ticket revenue

· School Event Coordinator has the ability to generate reports providing a printable list of tickets sold for each event

· Interactive pop-up help feature

· System level testing verified the ability of individual schools to upload personalized logos to their landing page

Section 2: Unit Level Test Results (Sample)

This section is a sample of the extensive Unit Level Test written to ensure the proper functionality of all critical database and user activity.

School Read/Write

Test Name	Write a school record to the database
Test Datatype	Integer
Expected Datatype	int
Result	Passed
File Name	/home/schoolt/public_html/application/controllers/test.php
Line Number	29
Notes	This test writes a school record to the database with valid data for all fields

Test Name	Read the school record that was just created from the database
Test Datatype	Boolean
Expected Datatype	Boolean
Result	Passed
File Name	/home/schoolt/public_html/application/controllers/test.php
Line Number	30
Notes	This test reads a school record from the database and validates that all fields are returned

Find School By City

Test Name	Try to read a school that is not activated based on city
Test Datatype	Array
Expected Datatype	Boolean
Result	Passed
File Name	/home/schoolt/public_html/application/controllers/test.php
Line Number	33
Notes	This test forces the activated field to be false and then tries to read the record based on the city lookup. A good test returns no records

Test Name	Try to read a school that is activated based on city
Test Datatype	Array
Expected Datatype	Boolean
Result	Passed
File Name	/home/schoolt/public_html/application/controllers/test.php
Line Number	34
Notes	This test forces the activated field to be true and then tries to read the record based on the city lookup. A good test returns the records

Test Name	Try to read a school that is not approved based on city
Test Datatype	Array
Expected Datatype	Boolean
Result	Passed
File Name	/home/schoolt/public_html/application/controllers/test.php
Line Number	35
Notes	This test forces the approved field to be false and then tries to read the record based on the city lookup. A good test returns no records

Test Name	Try to read a school that is approved based on city
Test Datatype	Array
Expected Datatype	Boolean
Result	Passed
File Name	/home/schoolt/public_html/application/controllers/test.php
Line Number	36
Notes	This test forces the approved field to be true and then tries to read the record based on the city lookup. A good test returns the records

Find School By Zip

Test Name	Try to read a school that is not activated based on zip
Test Datatype	Boolean
Expected Datatype	Boolean
Result	Passed
File Name	/home/schoolt/public_html/application/controllers/test.php
Line Number	39
Notes	This test forces the activated field to be false and then tries to read the record based on the zip lookup. A good test returns a message that no records were found

Test Name	Try to read a school that is activated based on zip
Test Datatype	Boolean
Expected Datatype	Boolean
Result	Passed
File Name	/home/schoolt/public_html/application/controllers/test.php
Line Number	40
Notes	This test forces the activated field to be true and then tries to read the record based on the zip lookup. A good test returns a string that does not say that no records were found

Test Name	Try to read a school that is not approved based on zip
Test Datatype	Boolean
Expected Datatype	Boolean
Result	Passed
File Name	/home/schoolt/public_html/application/controllers/test.php
Line Number	41
Notes	This test forces the approved field to be false and then tries to read the record based on the zip lookup. A good test returns a message that no records were found

Test Name	Try to read a school that is approved based on zip
Test Datatype	Boolean
Expected Datatype	Boolean
Result	Passed
File Name	/home/schoolt/public_html/application/controllers/test.php
Line Number	42
Notes	This test forces the approved field to be true and then tries to read the record based on the zip lookup. A good test returns a string that does not say that no records were found

Find School By Code

Test Name	Try to read a school that is not activated based on code
Test Datatype	Boolean
Expected Datatype	Boolean
Result	Passed
File Name	/home/schoolt/public_html/application/controllers/test.php
Line Number	45
Notes	This test forces the activated field to be false and then tries to read the record based on the zip lookup. A good test returns a message that no records were found

Test Name	Try to read a school that is activated based on code
Test Datatype	Boolean
Expected Datatype	Boolean
Result	Passed
File Name	/home/schoolt/public_html/application/controllers/test.php
Line Number	46
Notes	This test forces the activated field to be true and then tries to read the record based on the zip lookup. A good test returns a string that does not say that no records were found

Test Name	Try to read a school that is not approved based on code
Test Datatype	Boolean
Expected Datatype	Boolean
Result	Passed
File Name	/home/schoolt/public_html/application/controllers/test.php
Line Number	47
Notes	This test forces the approved field to be false and then tries to read the record based on the zip lookup. A good test returns a message that no records were found

Test Name	Try to read a school that is approved based on code
Test Datatype	Boolean
Expected Datatype	Boolean
Result	Passed
File Name	/home/schoolt/public_html/application/controllers/test.php
Line Number	48
Notes	This test forces the approved field to be true and then tries to read the record based on the zip lookup. A good test returns a string that does not say that no records were found

Get Cities by State Id

Test Name	Selects cities based on the stateid
Test Datatype	Array
Expected Datatype	Boolean
Result	Passed
File Name	/home/schoolt/public_html/application/controllers/test.php
Line Number	51
Notes	This test tries to read a list of cities when a stateid is passed in

Delete School

Test Name	Delete the school record that was just created from the database
Test Datatype	Boolean
Expected Datatype	Boolean
Result	Passed
File Name	/home/schoolt/public_html/application/controllers/test.php
Line Number	54
Notes	This test tries to delete a school record from the database and validates that it was successfully deleted

Section 3: System Level Test Results

3.1: Integration Test Results

3.2: Browser Compatibility Test Results

The web browser compatibility testing verified that a selection of the SchoolTicketsOnline.com’s webpages could be viewed, without distortion or error, on a variety of popular web browsers. This testing was narrowed to the following browsers and versions:

· Internet Explorer, Version 8 and above

· Google Chrome, Version 10 and above

· Mozilla Firefox, Version 4.0 and higher

· Safari, Version 5.0 and higher (on both Mac and Windows)

A sample of the test results is provided in Figures 12 – 15.

Figure 12: Browser Compatibility Test on Internet Explorer 8

Figure 13: Browser Compatibility Test on Google Chrome 10

Figure 14: Browser Compatibility Test on Mozilla Firefox 4.0

Figure 15: Browser Compatibility Test on Safari 5.0.4

3.3: Usability Test Results

Usability testing was directed at learning how potential end users of the website viewed site layout and design. A group of 16 potential end users reviewed the website and provided feedback. Each of these participants was given three common tasks to complete on the website:

· Locate a specified school by City/State, Zip Code, or School Code.

· Locate a specified event for that school and add certain tickets to the shopping cart.

· Locate link to contact the Site Administrator.

After completing the above steps, each participant completed the Usability Test Survey, which is displayed in Figure 16.

Figure 16: Usability Test Survey

The data contained in this section fully represents the responses obtained from the completed surveys of each of the 16 participants. The results from Question #1, below, provides the number of participants that selected each rating level for each task performed.

1. How easy, or difficult, were each of these tasks to complete?

(1 = Very Easy 2 = Easy 3 = Difficult 4 = Very Difficult 5 = Unable to Complete)

Table 2

Usability Survey, Question One Results
Task	1	2	3	4	5
Locate School	13	3
Locate Correct Event	9	5	2
Add Tickets to Cart	12	4
Overall Ticket Purchasing Process	9	5	1		1
Locate Link to Contact Site Administrator	2	4	7	1	2
Overall Site Navigation	4	9	2		1

The responses gathered for Questions #2 - #5 are listed after each question below. The responses are followed by the number of participants to provide that particular piece of feedback (e.g. “Site navigation was easy and clear (10)” indicates that 10 participants made that comment).

2. How long did it take to locate the school, find the event, and add the tickets to your cart? What method did you use to locate the school (search by City/State, Zip Code, or School Code)?

· Less than 1 minute (12)

· Between 1 and 2 minutes (2)

· Greater than 2 minutes (2)

· Searched by City/State (9)

· Searched by Zip Code (2)

· Searched by School Code (2)

· Did not report search method (3)

3. What aspect of this process, if any, did you find confusing or unclear?

· Locating link to contact Site Administrator/support; multiple users suggested adding “Contact Us” link in page footer (6)

· Recommendation to have more than one email address (for administration and support) (1)

· Location of the school login and the wording on the page were confusing; starting point for those attempting to purchase tickets needs to be more clear (a user may think they need to login to purchase tickets) (1)

· Title of event does not stand out, making it difficult to locate (1)

· User is required to enter how many tickets they want to purchase, as opposed to a default number, such as one ticket, for the quantity field (1)

4. How easy, or difficult, was it to navigate the website? Were links clear and understandable? If not, which links or web pages were unclear?

· Site navigation was easy and clear (10)

· How to locate link to contact Site Administrator/support was unclear (5)

· Unclear to have school login on left and search for school on right, should be reversed; add school login to top right of header and make remainder of home page dedicated to the end user (1)

· The terminology, “Submit Query” may be confusing to some users (1)

· When logged in to school account, absence of navigation links in page footer made site more difficult to navigate (1)

· Recommendation to add event title column for customer’s event view (1)

· Recommendation to add spaces between each event (1)

· Ticket level headings did not line up when viewing an event to add tickets to cart (1)

5. Please provide any additional comments or observations from your assessment.

· Clarify layout and location of “Contact Us” information (4)

· Recommendation to add spaces between each event (1)

· Add “Search” function in header or footer so users can search by school name (1)

· Add horizontal/global navigation links to page header (1)

· Place “Search for School” on left side of home page and school login on right (1)

Section 4: Acceptance Test Results

ACCEPTANCE TEST

SchoolTicketsOnline.com

Scope and Purpose

This test will be used to verify fulfillment of each system requirement, as well as demonstrate operability of each associated system function or characteristic. The results will be used to document the project sponsor’s acceptance of the completed system. The objective of the project team is to deliver a high-quality system that meets all of the sponsor’s expectations. This test is designed to confirm completion of that objective.

Test Execution

During the final delivery of the completed system, the project team will validate fulfillment of each requirement and associated system function to the project sponsor by means of demonstrations on the live website, delivery of applicable system documentation, or other methods previously specified. The project team will be available during system delivery, through the use of web conferencing, to answer all questions that the project sponsor may have. After this initial meeting, the client advocate will finalize the system’s delivery on-site with the project sponsor, during such time each party will indicate that each requirement has been fulfilled by initialing the respective line item for each, as outlined in the Acceptance Test on the following pages.

System Requirements	Requirement fulfilled
	Project Team	Sponsor	Date
1	The website contains a webpage for each of the following: home, registration, school login, terms of service, and privacy policy.	Complete	Complete	3/30/11
2	End-users have the ability to search for school using State/City drop-down menus, Zip Code, or School Code.	Complete	Complete	3/30/11
3	From the Shopping Cart interface the end-user is routed to the payment gateway, Paypal, to complete transaction. The end-user will then be provided with the option to print a receipt for the tickets and be routed back to SchoolTicketsOnline.com.	Complete	Complete	3/30/11
4	The end-users receive e-mail confirmation on ticket purchases	Complete	Complete	3/30/11
5	The website contains an interface for backend management of school events and tickets, to be used by each school's Event Coordinator.	Complete	Complete	3/30/11
6	The website contains an interface for backend management of overall management of the site and school accounts, to be used by the website's administrator.	Complete	Complete	3/30/11
7	For system maintainability purposes, adequate documentation has been provided to the sponsor for the following items: database and web interface design, site installation, daily operation, and troubleshooting procedures.	Complete	Complete	3/30/11
8	The delivered website has been installed on a suitable web hosting provider.	Complete	Complete	3/30/11

System Requirements	Requirement fulfilled
	Project Team	Sponsor	Date
9	The Site Administrator has been provided with adequate tools for back-end database support and easy web administration, including traffic reports and manual backups.	Complete	Complete	3/30/11
10	The system supports daily and weekly backups, provided by the web hosting provider.	Complete	Complete	3/30/11
11	The website supports popular versions of the following web browsers: Internet Explorer, Google Chrome, Mozilla Firefox, and Safari (supported versions outlined in project documentation).	Complete	Complete	3/30/11
12	Upon sign-up, each Event Coordinator receives a welcome email, which contains a direct link to their school's "landing page."	Complete	Complete	3/30/11
13	E-mail links are provided for the purpose of communication (external of the website) between end-users and the Site Administrator.	Complete	Complete	3/30/11
14	Event Coordinators are able to generate reports containing information for tickets sold, by date and ticket level, and revenue numbers.	Complete	Complete	3/30/11
15	Event Coordinators can upload a school logo, set-up PayPal information, and provide text-based descriptions of the school and its events.	Complete	Complete	3/30/11
16	On-screen help is available to Event Coordinators and end-users, as well as FAQ pages for each.	Complete	Complete	3/30/11

The final project, SchoolTicketsOnline.com, has been delivered to the project sponsor. All acceptance criteria have been met, as outlined in the preceding Acceptance Test.

Outstanding items, discrepancies, or other comments pertaining to system acceptance:

( N/A )

Section 5: Defect Log

APPENDIX H

DATA DICTIONARY

Table	Field	Data Type	Size	Null	Default	Relate	Constraints	Description
sales	salesid	int	11	N				System generated unique identifier
sales	invoice	varchar	14	N				Random generated to be used at the event to validate the tickets. Each ticket will have a unique key that defines that very specific ticket (event, date and quantity). This will be used to validate tickets at the event and ensure duplicate tickets are not printed off.
sales	total	decimal	7,2	N				Sum of all sales items
sales	transaction	varchar	80	N				Transaction ID from Paypal
sales	email	varchar	80	N			Valid email address	Email of customer
sales	date	datetime		N			Must be a current date/time	Sales date/time
sales	firstname	varchar	25	N			Alpha characters, periods and spaces	First name of customer
sales	lastname	varchar	25	N			Alpha characters, periods and spaces	Last name of customer
sales	address	varchar	40				Alphanumeric characters, periods and spaces	Address of buyer from Paypal
sales	city	varchar	25				Alpha characters	City of buyer from Paypal
sales	state	varchar	25				Alpha characters	State of buyer from Paypal
sales	zip	varchar	5				Numbers	Zip of buyer from Paypal
sales	phone	varchar	12	N			Numbers, dashes, periods and parenthesis	Phone of customer
sales	validated	char	1				Y/N	Set to 'Y' once Paypal IPN returns
salesitems	salesitemid	int	11	N				System generated unique identifier of this specific ticket (event, date and quantity)
salesitems	salesid	int	11	N		fk		Foreign Key to sales record
salesitems	ticketid	int	11	N		fk		Foreign Key to ticket record
salesitems	quantity	tiny int	4	N				Number of tickets purchased
salesitems	pricelevel	char	1	N			1, 2 or 3	Price level (general, student, etc)
tickets	ticketid	int	11	N				System generated unique identifier
tickets	eventid	int	11	N		fk		Foreign Key to event
tickets	tickettitle	varchar	255	N			Alphanumeric, spaces dashes and slashes	Title for this type of ticket (Balcony seats, etc.)
tickets	ticketsavailabile	small int	6	N	0		Can be 0 (unlimited)	Number of tickets available (if blank, unlimited)
tickets	ticketssold	small int	6	N	0		Numeric	Number of tickets sold so far for this ticket type
tickets	price1	decimal	5,2	N				Price for a level 1 ticket (general, student, etc)
tickets	price2	decimal	5,2					Price for a level 2 ticket
tickets	price3	decimal	5,2					Price for a level 3 ticket
tickets	ticketdescription	text	4000	N			Cleaned for cross site scripting. HTML allowed, no javascript.	Description of this ticket
events	eventid	int	11	N				System generated
events	schoolid	int	11	N		fk		Foreign Key
events	eventname	varchar	80	N			Alpha characters, periods and spaces	Name of the event (Holiday Concert, etc)
events	eventdescription	text	4000	N			Cleaned for cross site scripting. HTML allowed, no javascript.	Description of the event
schools	schoolid	int	11	N				System generated
schools	stateid	small int	6	N		fk		Foreign Key (State of the school)
schools	activated	char	1	N			Y/N	Determins if the account has been activated by the school
schools	approved	char	1	N			Y/N	Determins if the account has been approved by the site admin
schools	schoolcode	char	9	N				System generated unique code used to link directly to the school event page
schools	schoolname	varchar	80	N			Alpha characters, periods and spaces	Name of the school (Valley View Elementary, etc)
schools	schoolcity	varchar	40	N			Alpha characters, periods and spaces	City of the school
schools	schoolzip	char	5	N			Numbers only	zip code of the school
schools	schoollogo	varchar	12					Unique system generated filename for logo
schools	paypalaccount	varchar	80	N			Valid email address	Paypal email address the school uses to collect the money
schools	schoolinfo	text	4000	N			Cleaned for cross site scripting. HTML allowed, no javascript.	Information about the school
states	stateid	small int	6	N				System generated
states	state	varchar	32	N				State name
states	stateabbrev	char	2	N				State 2 digit abbreviation
admins	adminid	small int	6	N				System generated
admins	schoolid	small int	6	N		fk		Foreign Key
admins	email	varchar	80	N			Valid email address	Email address and login for event coordinators
admins	password	char	32	N				Hashed password of event coordinator
admins	siteadmin	char	1	N			Y/N	Determins the site admin account

APPENDIX I

SAMPLE SOURCE CODE

1 <?php

 2     /*

 3      * The events() function is called to display all events for a school

 4      * The selected school id is passed in from the url as the $schoolid variable

 5      * The function validates the $schoolid and then loads the school info and events info

 6      * Finally, the function displays the header, the events template and then the footer

 7      */

 8     function events($schoolid = 0)

 9     {

10         $data = array();

11         /*

12          * Check to see if the schoolid session is valid and if not, redirect to the home page

13          */

14         $schoolid = $this->getSchoolId($schoolid); // redirects to home page if schoolid is invalid

15         $data['tickets'] = $this->session->userdata('tickets');

16         $data['schoolid'] = $schoolid;

17         /*

18          * Get the school data for the selected school ID

19          */

20         $this->load->model('Schools');

21         $data['school'] = $this->Schools->getSchool($schoolid);

22         /*

23          * Get all event data for the selected school ID

24          */

25         $this->load->model('Events');

26         $data['events'] = $this->Events->getEvents($schoolid);

27         /*

28          * Time to display the screens

29          */

30         $this->load->view('ticket_head');

31         $this->load->view('ticket_events', $data);

32         $this->load->view('ticket_foot');

33     }

34     /*

35      * The tickets() function is called to display all of the different ticket types

36      * for the selected event for a school

37      * The selected school id is passed in from the url as the $schoolid variable

38      * The selected event id is passed in from the url as the $eventid variable

39      * The function validates the $schoolid and then loads the school info, events and ticket info

40      * Finally, the function displays the header, the tickets template and then the footer

41      */

42     function tickets($schoolid, $eventid)

43     {

44         /*

45          * Check to see if the schoolid is valid and if not, redirect to the home page

46          */

47         $schoolid = $this->getSchoolId($schoolid); // redirects to home page if schoolid is invalid

48         /*

49          * Check to see if the eventid is valid and if not, redirect to the home page

50          */

51         $eventid = $this->getEventId($eventid, $schoolid); // redirects to home page if eventid is invalid

52         $data['tickets'] = $this->session->userdata('tickets');

53         $data['schoolid'] = $schoolid;

54         $data['eventid'] = $eventid;

55         /*

56          * Get all ticket data from the event

57          */

58         $this->load->model('Events');

59         $data['event'] = $this->Events->getTickets($schoolid, $eventid);

60         /*

61          * Get school data

62          */

63         $this->load->model('Schools');

64         $data['school'] = $this->Schools->getSchool($schoolid);

65         /*

66          * Time to display the screens

67          */

68         $this->load->view('ticket_head');

69         $this->load->view('ticket_tickets', $data);

70         $this->load->view('ticket_foot');

71     }

72 ?>

APPENDIX J

DIRECTORY STRUCTURE

SchoolTicketsOnline.com uses the PHP framework CodeIgniter, which requires a specific directory layout. This layout provides for the separation of the CodeIgniter framework and application-specific code, as well as web page assets (JavaScript, CSS and images). The CodeIgniter framework is installed at the root of the web root, as defined by the web host. In the event that the website is moved to a different host, the directory structure will remain the same as long as the entire directory structure is copied to the web root of the new web host. At the root of the web root is the CodeIgniter file index.php, which is the front controller for the entire application, including the school control panel and the Site Administrator Control Panel.

Also at the root is the apache configuration file .htaccess, which allows CodeIgniter to support Search Engine Friendly (SEF) Uniform Resource Locators (URL). Below the root are the common asset folders for JavaScript code (the js directory), CSS files (the CSS directory), the images folder (for images used by the website), the logos directory (for uploaded school logos), CodeIgniter's system directory (contains the framework files) and the application directory, which holds all of the custom-developed controller, model and view folders, as well as other folders supported by the framework. The directory structure and all content, including the CodeIgniter engine and the custom code, will be provided to the sponsor as a "Zipped" file at the conclusion of the project. Figure 17 is a graphical representation of the folder structure for SchoolTicketsOnline.com.

Figure 17: Directory Structure

APPENDIX K

CONFIGURATION FILES

SchoolTicketsOnline.com has several configuration files that ensure the proper functioning of the CodeIgniter framework. The CodeIgniter-specific configuration files are maintained in the /application/config directory and include the config.php file and the database.php configuration files. The config.php file sets the base URL, the index page, the character set used by the web pages and a few other customizable settings. The database.php file holds the database-specific settings, including the database host, the user and password and the database name. The only other configuration file used is the apache configuration file called .htaccess, which is found at the web root of the website. This file is configured to support SEF URLs and at the time of the first release of SchoolTicketsOnline.com is configured with the CodeIgniter defaults. All configuration files were delivered as part of the zip file package delivered to the project sponsor at the end of the project.

APPENDIX L

MEETING MINUTES

Minutes: 2/4/11

630 - 745 PM PST

Attendance: ALL

1. Collaboration tool: Group settled on Gotomeeting.com. Chris established an account (free for 30 days). Rest of the group is guests. Eric will create an account in 25 days (March 1, 2011) to relieve Chris of monthly fee.

2. Ideas / sponsor: Group contributed equal effort in sharing ideas and seeking sponsorship. Group settled on Scottsdale Insurance as sponsor, and George's idea of establishing a web front end to help facilitate ticket sales to secondary school functions (FTP, databases access control) that is supported by individual school backend and monitored by central a site owner. Third-party service providers to include PayPal.

3. Primary project roles as follows:

A. Eric / PM, Technical Writer

B. Walter / Deputy PM, Technical Writer, and Graphics

C. George / Principal Developer and Client Advocate

D. Ryan / Solutions Analyst / Developer

E. Chris / Quality Assurance / Peer Review / End User

4. Next meeting:

** 2/6/11 @ 1100 PM PST **

ACTION ITEMS

Who / Action Item / Due / Status

· Ryan / E-mail group resume / ASAP / OPEN

· George / Pre-Milestone 1 Deliverable / Feb 5, 2011 / OPEN

· Eric / Milestone 1 Draft tasking / Feb 5, 2011 / OPEN

· Eric / Draft Project Plan / Feb 6, 2011 / OPEN

Minutes: 2/6/11

1100 AM - 1205 PM PST

Attendance: ALL

1. Open forum, chance for thoughts, concerns, and complaints: None posed.

2. Group dynamics, complaints will be formally reviewed by faculty during Milestone Three. Let us encourage open dialogue now, so we do not get stressed later.

A. Everyone is continuing on to 620B.

B. Chris to manually set up each 'goto' meeting and send each invite via e-mailed link.

3. Draft Project Plan presented. Agreement made on roles, responsibly, schedules, and draft workload.

A. Need for all to provide schedule / task inputs to Project Plan ASAP, to include work plan estimates.

B. Take at look at bigger picture when budgeting time. Level of effort will be different during each milestone.

4. Clarification of project roles (writing is assumed)

A. Eric / PM, Document Control

B. Walter / Deputy PM, System Documentation, Graphics

C. George / Principle Developer and Client Advocate

D. Ryan / Solutions Analyst, Developer

E. Chris / Quality Assurance

5. Group feels thus far that no skill sets are missing for proposed project.

6. Follow a business proposal format (i.e., extreme time sensitivities) for deliverable week

A. Everyone needs to write to the Handbook. PM supplied outlines, minutes, etc., is only meant to facilitate.

B. When writing is assigned / assumed, it must be complete, polished, and with FULL reference citation.

C. Developers please supply outlines a day ahead when agreed. Otherwise, full writing is assumed.

D. Delivering assignments on time is critical to a timely turnaround, quality output.

E. Else, if significant, PM will reflect slippage via Milestone Reports.

7. Two action item lists:

A. Master Project Plan

B. Administrative via minutes

8. Walter enters draft DFD.

9. George supplies domain registration and access information.

10. Next Meeting:

** Monday, Feb 7 (Dr. Snyder / whole class) ** then

** Wednesday, Feb 9 @ 630 PM PST **

ACTION ITEMS

· Who / Action Item / Due / Status

· George / Accelerated Vision, Capabilities Statement / Feb 8, 2011 / OPEN

· Group / Review respective section of project plan and provide additional tasking therein / Feb 11, 2011 / OPEN

· Eric / Find and share common methodology on estimating work (e.g., man hours) / Feb 7, 2011 / OPEN

· Eric / Relieve Chris of Gotomeeting.com monthly fees / Mar 1, 2011 / OPEN

· Ryan / E-mail group resume / ASAP / OPEN

Minutes: 2/9/11

630 PM - 800 PM PST

Attendance: ALL

1. Open forum, chance for thoughts, concerns, and complaints: None posed. PM spoke about the risks associated with "silent consent."

2. Walked through George's vision / Group's design, sponsor agreement and expectations, Ryan's web design layout, and Walter's data flows to mentally tie these together.

3. Did not come to a full consensus on what the "system documentation" is or how it will be delivered. Ideas included a "self-documenting website" and embedded FAQs. Still some uncertainty with regard to end user needs.

4. Quick overview of submitted work plan estimates. PM observes that all members have a fair and equitable workload per information provided. Estimates will be reviewed at each Milestone.

5. As you're working your parts, take note of those "Aha! Moments" for the formal presentation later.

** Inputs due to PM via e-mail by noon Friday, Feb 11. Please expect draft of final report by noon Saturday, Feb 12. Your tracked edits due back by 4:00 pm. **

6. Reminder for Friday: We are following a business proposal format (i.e., extreme time sensitivities) this week.

A. Please use the latest Milestone One outline.

B. Please be sure to write to the Handbook (lots of detailed questions therein).

C. When writing is assigned / assumed, it must be complete, polished, and with FULL reference citation.

D. Delivering assignments on time is critical to a timely turnaround, quality output.

7. Eric Clifford traveling to East Coast on Monday, Feb 14. Not avail for Dr. Snyder chat / presentation.

8. Chris Larsen likely out soon for delivery / newborn.

9. Next Meeting:

** Monday, Feb 14 (Dr. Snyder / whole class only) ** then

** Wednesday, Feb 16 @ 630 PM PST **

ACTION ITEMS

· Who / Action Item / Due / Status

· Walter / Exhaust system documentation needs (i.e., a list and how they will be delivered) by Milestone 1 report, so an work estimate can be provided / Feb 11, 2011 / OPEN

· Group / Review respective section of project plan and provide additional tasking therein / Feb 11, 2011 / OPEN

· Group / Who will present at Monday's chat? / Feb 14, 2011 / OPEN

· Ryan / Working microphone / Feb 14, 2011 / OPEN

· Eric / Relieve Chris of Gotomeeting.com monthly fees / Mar 1, 2011 / OPEN

· George / Accelerated Vision, Capabilities Statement / Feb 8, 2011 / CLOSED

· Eric / Find and share common methodology on estimating work (e.g., man hours) / Feb 7, 2011 / CLOSED

· Ryan / E-mail group resume / ASAP / CLOSED

Minutes: 2/20/11

11:00 AM - 1230 PM PST

Attendance: ALL

1. Open forum, chance for thoughts, concerns, complaints:

A. Walter seeks clarification on communication methods, i.e., appropriate use of group chats versus one-on-one.

B. Note: Minutes from 2/16/11 not taken. Highlight: Group decides on the following as a starting point for "system documentation."

1. End user training materials

2. Code layout

3. Operations (User) Manual

4. Directory structures

5. Others still to be named

C. Functional and non-functional requirements overall architecture, design, and

implementation plan.

2. Walter to work with both sets of data flows - George's three flows in main body (Walter to write narrative) and his detailed DFD's for the Appendix.

3. George submits class diagrams and data dictionary. No modifications needed. Needs to sit down with Jeff (project sponsor) for a review and write-up this week.

4. George to clarify intent of "client agreement," which is interpreted by him as living. Eric counters that agreement should be signed early, and that some other "sign-off" document is needed at conclusion. George to decide, ultimately gets Jeff to sign.

5. Ryan submits up-dates to non-functional as well as reviews of system interfaces and prototype functionality. Group submits recommended edits. Ryan to finish and turnaround to George ASAP.

6. George and Ryan to review Chris submitted test plan dates and sync with development dates, adjusting where needed.

7. Quality Assurance

A. Chris submits draft test plan outline and technical review checklist.

B. Defect tracking will hinge on sound test plan writing, to include testing methodology and defect tracking methodology (the latter not discussed). Test plan writing will be largely academic.

C. Technical review checklist to be modified for intuitive checks only. First official peer review tentative scheduled Sunday, Feb 27, 2011.

D. There are many ways QA has been sought early and should be spoken to in write-ups (e.g., chats, minutes, etc.)

E. Change controls for doc and code will be approached and written academically; the group may very well, however, stay with e-mail except for perhaps code reviews.

8. Next Meeting:

** Wednesday, Feb 23 @ 630 PM PST **

ACTION ITEMS

· Who / Action Item / Due / Status

· George and Ryan to review test plan dates and sync with development dates so that may be included in project planning / Feb 23, 2011 / OPEN

· Walter / Exhaust system documentation needs (i.e., a list and how they will be delivered) by Milestone 1 report, so an work estimate can be provided / Feb 11, 2011 / SUSPENDED

· Group / Review respective section of project plan and provide additional tasking therein / Feb 11, 2011 / CLOSED

· Ryan / Working microphone / Feb 14, 2011 / OPEN

· Eric / Relieve Chris of Gotomeeting.com monthly fees / Mar 1, 2011 / OPEN

Minutes: 2/23/11

6:30 - 8:00 PM PST

Attendance: ALL

1. Open forum, chance for thoughts, concerns, complaints:

A. Ryan asked for more help with his writing and general direction. Makes mild complaint that group is not responsive enough. George counters with recommendation that Ryan submit better quality so feedback can be more meaningful. Eric concurs. Ryan can make design choices, and document those choices, independent of group feedback. As previously stated, many assumptions can and should be made so progress can be achieved under tight timelines. George states that database is sufficiently populated to proceed accordingly. Recommends that Ryan design / hard code off-line. PHP replacement can happen independently of most design. Ryan seems to understand way forward.

B. Ryan states concern with staying on schedule. Eric, with assistance from Chris, agrees to provide a set schedule for development and testing. Eric asks that group review submitted master schedule for development reality / feasibility. Inputs from George and Ryan are needed before Chris and Walter can firm test dates.

2. Tasking up-dates:

A. Ryan: (1) Submits non-functional requirements and system interface design. Eric submits areas of improvements (to include a follow-up e-mail). (2) Group adds "maintainability," "price," and "usability" as three requirements that can both be assumed and the group can test.

B. George: (1) On track, on-schedule. Tasking is almost entirely tied to back-end development. Work progress is assumed. (2) Review of site to-date is impressive. (3) States site should be built by Monday, Mar 7, at which point schools can be created for testing.

C. Eric: (1) On track, on schedule. (2) Milestone Report reformatted to fit Final Report format. (3) Challenged by lower producing group members. Recommendations made / thoughts should help.

D. Chris: (1) On track, on schedule. (2) Defect tracking will hinge on sound test cases, selection of open source checklists. Test cases writing will be largely academic. (3) Reviewed 'Code and Design Review Checklist. (4) Work to-date is impressive.

E. Walter: (1) Behind schedule and under performing in every area. Separate e-mail addressing concerns with writing, communication, and overall production. Serious concern expressed openly by Eric.

3. Review Up-dated master project schedule / MAJOR MILESTONES:

A. MARCH 26: Design, Code, Function and Testing of website complete (Week 8)

B. APRIL 9: System documentation, sponsor sign-off, and final report complete (Week 10)

C. APRIL 16: Presentation complete (power point, prototype) (Week 11)

4. Reviewed draft testing schedule:

A. Inputs from George and Ryan regarding needed development time are needed before Chris and Walter can firm test dates.

5. Review system functions:

A. May be worth scanning the Handbook for instances of deliverables and mapping these scans to possible metrics and/or including as part of executive summary.

6. Review / finalize system documentation:

A. Group - I think - agrees that "system documentation" is used to "run" the system and "archival" documents are submitted to "fix or enhance" the system. Confusion born from the difference within the Handbook and what we have be used to labeling these types of documents.

B. System Documents

1. Operations / User Manual

C. Archival Documents

1. Source code

2. Directory structures

3. Architecture / Engineering Diagrams

4. Configuration Files

5. FAQ and/or Help will be embedded, i.e., not considered a "document"

7. George and Ryan to review test plan dates and sync with development dates so they may be included in project planning.

Minutes: 3/2/11

6:30 - 7:30 PM PST

Attendance: ALL

1. Open forum:

A. Walter sees benefit from conducting Milestone Two presentation, getting a better appreciation of the project's size and scope.

B. Chris & Eric: Group needs to be better at backing work with references, and said references need to hold academic credibility (i.e., no Wikipedia).

C. Eric asks Ryan to seek writing assistance from NU, friend or peer.

D. Eric to group: Please do not cut and paste / recycle work from previous Milestone.

E. Eric asks Group if it wants a "team name." Group shows little interest. Eric learns from George that sponsor is not back by his organization, when inquires about use of logo.

2. Tasking up-dates:

A. George:

1. 90% of coding schedule to be complete by March 7. Anticipates some bugs and missing features.

2. Makes minor modification to database. Class diagrams up-dates forthcoming.

3. Will write and conduct unit level test cases. Will communicate results to Chris and Walter to document.

4. Will set up DEV, QA, and PROD folders in Google Docs for QA and tracking.

B. Chris:

1. Working with Walter on test cases.

2. Encourages timely communication and results sharing from George so QA can stay on schedule.

C. Water:

1. Not sure of tasking.

D. Eric identifies system interface design as behind schedule. Group to use George's design templates. George will make minor design changes as time permits. Eric opines that interface design is not as important as identification of system documentation and needed outlines. Asks Ryan to solely focus on systems documentation. Group and Ryan concur.

7. From Milestone 2 presentation / chat:

A. Dr. Snyder recommends that the Group rehearse oral presentations.

B. Goal is to have the entire project complete with two weeks left in term (i.e., April 16)

C. All items, to include faculty checklists to the reviews with one week left (i.e., April 23)

D. Group pays for three hardbound copies of the Capstone report. Total estimate is $150. $50 per copy if group member wants own copy.

8. Next Meeting:

** Sunday, March 6, 11:00 AM - 1:00 PM PST **

ACTION ITEMS

· Who / Action Item / Due / Status

· George / Clarify intent of "client agreement." / Feb 25 / OPEN

· George / Finalize requirements (e.g., reports), establish sponsor availability for reviews / March 6 / OPEN

· Eric / Submit one page overview with presentation invitees / Mar 6 / OPEN

· Walter / Draft test cases / Mar 6 / OPEN

· Ryan / System Documentation Outlines / Mar 6 / OPEN

· George / Submit up-dates to database design, class diagram, and paragraph edit (p.23) / Mar 9 / OPEN

· George and Ryan to review test plan dates and sync with development dates so they may be included in project planning / ASAP / CLOSED

· Eric / Relieve Chris of Gotomeeting.com monthly fees / Mar 1, 2011 / CLOSED

Minutes: 3/9/11

6:30 - 8:45 PM PST

Attendance: ALL

1. Open forum:

A. George out March 22 and 23, 2011.

B. Eric exhausts binding process via previous email, group does not object.

C. Group consensus on paying for higher quality printing for binding.

D. Eric to follow-up on single v. double side printing and faculty signature page.

E. Group seemingly okay with proposed presentation line-ups. George offers clarification. Primaries for final are Eric, George, and Chris. To practice this way during Milestone 4. Ryan and Walter to field questions.

F. Group agrees to save graphics in PNG or TIFF (or like) in high quality (or like).

2. Up-date from George:

A. Commitment date is set at March 13 for near completion of development.

B. Eric relieves George of any requirements analysis being conducted in parallel until Milestone Four as well as building system / archival outlines otherwise due during Milestone Three.

C. George owes (1) up-date to class diagram, (2) data dictionary, (3) intro paragraph reflecting changes, (4) signed client agreement, and (5) unit test cases / results to-date (1-3 can slip to Milestone 4 if needed).

3. Review of User Guide Outlines:

A. Ryan owes detailed outlines of both, to include screen shot place holders

6. Up-date from Chris:

A. Review of system level test cases, requirements analysis, and defect log.

B. Chris owes . . .

1. Main report QA up-dates (more important)

2. Appendix Test Plan up-dates (less important)

3. Unit test cases (George's output formatted)

4. Draft - if not working - Defect log

5. Test results outline, to include detailed tech results.

6. Optional for 3: Draft status if system tests cases.

7. Optional for 3: Draft SOVT.

8. Optional for 3: Up-date to Risks

9. Optional for 3: System Metrics

7. Conduct 'Code and Design Review

A. Eric to incorporate academic HCI into interface design narrative, ties it to technical review testing results

Minutes: 3/16/11

6:30 – 8:00 PM PST

Participation: ALL

1. Open forum - Nothing noted.

2. Eric up-date:

A. Working on an Executive Summary

B. Continuing with system interface and design edits

C. Will up-date Team Capabilities

D. Will write System metrics (few academic paragraphs)

E. Detailed Milestone 5 tasking

F. Final and exhaustive (and final) comments on deviations and identify slippage post testing

G. Researching all remaining APA formatting questions

H. Capstone binding looks to be more expensive than NU's quoted $50 per copy

3. George up-date:

A. Nearly finished with all ad hoc test results / comments

B. Plans web interface design / adjustment complete by Sat, March 19

C. Leave quickly written schools for other testing. Clean-up should happen week before demo.

4. Chris up-date:

A. Test on schedule

B. Successfully folding ad hoc test results into formal documentation

C. Looking at a couple different ways to tackle the "Evaluation of Usability Tests" requirement

5. Walter up-date:

A. Improved progress with Lesson Learned tasking

B. Conducts interviews with regarding scope, offers interesting insights

C. Will brief progress at next two chats

6. Ryan up-date:

A. User guides on schedule, confident in execution

B. Will brief progress at next two chats

7. Next Chat:

** Sunday, March 20 at 11:00 AM PST **

Minutes: 3/27/11

Participation: ALL

** All below are absolute deadlines. If you cannot meet, please let [the Progam Manager] know ASAP.**

For all:

A. Review and comment on Walter's Lessons Learned to Eric by Saturday, April 2.

B. Printing (and total) cost estimates in separate e-mail.

For George:

A. Schedule Jeff for our Wednesday (3/30) chat (Eric will include Jeff in GoTo e-mail invite).

B. Need to finalize ASAP any last minute design adjustments per Chris' user feedback.

C. Coordinate with Chris to get user acceptance signatures, mail to Eric.

D. Up-dates to Appendix I: Sample Software Code to Eric by Sunday, April 3.

E. Milestone 4 read-through and edits by Sunday, April 3.

F. Verify and track change edits to both user guides when Ryan is done.

For Chris:

A. Lead Acceptance test with sponsor, Wednesday, March 30.

B. Acceptance Test /results to Eric by Sunday, April 3.

C. Defect Report to Eric by Sunday, April 3.

D. Final Usability Report to Eric by Sunday, April 3.

For Ryan:

A. Best and final draft of User Guides to group by Wednesday, March 30.

For Walter:

A. Project History and Lessons Learned, per Handbook, to Eric by Saturday, April 2.

APPENDIX M

SCHOOL EVENT COORDINATOR USER GUIDE

Table of Contents

Purpose ……………………………………………………………………………. 2

Web Browser Requirements ……………………………………………………… 2

Seeking Help ……………………………………………………………………… 2

Log in …………………………………………………………………………….. 3

Create a New Event ………………………………………………………………. 4

Add and Activate a Ticket Type ……..…………………………………………… 6

View an Event …………………………………………………………………….. 8

Edit an Event ……………………………………………………………………… 9

Delete an Event …………………………………………………………………… 10

Configure Account ……………………………………………………………….. 11

Generate a Report of Tickets Sold ……………………………………………….. 12

Generate a Report of Revenue …………………………………………………… 13

Upload a Logo ……………………………………………………………………. 14

Change Password …………………………………………………………………. 15

Setup PayPal ………………………………………………………………………. 16

Print Sold Event Tickets …………………………………………………………... 17

Overall Approach …………………………………………………………………. 18

Purpose

This guide was developed to aid School Event Coordinators with creating, modifying, and deleting school events and tickets on SchoolTicketsOnline.com. This guide also explains how to generate reports, upload a school logo, change a password, and setup PayPal for ticket payments.

Web Browser Requirements

At a minimum, Microsoft Internet Explorer 7, Google Chrome 9.0, Mozilla Firefox 3.0, Safari 2.0, or newer version of these browsers and the ability to run JavaScript and support cookies.

Seeking Help

1. Open a web browser and go to http://schoolticketsonline.com/index.php/school/login or select “Home.”

2. Click “FAQ.”

Page 2

Log in

1. Open a web browser and go to http://schoolticketsonline.com/index.php/school/login.

2. Log into the School Control Panel via the interface as shown in Figure 1. Use the e-mail address and password provided during registration.

Note: Pre-approval required. See “Overall Approach” on Page 18.

Figure 1

Page 3

Create a New Event

1. Log-in as a pre-approved School Event Coordinator.

2. Click “Add an Event” as shown in Figure 2.

Figure 2

3. Enter the school’s event information as shown in Figure 3, to include the event name, its location, and a description. Also indicate the event date, the date your school would like to stop selling tickets, price level(s), and the maximum number of tickets to be made available for sale.

Figure 3

Page 4

4. Click “Submit.”

5. The new event will display in the School Control Panel along with a new “ID” as shown in Figure 4.

6. See “Add and Activate a Ticket Type” to complete detailed ticket information and activate the event.

Figure 4

Page 5

Add and Activate a Ticket Type

1. Create a New Event.

2. Click “Add Tickets” as shown in Figure 5.

Figure 5

3. Click “Add a Ticket Type” as shown in Figure 6.

Figure 6

4. Enter all ticket information as shown in Figure 7, to include a title, description, total available for purchase, the price for “General Admission” as well as separate price levels for “Students” and “Seniors” (latter two are optional).

Page 6

Figure 7

5. By default, an event is not active until the “Toggle” link displays

“Yes” as shown in Figure 8. Click “Toggle” when ready to advertise tickets to the public via the Home Page of SchoolTicketsOnline.com.

Figure 8

Page 7

View an Event

1. Open a web browser and go to http://schoolticketsonline.com/index.php/school/login or select “Home.”

2. Click on any event via “View Tickets” to view an event as shown in Figure 9.

Note: This link is for editing the ticket type, not to edit an event.

Figure 9

Page 8

Edit an Event

1. View an Event.

2. Click “Edit” under the Action column as shown in Figure 10.

Figure 10

3. Edit “Ticket Information” as shown in Figure 11.

Figure 11

4. Click “Submit.”

Page 9

Delete an Event

1. Open a web browser and go to http://schoolticketsonline.com/index.php/school/login or select “Home.”

2. Find the event and click “Delete” as shown in Figure 12.

Figure 12

3. Click “OK” when prompted as shown in Figure 13.

Figure 13

Page 10

Configure an Account

1. Open a web browser and go to http://schoolticketsonline.com/index.php/school/login or select “Home.”

2. To modify school information (such as its name; city, state, and zip; a description; and/or the corresponding PayPal Account) click “Configure Account.”

3. Up-date or add the information in the fields of the display as shown in Figure 14.

4. Click “Submit.”

Figure 14

Page 11

Generate a Report of Tickets Sold

1. Open a web browser and go to http://schoolticketsonline.com/index.php/school/login or select “Home.”

2. Click “Report” as shown in Figure 15.

Figure 15

3. Report of “Tickets Sold” as shown in Figure 16 (an example).

Figure 16

Page 12

Generate a Report of Revenue

1. Open a web browser and go to http://schoolticketsonline.com/index.php/school/login or select “Home.”

2. Click “Report” as shown in Figure 17.

Figure 17

3. Report of “Revenue” as shown in Figure 18 (an example).

Figure 18

Page 13

Upload a Logo

1. Open a web browser and go to http://schoolticketsonline.com/index.php/school/login or select “Home.”

2. Click “Upload Logo” as shown in Figure 19.

3. Browse for logo (JPEG, PNG or GIF only).

4. Click “Submit.”

Figure 19

Page 14

Change Password

1. Open a web browser and go to http://schoolticketsonline.com/index.php/school/login or select “Home.”

2. Click “Change Password” as shown in Figure 20.

3. Enter New Password.

Note: SchoolTicketsOnline.com does not technically impose password restrictions or enforce minimum standards. It is recommended, however, that passwords include a combination of numbers, symbols, lower and/or uppercase characters.

4. Renter New Password.

Note: The new password will take effect at next login.

Figure 20

Page 15

Setup PayPal

SchoolTicketsOnline.com is designed to work with PayPal as its preferred third-party payment gateway. To receive tickets payment, School Event Coordinators are required to go to http://www.paypal.com to setup a PayPal account. See Figure 21. This user guide does not detail these processes.

Figure 21

Page 16

Print Sold Event Tickets

1. Open a web browser and go to http://schoolticketsonline.com/index.php/school/login or select “Home.”

2. Click “Print” as shown in Figure 22.

Figure 22

3. Figure 23 as shown below is an example of a printed report.

Figure 23

Page 17

Overall Approach

· Visit the Home Page at http://www.schoolticketsonline.com to learn about the ticket broker service being offered to public schools – free of charge.

Figure 24

· Click on “Sign up now” on the Home Page as shown in Figure 24 and fill-out the school’s information including the email address that is associated with an existing PayPal account.

· The Site Administrator activates and approves the initial request to create a school record and ID, which is displayed on the Home Page as a search result by school by name, zip code, and/or School ID. See “User Guide for Site Administrator” for more information.

· Open a web browser and go to http://schoolticketsonline.com/index.php/school/login and log in to the School Control Panel with the e-mail address and password provided during registration.

· Create a new event, add a ticket type(s) to the event, and active the tickets/event.

· School Event Coordinators can take several actions such as view tickets, edit an event, generate a report, print tickets sold, and delete an event.

Page 18

· The ticket purchasers select an event; enter a quantity of tickets, ticket type, and then click “Checkout” to begin the payment process. This leads the user to PayPal to make the purchase and print the tickets. The ticket purchaser is required to have a PayPal account.

· School Event Coordinators check on the number of tickets sold, generates or prints reports, and ensures payments are made.

Page 19

SchoolTicketsOnline.com User Guide for School Event Coordinators

2011

APPENDIX N

SITE ADMINISTRATOR USER GUIDE

Table of Contents

Purpose …………………………………………………………………………… 2

Web Browser Requirements ……………………………………………………… 2

Log in …………………………………………………………………………….. 3

Activate a School …………………………………………………………………. 4

Delete a School …………………………………………………………………… 5

Disable a School ………………………………………………………………….. 6

Full Backup of Site ………………………………………………………………. 7

Partial Backup of Home Directory ……………………………………………….. 9

Backup of MySQL Databases …………………………………………….……… 12

Restore the Home Directory ………………………………………………. ……... 14

Restore MySQL Databases ……………………………………………………….. 16

Purpose

This guide was developed to aid the Site Administrator with activating, deleting, and disabling schools. It also explains how to make a full back up of the site, which includes all source code and databases, as well as conduct partial backups of the Home Directory and MySQL Databases and restore each.

Web Browser Requirements

At a minimum, Microsoft Internet Explorer 7, Google Chrome 9.0, Mozilla Firefox

3.0, Safari 2.0, or newer version of these browsers and the ability to run JavaScript

and support cookies.

Page 2

Log in

1. Open a web browser and go to http://schoolticketsonline.com/index.php/admin.

2. Log in to the Site Administrator Control Panel at the interface as shown in Figure 1.

3. Use an e-mail address and password.

Figure 1

Page 3

Activate a School

1. A school account can be manually activated by the Site Administrator or an automated activation will occur when the School Event Coordinator selects the “Activation Code” link in the welcome e-mail received after initial sign-up.

2. Log-in as the Site Administrator.

4. By default, a school is not active until the “Toggle” link displays “Yes” under the Active column as shown in Figure 2.

Note: Both the “Active” and “Approved” column must be set to “Yes” in order for the school to be searchable to the public.

5. Click “Toggle” when ready to make the school searchable by the general public via the Home Page of SchoolTicketsOnline.com.

Figure 2

Page 4

Delete a School

1. Log-in as the Site Administrator.

2. Find the school listed on the Site Administrator Control Panel as shown in Figure 3.

3. Click “Delete.”

Figure 3

Page 5

Disable a School

1. By default, a school is not active until the “Toggle” link displays “Yes” under the Active column as shown in Figure 4.

Figure 4

2. If the school is active, click “Toggle” when ready to disable the school. “No” will display. The school will no longer be searchable by the general public via the Home Page of SchoolTicketsOnline.com.

Page 6

Full Backup of Site

1. Go to http://alturl.com/q7kbu.

2. Log in and click on the “Backup Wizard” icon as shown in Figure 5.

Figure 5

Figure 6

3. Click “Backup” as shown in Figure 6.

4. The main backup screen will display as shown in Figure 7.

Page 7

Figure 7

5. Click “Full Backup” and enter the registered email address to receive email notification upon completion of the full backup.

6. Leave the rest as default and click “Generate Backup” to start the full back up as shown in Figure 8.

Figure 8

Page 8

Partial Backup of Home Directory

1. Go to http://alturl.com/q7kbu.

2. Log in and click on the “Backup Wizard” icon as shown in Figure 9.

Figure 9

3. The “Backup/Restore” screen will display as shown in Figure 10.

Figure 10

4. Click “Backup.”

5. The main backup screen will display as shown in Figure 11.

Page 9

Figure 11

6. Click “Home Directory” as shown in Figure 12.

Figure 12

7. Click “Save to Disk” then “OK” to save the partial backup of the Home Directory. See Figure 13.

Page 10

Figure 13

Page 11

Backup of MySQL Databases

1. Follow steps 1 – 5 in “Partial Back up of Home Directory.”

2. Click on the “MySQL Databases” as shown in Figure 14.

Figure 14

3. Click on the link “school_tickets” to back up the MySQL databases as shown in Figure 15.

Figure 15

4. In the pop-up window, choose “Save to Disk” then click “OK” as shown in Figure 16.

Note: This will back up the database file on schoolticketsonline.com. The file will be saved under the filename “school_tickets.sql.gz”.

Page 12

Figure 16

Page 13

Restore the Home Directory

1. Log in to http://alturl.com/9by2m.

2. Log in and click on the “Backup Wizard” icon as shown in Figure 17.

Figure 17

3. The “Backup/Restore” screen will display as shown in Figure 18.

Figure 18

4. Click “Restore.”

5. Click on the “Home Directory” link as shown in Figure 19.

Page 14

Figure 19

6. From the pop-up window, click “Browse” to locate and select the backup file

as shown in Figure 20.

7. Click “Upload” to start the restoration of “Home Directory” back to SchoolTicketsOnline.com.

Figure 20

Page 15

Restore MySQL Databases

1. Follow steps 1 – 4 in “Restore the Home Directory.”

2. Click “MySQL Database” as shown in Figure 21.

Figure 21

3. Click “Browse” as shown in Figure 22.

4. Find and select the backup file “school_tickets.sql.”

5. Click “Upload” to start the restoration of the MySQL databases as shown in Figure 22.

Figure 22

SchoolTicketsOnline.com User Guide for Site Administrator

2011

Page 16

APPENDIX O

FACULTY PRESENTATION