Project Plan Rev. 0.1 Page 2

Total Page:16

File Type:pdf, Size:1020Kb

Project Plan Rev. 0.1 Page 2

School of Engineering Phone 503 943 7314 5000 N. Willamette Blvd. Fax 503 943 7316 University of Portland Portland, OR 97203-5798

Final Report

Project Golden Spruce: Freshman Engineering Database for the University of Portland

Contributors:

Jeff Keagbine

Tim Meyer

Spengo Rogers

Kris Slavenski

Name Date Name Date Dr. Ward Marcos Ortiz Dr. VanDeGrift

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 2 PROJECT GOLDEN SPRUCE

Revision History

Rev. Date Author Reason for Changes 0.9 03/27/10 Team Golden Spruce Initial draft

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 3 PROJECT GOLDEN SPRUCE

Acknowledgments

We want to thank our advisors Dr. Ward and Dr. VanDeGrift for guiding us throughout the entire year and also for their significant contribution in finding any potential issues in our design and implementation. We want thank our industry representative, Marcos Ortiz, for finding numerous issues in our design that we otherwise would have missed. Their thorough analysis throughout the design process enabled our project to go much smoother and be much better than it would have otherwise. Finally, we would like to thank everyone who participated in the stress testing of the project.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 4 PROJECT GOLDEN SPRUCE

Table of Contents

List of Figures

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 5 PROJECT GOLDEN SPRUCE

List of Tables

Chapter 1 Summary

This final report is being presented to give the reader an insight into the processes and accomplishments of team Golden Spruce since the completion of design document and up to the presentation of the project on Founders Day.

The project involved the design and implementation of FEDUP 2.0, a website that manages the information used each year for the Freshman Design Competition at the University of Portland, such as teams of students, orders for parts and an inventory of those parts. The FEDUP 2.0 final product is able manage users in three distinct user groups, a collection of teams and an inventory system of parts used during the competition. This product is complete with full login/logout, password, and security features for each user group and the entire site as a whole.

The rest of this document outlines this product in much greater detail, including the development process from which it was created, its functionality and how to use it.

Next is an introduction to the specific sections of this Final Report document.

Chapter 2 Introduction

This document provides a detailed report of Golden Spruce’s project FEDUP 2.0. The final report is written for future senior design teams who will be extending our project, and to anyone else who is interested in how we designed, implemented and tested FEDUP. Anyone who reads this final report will understand how we implemented our project and how our implementation differed from our design. The reader will be able to use this information to either improve the process we used to create FEDUP 2.0, or to improve FEDUP 2.0 itself.

Following this introduction is the background section which contains information about the Freshmen Design Competition and FEDUP history.

Following the background is information about the architecture for FEDUP 2.0. A figure of our data centered architecture is presented and the reason we chose this architecture is explained in this section. In this section we describe the process Team Golden Spruce used to develop project FEDUP 2.0 and how another team could duplicate or enhance the project.

Following the architecture section is the Results section with information about each component of the FEDUP 2.0 project. The database is fully defined in this section and all of our screens are displayed with a description for each one. The Results section then describes how implementation differed from

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 6 PROJECT GOLDEN SPRUCE the plan and describes how Team Golden Spruce dealt with various issues that came up during the development process.

The conclusion will highlight the important issues of the development process and provide possibilities for improving this process.

Chapter 3 Background

The University of Portland Freshman Design Competition is a yearly competition which challenges freshmen to: … conceive, design, build, and demonstrate a device to accomplish a specific task. The project includes aspects of limited resources, speed, cost, and effectiveness. At the end of the competition, awards are made for highest score, lowest cost per score, and highest [score] per time, as well as an award for the most ingeniously designed device (University of Portland, 2007: http://engineering.up.edu/default.aspx?cid=4209&pid=82).

Each year, teams in the Freshmen Design Competition are challenged to create a device to accomplish a given task. For example, in 2006 teams were challenged to build a device that could shoot wiffle balls into a basketball hoop. The more wiffle balls they made through the hoop, the higher their score in the competition. Teams are given an unlimited amount of “funny money” (which from here out will just be called money) with which they may buy parts to build their device. Parts have a monetary value and a limit on how many can be purchased, e.g. a team may only purchase two motors.

To purchase parts, a team must fill out an order form and take it to a tool room worker to process. The tool room worker validates that the team is allowed to buy the parts (e.g. checking that the team has not already purchased two motors). After the tool room worker has validated that the team is allowed to buy the parts on the order form, the tool room worker sells the parts to the team, which consists of filling the order and giving the team an invoice of the transaction.

At the end of the competition, awards are given to teams with the highest score, highest score per time, and lowest cost per score. After the competition is over, teams must return the parts that are required to be returned. If a team does not return a part that is required to be returned, the members of the team receive a grade of F in the course.

Adapted from Team Goldeneye FS v 1.1, Senior Design Project, 2007

Chapter 4 Architecture

This section describes the overall design of FEDUP 2.0. A figure of our data centered architecture is presented and the reason we chose this architecture is explained in this section. In this section we

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 7 PROJECT GOLDEN SPRUCE describe the process Team Golden Spruce used to develop project FEDUP 2.0 and how another team could duplicate or enhance the project. Detailed descriptions of each screen and stored procedure used can be found in the appendix.

Flowcharts

The following flow diagrams describe what pages the different users will see and how they can get to them. First they will be presented with the login screen followed by a main menu. The main menu consists of buttons that lead to the various pages with the functionality each user will need. The solid lined boxes represent high priority functionality to be added and the dashed lined boxes represent additional functionality that will be added as time permits. The numbers in each box represent the requirement number from the Functional Specification for that specific functionality. (2)

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 8 PROJECT GOLDEN SPRUCE

Figure 1: Administrator flow diagram

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 9 PROJECT GOLDEN SPRUCE

Figure 2: Student flow diagram

Figure 3: Employee flow diagram

Figure 4: Ordering and filling diagram below shows the process for students submitting an order and how that order is filled by an administrator or employee. Dashed lines indicate secondary and tertiary requirements while solid lines indicate primary requirements. In the event that the secondary and tertiary requirements are not implemented order processing will be handled without any team/review process or email capabilities.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 10 PROJECT GOLDEN SPRUCE

Figure 4: Ordering and filling diagram

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 11 PROJECT GOLDEN SPRUCE

Figure 5: Request new password diagram below shows the process for a user requesting a new password. Dashed lines indicate secondary and tertiary requirements while solid lines indicate primary requirements.

Figure 5: Request new password diagram

Database

The database is the central repository of information relating to teams, invoices, parts, employees, and professors. Each table has a primary key (PK). The primary keys for the following tables represent a unique way to look up and identify information stored in the individual tables. Following this table is detailed information for each table and each field. Not shown in this table are some of the automatically generated tables used by ASP.net. These tables were added to our design in order to provide login functionality and security measures. The two most important tables added store the user and password information for users that can login to the site and the membership and role information for each user which define what access level each user has on the site. Due to this design change the Password field was removed from the Person table. These additional tables are linked to the original database, shown below, through the Email key and are essential to the functionality of FEDUP 2.0.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 12 PROJECT GOLDEN SPRUCE

Figure 6: Database Design

Format: - [Table_Name]: Description (#of fields) N.) Field_Name – Type (max length, if applicable): Description Example of column name: Column_Name Example of table name: [Table_Name]

 [Part]: This table contains information pertaining to a part (10 fields).

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 13 PROJECT GOLDEN SPRUCE

1 .) Part_Num – Integer (3) (Primary Key): This is the number that uniquely identifies a part. The current numbering scheme the tool room employs has all parts having a 3 digit number. 2 .) Part_Name – VarChar(30): This is the name of a part, like “Wheel, 4 inch.” 3 .) Price – Currency: This is the price of the part per unit of sale. 4 .) Amt_Purchaseable – Integer: This is the number of a said part that can be purchased. For example, a motor only has an Amt_Purchaseable of 1, meaning only 1 motor can be purchased. 5 .) Unit_of_Sale – VarChar (15): This contains the information about how parts are sold; e.g. for a wheel it would be “each”, for a dowel it may be “5 inches”, and for a weight it may be “2 ounces”. 6 .) Description – VarChar (100): This contains a description of a part. 7 .) Returnable – Bit: This represents whether a part can be returned or not. 8 .) Recheck – Bit: This represents whether a part has to be returned at the end of the semester. 9 .) Amt_In_Stock - Integer: This holds the information for the amount of this type of part that is in inventory.

 [Class]: This table contains information about who teaches a class section (2 fields). 1 .) Section – Char (1) (Primary Key): This char uniquely identifies a class. There are multiple classes of EGR 110 – the section, which is simply “A”, “B”, “C”, …, “Z”, identifies the class of EGR 110. 2 .) Email (of Professor) – VarChar (30): This is the email of the professor who is teaching a section of EGR 110.

 [Team]: This table contains information about a team (4 fields). 1 .) Section – Char (1) (Part of Primary Key): This is Section from [Class]. It is the section of EGR 110 which this team comes from. 2 .) Team_Num – Integer (2) (Part of Primary Key): This is the number that uniquely identifies a team in a particular section of EGR 110. 3 .) Channel – VarChar (10): This is the channel which a team is supposed to use with their remote control. 4 .) Locker_Num – VarChar (10): This is the number of the locker that the team has been assigned to store their EGR 110 related supplies and their tools.

 [Person]: This table contains information about a person (5 fields). 1 .) Email – VarChar (30) (Primary Key): A person’s UP email address. 2 .) Name – VarChar (30): A person’s name. 3 .) Phone_Num – VarChar (14): A phone number by which a person can be contacted. 4 .) Security_Group – VarChar (10): The security group this person belongs to; e.g., “Employee”, “Professor”, “Student”.

 [Professor]: A professor is a type of person. This table contains a professor’s email address. 1 .) Email – VarChar (30) (Primary Key): A person’s UP email address.

 [Student]: A student is a type of person. This table contains all information a person has plus exclusive information about students (2 Fields). 1 .) Section – Char (1): Section from [Class]. The section of EGR 110 to which this student belongs. 2 .) Team_Num – Integer: The team number of the team to which this student belongs.

 [Employee]: An employee is a type of person. This table contains exclusive information about employees (1 Field). 1 .) Is_Active – Bit: This denotes whether this employee is an active employee.

 [Invoice_Hdr]: This table contains invoices belonging to teams (5 fields)

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 14 PROJECT GOLDEN SPRUCE

1 .) Invoice_Num – Integer (Primary Key): This is the number that uniquely identifies an invoice. It will be generated when an invoice is created. 2 .) Section – Char (1): This is Section from [Team]. It is the section of the team that this invoice belongs to. 3 .) Team_Num – Integer(2): This is Team_Num from [Team]. It is the team number of the team that this invoice belongs to. 4 .) Date – DateTime: The date this invoice was created. 5 .) Email – VarChar(30) (the Email of the Employee who fills the order): This is the email of the employee that fills the invoice. 6 .) Is_Open – Char(1): Contains the information for whether the order is open or not.

 [Invoice_Detail]: This table contains information about what parts are in an invoice (4 fields). 1 .) Invoice_Num – Integer (Part of Primary Key): This is Invoice_Num from table Invoice_Hdr. 2 .) Part_Num – Integer (Part of Primary Key): This is Part_Num from table Part. 3 .) Quantity – Integer: This specifies the amount of a given part that was purchased, e.g., “4 tires were purchased.” 4 .) Cost – Currency: This is the cost of this Invoice_Detail. For example, if this Invoice_Detail was of 4 wheels, and the price of each wheel is $50, then the cost would be $200.

 [Std_Invoice_Detail]: This table contains information about what parts form the standard invoice (2 fields). 1 .) Std_Part_Num – Integer (Part of Primary Key): This is the number that identifies a standard order part. It is identical to the Part_Num found in [Parts]. For example, if a Worm- Gear Motor is part of a standard order, then the Part_Num for the Worm-Gear Motor is here. 2 .) Quantity – Integer: This is the amount of this part that is in the standard order. For example, if there are two Worm-Gear Motors in the standard order, than Quantity would be 2.

The estimated size of the database is as follows:  Estimated number of students: approximately 200  Estimated number of professors: approximately 8 (at 35 students per professor)  Estimated number of teams: approximately 60 (at 3-4 students per team)  Estimated number of employees: approximately 10  Estimated number of parts: approximately 70  Estimated number of standard order parts: approximately 25  Estimated number of invoices: approximately 330 (at 5 invoices per team)

Limitations of Database:  The database can only support up to 26 class sections  The database can only support up to 99 teams per class section  The database can only support up to 999 parts. This is not reflected in the current screen mockups but the final project will have 3-digit part numbers.

Security

In order to maintain a secure system we needed to ensure that passwords were kept safe at all times and that unauthorized users could not access the system. In order to ensure password security, passwords are kept encrypted at all times and will be handled only by the system so they never need to be unencrypted. In order to prevent unauthorized access we used session ids. When a user logs in a session is started and a session id is created. Every time the user wants to perform an action the session must be confirmed. We used ASP.NET user roles to restrict which pages a user can access. If the browser is inactive for ten minutes the session expires and the session id is no longer valid so the

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 15 PROJECT GOLDEN SPRUCE session cannot be confirmed. When a user logs out the session is closed. We use parameterized SQL statements to protect from SQL injection.

Chapter 5 Results

Features

Table 1 below is an overview of the requirements specified by FEDUP 2.0 clients. Each requirement is rated on a priority scale from ‘1’ to ‘3’. A priority of ‘1’ means that the requirement is a primary requirement for this project and will be implemented. A priority of ‘2’ means the requirement is secondary and will be implemented if all primary requirements are completed and time permits. A priority of ‘3’ is tertiary and will only be implemented if all primary and secondary requirements are implemented and time permits. The implemented column shows whether that particular functionality was implemented in the FEDUP 2.0 final product. The ID # on the right helps the requirement to be easily tracked and referenced throughout this and other documents and discussions. Each requirement is described in greater detail in the Golden Spruce’s Function Specification document.

Table 1: Requirements Overview

ID # Priority Implemented Non-Functional Requirements 000 FEDUP 2.0 can be accessed over the internet 1 Yes 001 FEDUP 2.0 is protected from SQL injections 1 Yes FEDUP 2.0 has four distinct user classes with unique 1 Yes 002 rights 003 Has a response time of under 4 seconds 1 Yes 004 FEDUP 2.0 can accommodate 30 users at one time 1 Yes Update FEDUP 1.0 functionality to integrate with 1 Yes 005 FEDUP 2.0

Administrator Functions 100 User interface for database management by the admin 1 Yes 101 Edit teams 1 Yes 102 Edit employees 1 Yes 103 Edit student 1 Yes 104 Edit parts 1 Yes 105 Order processing 1 Yes 106 View students 1 Yes 107 View employees 1 Yes

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 16 PROJECT GOLDEN SPRUCE

108 Edit standard order 2 No 109 Edit faculty 2 No 11 0 Create Database from Spreadsheet 2 No 111 View faculty 2 No 112 Administrator print team records 2 No 113 Add competition results 3 No 114 Upload pictures for parts 3 No

Employee Functions 200 Order processing 1 Yes 201 Edit parts 2 Yes 202 Return parts 2 Yes 203 View employees 2 Yes

Faculty Functions 300 Edit students 2 No 301 Edit teams 2 No 302 Nightly email updates 3 No 303 Add competition results 3 No 304 Professor home page 3 No 305 Print team records 3 No

Students Functions 400 Online ordering with checkout 1 Yes

All Users Functions 500 Logging in for each user 1 Yes 501 View teams 1 Yes 502 Logging out 1 Yes 503 Change password 2 Yes 504 Request new password 2 Yes 505 View pictures for parts 2 No 506 Visual confirmation on submissions 2 No 507 View team expenses and invoices 2 Yes 508 Sort by columns 3 No 509 View competition results 3 No 510 Users follow links to EGR110 website 3 No

Screens

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 17 PROJECT GOLDEN SPRUCE

Below are a few of the screens from the FEDUP 2.0 website. Some of these screens were changed from what the original design document specified. In these cases the original design screen is also shown and the reason behind the change is specified. All original design screens can be found in Golden Spruce’s design document.

Screens are upcoming. Tim was doing the screens but he found out he has strep today, the screens should be available to add tomorrow.

Process

The process of creating FEDUP 2.0 did not perfectly follow the path that had been planned. This section will focus on the difficulties and changes that were encountered and required to finish FEDUP 2.0.

Team Golden Spruce’s assumptions were minimal. We assumed that the host server for FEDUP 2.0 will have the .NET 2.0 Framework, that it will be able to handle the load of running FEDUP 2.0 for multiple users and that any version changes to SQL server or .NET Framework will be backwards compatible. Our assumptions have held true as FEDUP 2.0 will be hosted by the Information Services Department at the University of Portland.

Team Golden Spruce decided to revise their milestone table at the beginning of the second phase of the project to improve the overall efficiency and development process of FEDUP 2.0. These changes included moving the creation of the login functionality up to the beginning of the milestone list for the second phase and then completing all the administrator functionality second. This was done because the login and security pervades the whole application and the administrator has the most functionality so almost all of the rest of the functionality is a modification of what the administrator can do. Next on the list was completing the student and employee functionality, except for ordering, and lastly once all the users were created we added the ordering functionality. We ran into many problems with the login functionality which caused us to finish that milestone late and put a general burden on the rest of the project as it made it hard to test everything together. However, we were still able to finish most of the other milestones on time and we used the troubleshooting time built in to our project to make sure we did not fall too far behind.

Our biggest risk that affected the team was one we were prepared for so it did not cause too big of a problem. This risk was that we lost a lot of the work capacity of one member of the team because his son was born in the middle of our project. However, we had planned for this and design our schedule so that the project would not be negatively by this. This planning involved having the team member begin working during Christmas break. Their prime focus was getting the code to run on the web and understanding what needed to be done to do so. This early work proved critical to the project as a crippling issue was found early so that when the rest of the team began their work, they started in the correct way. The issue was a structural problem with the FEDUP database. To host FEDUP 2.0 online, we needed to take advantage of ASP.net and its login and security

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 18 PROJECT GOLDEN SPRUCE

functionality. However FEDUP had made no use of ASP.net and had included extra tables to handle what ASP.net handles more securely and efficiently. Not only was FEDUP not set up to go online, but it had been set up in a manner that made it more difficult to put online because we had to work with the additional tables. Knowing this information early was vital to the success of the project. Notes involving issues with hosting online are included in the appendix under troubleshooting.

During the project we were required to update our budget to get resource materials (books) to help complete the project. This was the only resource or budget issue that was different than predicted. The facilities and equipment we had available to us were all adequate.

Testing

Testing for FEDUP 2.0 was done in three stages. The first stage was the testing that team Golden Spruce performed continually during the entire project but especially during the troubleshooting, debugging and white box testing milestones. These tests included each team member systematically going through each page of the website to test every feature and compile lists of what was and was not working and what errors were being reported.

The second stage of testing was a client test. This test involved bringing in the two main clients from whom the requirements for the project were received. For this test Golden Spruce had a number of tasks for the two clients to perform, while the team observed and took notes on what the clients were doing and any problems they ran into. Then the team worked with the clients to go through each page of the website and take notes on what they would like to be improved. This proved very helpful as there were some minor issues that needed to be changed such as fixing links, adding navigational buttons and creating more user friendly messages.

The last stage of testing was a stress test session. This test involved bringing in a group of students to act as users all at the same time. Each user was given a set of tasks to complete that testing each part of the website. The goal of this test was to find out how the website handled and reacted under the stress of many users simultaneously accessing pages and accessing and modifying the database.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 19 PROJECT GOLDEN SPRUCE

User Documentation

The following are user guides for each of the three users groups that can access and use FEDUP 2.0. These user guides will explain to each type of user how to use the site and all its functionality.

Administrator User Guide

This guide assumes that the user has a valid administrator account and has logged into the FEDUP 2.0 website and is on the Administrator Main Menu page. Faculty users will be given administrator accounts.

Employee

Add Employee – To add an employee the user clicks on the Employees button. A list of all the employees will be displayed. The user then clicks on the Add Employee button. A screen is displayed where the user can add all the information for the new employee. The user then clicks the Submit button. The employee is created and the user is brought back to the View Employees page.

Edit Employee – To edit an employee the user clicks on the Employees button. A list of all the employees will be displayed. The user then clicks on the Edit/View button beside the name of the employee they wish to edit. A screen is displayed where the user can edit the information for the employee. The user then clicks the Submit button. The employee’s information is edited and the user is brought back to the View Employees page.

Remove Employee – To remove an employee the user clicks on the Employees button. A list of all the employees will be displayed. The user then clicks on the Remove button beside the name of the employee they wish to remove. A screen is displayed where the user confirms that they want to remove the employee. The user then clicks the Remove button. The employee’s Is_Active information is set to false to represent that they do not work in the tool room at this time.

Team

Add Team – To add a team the user clicks on the Teams and Students button. A list of all the teams will be displayed. The user then clicks on the Add Team button. A screen is displayed where the user can add all the information for the new team. The user then clicks the Submit button. The team is created and the user is brought back to the Teams and Students page.

Remove Team – To remove a team the user clicks on the Teams and Students button. A list of all the teams will be displayed. The user then clicks on the Remove button beside the team they wish to remove. A screen is displayed where the user confirms that they want to remove the team. The user then clicks the Remove button.

Student

Notes: A student must be added to a team that already exists. The name and email of a student are required; the phone number should be filled out for the team contact.

Add Student – To add a student the user clicks on the Teams and Students button. A list of all the teams will be displayed. The user then clicks on the View/Edit/Add All Students button. A list of all the students is displayed. The user clicks the Add Student button. A screen is displayed where the user

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 20 PROJECT GOLDEN SPRUCE can add all the information for the new student. The user then clicks the Submit button. The student is created and the user is brought back to the View/Edit/Add All Students page.

Edit Student – To edit a student the user clicks on the Teams and Students button. A list of all the teams will be displayed. The user then clicks on the View/Edit All Students button. A list of all the students is displayed. The user clicks the View/Edit button next to the student they want to edit. A screen is displayed where the user can edit the information for the student. The user then clicks the Submit button. The user is brought back to the View/Edit All Students page.

Remove Student – To remove a student the user clicks on the Teams and Students button. A list of all the teams will be displayed. The user then clicks on the View/Edit All Students button. A list of all the students is displayed. The user clicks the Remove button next to the student they want to remove. A screen is displayed where the user confirms they want to remove the student. The user then clicks the Remove button. The user is brought back to the View/Edit All Students page.

Parts

Add Part – To add a part the user clicks on the Parts button. A list of all the parts will be displayed. The user then clicks on the Add Part button. A screen is displayed where the user can add all the information for the new part. The user then clicks the Submit button. The part is created and the user is brought back to the Parts page.

Edit Part – To edit a part the user clicks on the Parts button. A list of all the parts will be displayed. The user then clicks on the View/Edit Part button next to the part they want to edit. A screen is displayed where the user can edit the information for the part. The user then clicks the Submit button. The user is brought back to the Parts page.

Remove Part – To remove a part the user clicks on the Parts button. A list of all the parts will be displayed. The user then clicks on the View/Edit Part button next to the part they want to edit. A screen is displayed where the user can edit the information for the part. The user then clicks the Submit button. The user is brought back to the Parts page.

Orders

Fill an Open Order – To fill an open order the user clicks on the Orders button. On the next screen the user clicks the Open Orders button. A list of all the open orders is displayed. The user selects the Review Order button next to the order they wish to fill. The order information for that order is displayed. The user clicks the Fill Order button to fill the order. The user is brought to the Filled Orders page.

View a Filled Order – To view fill a filled order the user clicks on the Orders button. On the next screen the user clicks the Filled Orders button. A list of all the open orders is displayed. The user selects the View Order button next to the order they wish to view. The order information for that order is displayed.

Team Expenses and Invoices

View a Team Expense and Invoice – To view a team expense and invoice the user clicks the Expenses and Invoices button. A list of all the teams is displayed. The user clicks the Select button next to the team they wish to view information for. The team members and orders for that team are displayed. The user can click the Select button for any order and review that order.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 21 PROJECT GOLDEN SPRUCE

Change Password

Change Password – To change their password the user clicks on the Change Password button. A screen is displayed where the user enters their old password and the new password they want. The user clicks the Submit button. The user’s password is changed and they are taken to the Login screen.

Forgot Password

Request a New Password – To request a new password the user clicks the Forgot Password button on the Login screen. The user then enters their email address and clicks the Submit button. A new password is sent to their email address.

Employee User Guide

This guide assumes that the user has a valid employee account and has logged into the FEDUP 2.0 website and is on the Employee Main Menu page.

Team

Add Team – To add a team the user clicks on the Teams and Students button. A list of all the teams will be displayed. The user then clicks on the Add Team button. A screen is displayed where the user can add all the information for the new team. The user then clicks the Submit button. The team is created and the user is brought back to the Teams and Students page.

Remove Team – To remove a team the user clicks on the Teams and Students button. A list of all the teams will be displayed. The user then clicks on the Remove button beside the team they wish to remove. A screen is displayed where the user confirms that they want to remove the team. The user then clicks the Remove button.

Student

Notes: A student must be added to a team that already exists. The name and email of a student are required; the phone number should be filled out for the team contact.

Add Student – To add a student the user clicks on the Teams and Students button. A list of all the teams will be displayed. The user then clicks on the View/Edit/Add All Students button. A list of all the students is displayed. The user clicks the Add Student button. A screen is displayed where the user can add all the information for the new student. The user then clicks the Submit button. The student is created and the user is brought back to the View/Edit/Add All Students page.

Edit Student – To edit a student the user clicks on the Teams and Students button. A list of all the teams will be displayed. The user then clicks on the View/Edit/Add All Students button. A list of all the students is displayed. The user clicks the View/Edit button next to the student they want to edit. A screen is displayed where the user can edit the information for the student. The user then clicks the Submit button. The user is brought back to the View/Edit/Add All Students page.

Remove Student – To remove a student the user clicks on the Teams and Students button. A list of all the teams will be displayed. The user then clicks on the View/Edit/Add All Students button. A list of all the students is displayed. The user clicks the Remove button next to the student they want to remove. A screen is displayed where the user confirms they want to remove the student. The user then clicks the Remove button. The user is brought back to the View/Edit/Add All Students page.

Parts

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 22 PROJECT GOLDEN SPRUCE

Add Part – To add a part the user clicks on the Parts button. A list of all the parts will be displayed. The user then clicks on the Add Part button. A screen is displayed where the user can add all the information for the new part. The user then clicks the Submit button. The part is created and the user is brought back to the Parts page.

Edit Part – To edit a part the user clicks on the Parts button. A list of all the parts will be displayed. The user then clicks on the View/Edit Part button next to the part they want to edit. A screen is displayed where the user can edit the information for the part. The user then clicks the Submit button. The user is brought back to the Parts page.

Remove Part – To remove a part the user clicks on the Parts button. A list of all the parts will be displayed. The user then clicks on the View/Edit Part button next to the part they want to edit. A screen is displayed where the user can edit the information for the part. The user then clicks the Submit button. The user is brought back to the Parts page.

Orders

Fill an Open Order – To fill an open order the user clicks on the Orders button. On the next screen the user clicks the Open Orders button. A list of all the open orders is displayed. The user selects the Review Order button next to the order they wish to fill. The order information for that order is displayed. The user clicks the Fill Order button to fill the order. The user is brought to the Filled Orders page.

Cancel an Open Order – To cancel an open order the user clicks on the Orders button. On the next screen the user clicks the Open Orders button. A list of all the open orders is displayed. The user selects the Review Order button next to the order they wish to fill. The order information for that order is displayed. The user clicks the Cancel Order button to cancel the order. The user is brought to the Filled Orders page.

View a Filled Order – To view fill a filled order the user clicks on the Orders button. On the next screen the user clicks the Filled Orders button. A list of all the open orders is displayed. The user selects the View Order button next to the order they wish to view. The order information for that order is displayed.

Change Password

Change Password – To change their password the user clicks on the Change Password button. A screen is displayed where the user enters their old password and the new password they want. The user clicks the Submit button. The user’s password is changed and they are taken to the Login screen.

Forgot Password

Request a New Password – To request a new password the user clicks the Forgot Password button on the Login screen. The user then enters their email address and clicks the Submit button. A new password is sent to their email address.

Student User Guide

This guide assumes that the user has a valid student account and has logged into the FEDUP 2.0 website and is on the Student Main Menu page.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 23 PROJECT GOLDEN SPRUCE

Team

View Team Members / Team Expenses and Invoices – To view a team expense and invoice the user clicks the Expenses and Invoices button. A list of all the teams is displayed. The user clicks the Select button next to the team they wish to view information for. The team members and orders for that team are displayed. The user can click the Select button for any order and review that order.

Parts

View Parts– To view parts a user clicks on the Parts Information button. A list of all the parts is displayed. To view the information for a particular part the user can click the View Part button next to the desired part.

Orders

Place an Order – To place an order the user clicks the Order Parts button. The user uses the drop down menus to select the part(s) they wish to order and the quantity for each part. When finished the user clicks the Submit Button. The order is submitted and user is taken back to the main menu.

Change Password

Change Password – To change their password the user clicks on the Change Password button. A screen is displayed where the user enters their old password and the new password they want. The user clicks the Submit button. The user’s password is changed and they are taken to the Login screen.

Forgot Password

Request a New Password – To request a new password the user clicks the Forgot Password button on the Login screen. The user then enters their email address and clicks the Submit button. A new password is sent to their email address.

Milestones

The following table shows our original milestone dates and our final completion dates.

Table 2: Milestones

Date Milestone Completed 9/04/2009 Proposal finished 9/04/2009 9/19/2009 Requirements section of functional spec finished 9/19/2009 9/25/2009 Functional spec .90 approved 9/25/2009 9/27/2009 First program review presentation 09/27/2009 10/02/200 9 Functional spec .95 approved 10/02/2009 10/09/200 9 Functional spec 1.0 approved 10/09/2009 10/25/200 9 Second program review presentation 10/25/2009 10/29/200 9 Screen mockups and 35 test cases completed 10/29/2009

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 24 PROJECT GOLDEN SPRUCE

11/02/200 9 Administrator functionality completed 11/02/2009 11/09/200 9 All user functionality completed 11/09/2009 11/12/200 9 Database and functionality design completed 11/12/2009 11/15/200 9 Design .90 approved 11/15/2009 11/27/200 9 Design .95 approved 11/27/2009 12/4/2009 Design 1.0 approved 12/4/2009 1/17/2009 Get FEDUP 2.0 Online 1/17/2009 1/24/2010 Complete Login Screen, Sessions, Password Functionality 2/28/2010 1/31/2010 Complete View/Create/Edit Parts 1/31/2010 2/07/2010 Complete View/Create/Edit Students 2/07/2010 2/14/2010 Complete View/Create/Edit Employees and Teams 2/14/2010 2/14/2010 Complete Administrator Functionality 2/14/2010 2/21/2010 Complete Employee/Student Functionality 2/21/2010 2/28/2010 Complete Order Processing 2/28/2010 3/05/2010 Troubleshooting/Additional Functionality 3/05/2010 3/08/2010 Golden Spruce white box testing and debugging 3/31/2010 3/19/2010 Client black box testing 3/31/2010 3/24/2010 User Stress Testing 4/08/2010 4/02/2010 Final Report 4/09/2010 4/05/2010 Founder’s day presentation complete 4/09/2010

Proposal finished

Our project was reviewed by faculty and was approved.

Requirements section of functional spec finished

Our requirements section has been completed and approved by all team members.

Functional spec .90 approved

The first draft of the functional spec has been submitted to our advisors.

First program review

The first program review has been completed and presented before the rest of the teams and advisors.

Functional spec .95 approved

The functional spec has been approved by our advisors and submitted to our industry representatives.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 25 PROJECT GOLDEN SPRUCE

Functional spec 1.0 approved

The functional spec is approved by both our advisors and our industry representatives.

Second program review

The first program review has been completed and presented before the rest of the teams and advisors.

Administrator functionality design completed

The overall architecture of the database will remain the same as in FEDUP 1.0. However, to get the functionality of FEDUP 2.0, many additional query’s, as well as much more C# code will need to be designed and written. The first thing we need to do is design the base functionality for the administrator user. This includes the ability to edit teams, employees, and parts through the user interface rather than doing it directly in SQL.

Design of all user functionality completed

The rest of the users’ functionality will be designed as needed to obtain the desired functionality of FEDUP 2.0.

Database and functionality design completed

Though FEDUP 1.0 has most of the tables and fields we need, for FEDUP 2.0 we will need to design a few more fields to provide the functionality we need along with much more code.

Design .90 approved

The first draft of the design document has been submitted to our advisors.

Design .95 approved

The design document has been approved by our advisors and submitted to our industry representatives.

Design 1.0 approved

The design document is approved by both our advisors and our industry representatives.

Get FEDUP 2.0 Online

As the main focus of this project is to host FEDUP 2.0 online this is a very important milestone and needs to be completed in order for us to test all the functionality in a real environment.

Complete Login Screen, Sessions, Passwords

All users will be greeted by a login screen when FEDUP 2.0 is launched, from which they will be able to log in and access their respective user interfaces.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 26 PROJECT GOLDEN SPRUCE

View/Create/Edit Parts

It will be possible for a FEDUP 2.0 user to create and modify parts through the user interface without using SQL directly.

View/Create/Edit Students

It will be possible for a FEDUP 2.0 user to create and modify student information through the user interface without using SQL directly.

View/Create/Edit Employees and Teams

It will be possible for a FEDUP 2.0 user to create and delete employees through the user interface without using SQL directly. It will be possible for a FEDUP 2.0 user to create and modify teams through the user interface without using SQL directly.

Complete Administrator Functionality

There will be an administrator user that can modify teams, parts, students and employees through the user interface.

Complete Employee/Student Functionality

There will be an employee user that can modify teams, parts, and students through the user interface. The student user interface is complete and includes the ability to order parts through the user interface.

Complete Order Processing

The part ordering system will be complete that enables a student to submit an online order for parts. The employee user can process the orders the students submit.

Troubleshooting/Additional Functionality

At this point all functionality will be completed and if there are problems with any of it they can be corrected. Additional functionality will be added as time permits.

Golden Spruce white box testing

At this point, the project will be mostly complete and testing by Golden Spruce team members can commence

Client black box testing

FEDUP 2.0 clients, faculty and tool room employees, will test FEDUP 2.0.

Stress testing

Engineering students will be offered an incentive such as pizza to come and test FEDUP 2.0 to make sure it can handle multiple users at once.

Final report complete

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 27 PROJECT GOLDEN SPRUCE

Project is finished, report is completed.

Founder’s day presentation complete

The presentation for founder’s day is complete and ready to present.

Schedule

Schedule Overview

This is the year-long schedule for Team Golden Spruce. The major phases were completing the functional specification, completing the design document, programming the software and testing the finished product. The first two major phases were completed in November and December when the functional specification and design document were approved, respectively. The next phase, programming the software, took place in a series of approximately one week long milestones, from mid-December to late-March. The final stage, testing, included three different testing sessions each employing a different testing method, white box, black box and stress testing, respectively and took place during March and the first weeks of April.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 28 PROJECT GOLDEN SPRUCE

Resources

There were very few resources required to complete this project. For development, we used computers with Windows SQL Server 2005, Visual Studio, and .NET 2.0 Framework.

Personnel

Team Golden Spruce consists of four members with the following responsibilities:

 Timothy Meyers: Database developer, team lead first semester

 Kris Slavenski: Database developer, team lead second semester

 Steven Rogers: C# developer

 Jeff Keagbine: C# developer

Equipment

For development, we used computers with Windows SQL Server 2005, Visual Studio, and .NET 2.0 Framework. These will be the personal computers of the team members and the lab computers in Shiley Hall.

Chapter 6 Conclusions

Team Golden Spruce successfully designed and implemented a web-based application and database to be used by the employees and students for the Freshmen Design Competition. There is a way for employees and administrators to add to the database through an online user interface. Students can log in online and order parts over the internet. There are security features in place to prevent unauthorized users from accessing pages they are not supposed to and from using SQL exploits to tamper with the database.

Team Golden Spruce used the waterfall development model. The Functional Specifications and Design Document were changed various times because of misunderstandings with the client. These misunderstandings were expected and so Team Golden Spruce was able to stay on schedule and finish on time.

Team Golden Spruce used a data-centered architecture with a central SQL Server database. This database interacted with web pages implemented using C# and ASP.Net. The Sell Parts screen is the most important of the screens and features a table which grows dynamically.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 29 PROJECT GOLDEN SPRUCE

The system could be extended to include additional functionality such as allowing for faculty users and having pictures and links along with the descriptions of the parts. A way to create a database from an uploaded spreadsheet could also be implemented in the future. This phase of the project doesn’t have hold any information about the actual competition. A system for inputting the competition results as the competition progresses could be added as well as printable score sheets for the entire competition.

References

These are the resources that Golden Spruce consulted during the implementation of FEDUP 2.0.

 Golden Spruce Functional Specification

 Golden Spruce Design Document

 Book 1

 Book 2

 Book 3

Appendices

Stored Procedure

The following is a list of all stored procedures used by the application.

GO CREATE PROCEDURE [dbo].[Get_Next_Invoice]( @Next_Invoice INT OUTPUT) AS BEGIN SELECT @Next_Invoice = COUNT(*) + 1 FROM Invoice_Hdr I

IF @Next_Invoice = null SET @Next_Invoice = 1 END

GO CREATE PROCEDURE [dbo].[List_Students_No_Params] AS BEGIN SELECT p.Email FROM Student p END

GO

CREATE PROCEDURE [dbo].[List_Students_One_Params] ( @Name NVARCHAR (30) ) AS

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 30 PROJECT GOLDEN SPRUCE

BEGIN SELECT p.Email FROM Person p WHERE p.Pname = @Name END

GO

CREATE PROCEDURE [dbo].[Get_Next_Invoice_Num] AS BEGIN SELECT COUNT(*) + 1 as Next_Invoice_Num FROM Invoice_Hdr I END

GO CREATE PROCEDURE [dbo].[List_Active_Employees_Names] AS BEGIN SELECT P.Pname, P.Email FROM Employee E, Person P WHERE E.Is_Active = 1 AND E.Email = P.Email END

GO

CREATE PROCEDURE [dbo].[List_Parts_Both_Params] ( @Part_Name NVARCHAR (30), @Part_Num INT ) AS BEGIN SELECT p.Part_Num, p.Part_Name FROM Part p WHERE p.Part_Num = @Part_Num AND p.Part_Name LIKE '%'+@Part_Name+'%' END

GO CREATE PROCEDURE [dbo].[List_Parts_No_Params] AS BEGIN SELECT p.Part_Num, p.Part_Name FROM Part p END

GO

CREATE PROCEDURE [dbo].[List_Parts_One_Params] ( @Part_Name NVARCHAR (30), @Part_Num INT ) AS BEGIN IF(@Part_Name = '') SET @Part_Name = NULL SELECT p.Part_Num, p.Part_Name FROM Part p WHERE p.Part_Num = @Part_Num OR p.Part_Name LIKE '%'+@Part_Name+'%' END

GO CREATE PROCEDURE [dbo].[Retrieve_Currently_Owned_Parts]( -- Add the parameters for the stored procedure here @Section NCHAR(1), @Team_Num INT ) AS BEGIN -- SET NOCOUNT ON added to prevent extra result sets from

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 31 PROJECT GOLDEN SPRUCE

-- interfering with SELECT statements. SET NOCOUNT ON;

-- Insert statements for procedure here SELECT Temp.Part_Name, Temp.Quantity FROM (SELECT p.Part_Num, p.Part_Name, SUM(id.Quantity) AS 'Quantity' FROM Part p, Invoice_Hdr ih, Invoice_Detail id WHERE ih.Section = @Section AND ih.Team_Num = @Team_Num AND id.Invoice_Num = ih.Invoice_Num AND p.Part_Num = id.Part_Num GROUP BY p.Part_Num, p.Part_Name) AS Temp WHERE Temp.Quantity > 0

END

GO CREATE PROCEDURE [dbo].[Retrieve_Invoice_Info] ( @Invoice_Num INT ) AS BEGIN SELECT p.Part_Num, p.Part_Name, p.Unit_of_Sale, p.Returnable, p.Price, id.Quantity, id.Cost FROM Part p, Invoice_Detail id WHERE id.Invoice_Num = @Invoice_Num AND id.Part_Num = p.Part_Num END

GO CREATE PROCEDURE [dbo].[Retrieve_Part_Info] ( @Part_Num INT ) AS BEGIN SELECT Part_num, Part_Name, Price, Unit_of_Sale, Amt_Purchasable, Returnable, Recheck, p.Description,Amt_In_Stock FROM Part p WHERE p.Part_Num = @Part_Num END

GO CREATE PROCEDURE [dbo].[Retrieve_Parts_History]( -- Add the parameters for the stored procedure here @Section NCHAR(1), @Team_Num INT ) AS BEGIN -- SET NOCOUNT ON added to prevent extra result sets from -- interfering with SELECT statements. SET NOCOUNT ON;

-- Insert statements for procedure here SELECT p.Part_Name, id.Quantity, id.Invoice_Num, ih.Date FROM Part p, Invoice_Hdr ih, Invoice_Detail id WHERE ih.Section = @Section AND ih.Team_Num = @Team_Num AND id.Invoice_Num = ih.Invoice_Num AND p.Part_Num = id.Part_Num END

GO CREATE PROCEDURE [dbo].[Retrieve_Purchasing_Team] ( @Invoice_Num INT ) AS BEGIN SELECT hd.Section, hd.Team_Num FROM Invoice_Hdr hd WHERE hd.Invoice_Num = @Invoice_Num END

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 32 PROJECT GOLDEN SPRUCE

GO CREATE PROCEDURE [dbo].[Retrieve_Return_Info] ( @Section NCHAR(1), @Team_Num INT) AS BEGIN SELECT p.Part_Num, p.Part_Name, p.Price, p.Unit_of_Sale, (SELECT ISNULL(SUM(id2.Quantity),0) FROM Invoice_Hdr ih2, Invoice_Detail id2 WHERE ih2.Section = @Section AND ih2.Team_Num = @Team_Num AND ih2.Invoice_Num = id2.Invoice_Num AND id2.Part_Num = p.Part_Num) AS Purchased FROM Part p WHERE p.returnable = 1 END

GO CREATE PROCEDURE [dbo].[Retrieve_Sale_Date] ( @Invoice_Num INT ) AS BEGIN SELECT hd.Date FROM Invoice_Hdr hd WHERE hd.Invoice_Num = @Invoice_Num END

GO CREATE PROCEDURE [dbo].[Retrieve_Sale_Info] ( @Section NCHAR(1), @Team_Num INT ) AS BEGIN DECLARE @tm_remaining int SELECT p.Part_Num, p.Part_Name, p.Price, p.Amt_Purchasable, p.Unit_of_Sale, p.Returnable, (SELECT (p.Amt_Purchasable - ISNULL(SUM(id2.Quantity),0)) FROM Invoice_Hdr ih2,Invoice_Detail id2 WHERE ih2.Section = @Section AND ih2.Team_Num = @Team_Num AND ih2.Invoice_Num = id2.Invoice_Num AND id2.Part_Num = p.Part_Num) AS Remaining

FROM Part p END

GO CREATE PROCEDURE [dbo].[Retrieve_Section_Professor] ( @Section NCHAR(1) ) AS BEGIN SELECT p.Pname FROM Person p, Class C WHERE C.Section = @Section and C.Email = p.Email END

GO

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 33 PROJECT GOLDEN SPRUCE

CREATE PROCEDURE [dbo].[Retrieve_Selling_Employee]( @Invoice_Num INT ) AS BEGIN SELECT p.Pname FROM Person p, Invoice_Hdr hd WHERE hd.Invoice_Num = @Invoice_Num AND hd.Email = p.Email END

GO CREATE PROCEDURE [dbo].[Retrieve_Team_Members] ( @Section NCHAR(1), @Team_Num INT ) AS BEGIN SELECT p.Pname, p.Email FROM Person p, Student S WHERE S.Section = @Section and S.Team_Num = @Team_Num AND S.Email = p.Email END

/* GO CREATE PROCEDURE [dbo].[Retrieve_Total_Cost] ( @Invoice_Num INT ) AS BEGIN SELECT hd.Total_Cost FROM Invoice_Hdr hd WHERE hd.Invoice_Num = @Invoice_Num END

*/

GO CREATE PROCEDURE [dbo].[Submit_Sale_Info] ( @Invoice_Num INT, @Section NCHAR(1), @Team_Num INT, @Email NVARCHAR (30), @Parts_and_Quantities NVARCHAR (1000), @Delimiter NCHAR (1))

AS BEGIN -- Insert into invoice header. INSERT INTO Invoice_Hdr (Invoice_Num, Section, Team_Num, Email, Date) Values (@Invoice_Num, @Section, @Team_Num, @Email, GETDATE()) set nocount on

-- @Parts_and_Quantities is the array we wish to parse -- @Delimiter is the separator character such as a comma -- @delimeter_position is used to locate each separator character declare @delimiter_position1 int declare @delimiter_position2 int declare @delimiter_position3 int -- @array_value holds each array value as it is returned declare @array_value_part nvarchar(1000) declare @array_value_quantity nvarchar(1000) declare @array_value_cost nvarchar(1000)

-- may need to delete thes. Are going to try to cast as part of the insert statement

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 34 PROJECT GOLDEN SPRUCE

declare @Insert_part_num int declare @insert_quantity int declare @insert_cost Money

-- For the loop to work I need an extra separator at the end. Always look --- to the left of the separator character for each array value

set @Parts_and_Quantities = @Parts_and_Quantities + @Delimiter;

-- Loop through the string searching for separtor characters while patindex('%' + @delimiter + '%' , @Parts_and_Quantities) <> 0 begin

-- patindex matches the a pattern against a string select @delimiter_position1 = patindex('%' + @delimiter + '%' , @Parts_and_Quantities) select @array_value_part = left(@Parts_and_Quantities, @delimiter_position1 - 1) -- clear out the first variable retrieved from the list select @Parts_and_Quantities = stuff(@Parts_and_Quantities , 1, @delimiter_position1, '')

-- patindex matches the a pattern against a string select @delimiter_position2 = patindex('%' + @delimiter + '%' , @Parts_and_Quantities) select @array_value_quantity = left(@Parts_and_Quantities, @delimiter_position2 - 1) -- clear out the first variable retrieved from the list select @Parts_and_Quantities = stuff(@Parts_and_Quantities , 1, @delimiter_position2, '')

-- patindex matches the a pattern against a string select @delimiter_position3 = patindex('%' + @delimiter + '%' , @Parts_and_Quantities) select @array_value_cost = left(@Parts_and_Quantities, @delimiter_position3 - 1) -- clear out the first variable retrieved from the list select @Parts_and_Quantities = stuff(@Parts_and_Quantities , 1, @delimiter_position3, '') -- This is where you process the values passed. -- @array_value_part holds the part number value of this element of the array -- @array_value_quantity holds the quantity value of this element of the array -- @array_value_cost holds the cost for this quantity of parts purchased -- casting may not be necessary. Documentation show these could be implicit

INSERT INTO Invoice_Detail (Invoice_Num, Part_Num, Quantity, Cost) Values (@Invoice_Num, CAST(@array_value_part AS Int), CAST(@array_value_Quantity AS Int), CAST(@array_value_cost AS Money))

end END

GO CREATE PROCEDURE [dbo].[Verify_Team] ( @Section NCHAR(1), @Team_Num INT) AS BEGIN SELECT COUNT(*) AS Valid FROM Teams WHERE Section = @Section AND Team_Num = @Team_Num END

GO CREATE PROCEDURE [dbo].[View_Teams] ( -- Add the parameters for the stored procedure here @Section NCHAR(1), @Team_Num INT ) AS BEGIN -- SET NOCOUNT ON added to prevent extra result sets from -- interfering with SELECT statements.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 35 PROJECT GOLDEN SPRUCE

SET NOCOUNT ON;

-- Insert statements for procedure here SELECT t.Section, t.Team_Num FROM Teams t LEFT OUTER JOIN Invoice_Hdr ih ON (t.Section = ih.Section AND t.Team_Num = ih.Team_Num) WHERE t.Section = @Section OR t.Team_Num = @Team_Num GROUP BY t.Section, t.Team_num END

GO

CREATE PROCEDURE [dbo].[View_Teams_Both_Params] ( -- Add the parameters for the stored procedure here @Section NCHAR(1), @Team_Num INT ) AS BEGIN -- SET NOCOUNT ON added to prevent extra result sets from -- interfering with SELECT statements. SET NOCOUNT ON; -- Insert statements for procedure here SELECT t.Section, t.Team_Num FROM Teams t LEFT OUTER JOIN Invoice_Hdr ih ON (t.Section = ih.Section AND t.Team_Num = ih.Team_Num) WHERE t.Section = @Section AND t.Team_Num = @Team_Num GROUP BY t.Section, t.Team_num END

GO CREATE PROCEDURE [dbo].[View_Teams_No_Params] AS BEGIN -- SET NOCOUNT ON added to prevent extra result sets from -- interfering with SELECT statements. SET NOCOUNT ON;

-- Insert statements for procedure here SELECT t.Section, t.Team_Num FROM Teams t LEFT OUTER JOIN Invoice_Hdr ih ON (t.Section = ih.Section AND t.Team_Num = ih.Team_Num) GROUP BY t.Section, t.Team_num END

GO

CREATE PROCEDURE [dbo].[View_Teams_One_Params] ( -- Add the parameters for the stored procedure here @Section NCHAR(1), @Team_Num INT ) AS BEGIN -- SET NOCOUNT ON added to prevent extra result sets from -- interfering with SELECT statements. SET NOCOUNT ON; -- Insert statements for procedure here SELECT t.Section, t.Team_Num FROM Teams t LEFT OUTER JOIN Invoice_Hdr ih ON (t.Section = ih.Section AND t.Team_Num = ih.Team_Num) WHERE t.Section = @Section OR t.Team_Num = @Team_Num GROUP BY t.Section, t.Team_num END

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 36 PROJECT GOLDEN SPRUCE

Troubleshooting

Sub-Project Documentation Computer Specs: OS: Win 7 Processor: AMD Quad Core RAM: 4 GB Graphics Card: ATI 512mb Space: 500+ GB

Reading Hints: All figure numbers are dynamically referenced, meaning, you can control-click on them to jump to the Figure. Links: http://www.asp.net/(S(ywiyuluxr3qb2dfva1z5lgeg))/learn/videos/video-189.aspx

Current thoughts: 1/28/10 – We are beginning to think that team golden designed FEDUP in the least web deployment friendly way possible. The users table should be the only table the handle people, while the capabilities of ASP.net handle the different roles and members. 2/1/10 – Realistically, the login functionality may take the whole month of Feb to get implemented correctly, however, with some push I think it could be done in two weeks. This is considering the exams we all have this Friday.

Processes: Trying to run a simple Visual Basic login screen on a small website - 1/30/10

Following the tutorial from about creating a customer membership provider by Chris Pels, located here, we encountered an issue. It is caused by some type of validation requirement with ASP.NET shown in Figure 47 below.

This error was corrected by placing the following code in the web.config file:

To connect to my database one my computer, the connection string had to be changed to the following:

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 37 PROJECT GOLDEN SPRUCE

This line was added to the HDIMembershipProvider class because it was shown in the video but not in the code that was downloaded:

Private _eventSource As String = "HDIMembershipProvider" From here I published the website using IIS, and received the error in Figure 48 and well as Figure 49. After some troubleshooting, I decided to just re implement the code making sure I include everything from the downloaded code. This fixed the errors.

I then received the error is Figure 410, and after correcting the connection string I received the error in Figure 411, but this was fixed by correcting the connection string from ‘…TIM- PC\\TIMSQLSERVER…’ to ‘…TIM-PC\TIMSQLSERVER….’ The extra ‘\’ is normally used as an escape character, but for the web.config file, it is not needed.

After all these errors, I was finally able to get the ‘CreateUser.aspx’ page to show up. After inputting dummy data, I received the feedback shown in read in Figure 412 stating ‘Your account was not created. Please try again.’

To debug this issue, I need to set ‘CreateUser.aspx’ to the start page by right-clicking on it in Visual Studio and selecting ‘Set as start page.’ I then just hit the play button to debug, however, I get the error message in Figure 413 and do not understand it enough to get around it. So I decided I would trace the database instead to get an idea of when and where the database is being accessed, however, when I click on ‘Data Profile Viewer’ under integrations services under SQL Server 2008 in the start menu, I get the error message in Figure 414. This tells me I need ‘Integration Services’ to be installed. However, after inserting the installation CD and trying to locate this functionality in the features area, I do not see it. This may or may not matter, but the license agreement say server ‘EXPRESS,’ but according to MSDN where I got the software from, it’s the full version.

Currently, I have no way to debug and that is where I am as of 2/1/10.

2/7/10

Paying more attention to what the error message said, I tried right clicking on the WebSiteVB1 shown in Figure 415. Under that I saw ‘Set as start up project.’ I selected that and debugging now works. Yippy!

2/9/10 (note: on 2/8/10 I began implementing a C# version of this login functionality)

After many debugging attempts, it has been determined that the login functionality works as it should only during debug mode. More specifically it only works when you hit the play button in visual studio and it pops up the first page where you create a user. If you try and create another user after the first successful attempt, even after logging out, and without stopping the debugging, you will end up with Figure 412. It has also been determined that it doesn’t matter where you put a break point, in fact you don’t even need break points. It will run correctly with no break points in debug mode.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 38 PROJECT GOLDEN SPRUCE

After many hours I decided I would try to implement the C# version of the login functionality (I tired the VB version as that is what the video tutorial discussed). I wanted to see if the C# version would bypass this issue, I have currently gotten as far as Figure 3. However, I am not having the same luck at getting past this problem as I did with the VB code. The recommendations online say to change your Trust levels to full for the local internet connection. I have done this and still no change, I am currently attempting to use both the 32-bit and 64-bit versions of ASP.net config as some files posts say this caused their problem, but so far I have had no luck. I have been referencing this post: http://weblogs.asp.net/jgaylord/archive/2007/02/13/system-web-aspnethostingpermission- when-accessing-network-or-intranet-projects-using-visual-studio-2005.aspx

The funny thing is, if I run this in debug mode, it bypasses this error and functions correctly. AAAHHH!!!

2/9/10 (Later that day)

I have conquered the issue in Figure 49. Referring to Figure 16 and Figure 17, and getting help from this post: http://geekswithblogs.net/ProjectLawson/archive/2009/05/05/iis- system.web.aspnethostingpermission-exception-on-windows-7-rc.aspx the issue revolves around the ‘Load User Profile’ in the Application Pool in IIS 7.0 on windows 7. By default it is set to ‘False.’ It needs to be set to true, make sure to do so.

I now received the same error as shown in Figure 48.

2/21/10 Create your own SQL Server Database. Read this: http://msdn.microsoft.com/en-us/library/83y98ckk.aspx

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 39 PROJECT GOLDEN SPRUCE

Images:

Figure 47

Figure 48

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 40 PROJECT GOLDEN SPRUCE

Figure 49

Figure 410

Figure 411

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 41 PROJECT GOLDEN SPRUCE

Figure 412

Figure 413

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 42 PROJECT GOLDEN SPRUCE

Figure 414

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 43 PROJECT GOLDEN SPRUCE

Figure 415

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI FINAL REPORT REV. 0.90 PAGE 44 PROJECT GOLDEN SPRUCE

Figure 16

Figure 17

Figure 18

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: KRIS SLAVENSKI

Recommended publications