isu alumni association online store - ecpe senior...

ISU Alumni Association Online StoreProject Number May05-39

Final Report

Client:Iowa State University Alumni Association

Faculty AdvisorDr. Srinivas Aluru, CprE

Team MembersKeith Dahlby, CprE Jordan Jump, CprE

Andrew Kirpalani, CprE Jonathan Ruhnke, CprE

DISCLAIMER: This document was developed as a part of the requirements of an electrical and computer engineering course at Iowa State University, Ames, Iowa. This document does not constitute a professional engineering design or a professional land surveying document. Although the information is intended to be accurate, the associated students, faculty, and Iowa State University make no claims, promises, or guarantees about the accuracy, completeness, quality, or adequacy of the information. The user of this document shall ensure that any such use does not violate any laws with regard to professional licensing and certification requirements. This use includes any work resulting from this student-prepared document that is required to be under the responsible charge of a licensed engineer or surveyor. This document is copyrighted by the students who produced this document and the associated faculty advisors. No part may be reproduced without the written permission of the senior design course coordinator.

April 1, 2005

May05-39 Final Report Revision 1.0

Table of ContentsList of Figures ivList of Tables vList of Definitions vi

Introductory Materials 1 Executive Summary 1Problem 1Goal 1Approach 1Design 1Conclusions and Benefits 2Acknowledgement 2Problem Statement 2General Problem Statement 2General Solution Approach 3Operating Environment 3Intended Users and Intended Uses 3Intended Users 3Intended Uses 3Assumptions and Limitations 3Technical Assumptions 3Non-Technical Assumptions 4Limitations 4Expected End Product and Other Deliverables 4

Product Approach and Results 5 End Product Functional Requirements 5Resultant Design Constraints 5Approaches Considered and One Used 5Technical approach used 5Other technical approaches considered 6Implementation Process Description 6Project Infrastructure 7Development Framework and Common Component Creation 7Peripheral Component Creation 7Implementation Improvements 8End-Product Testing Description 8Integrated Testing Procedures 8Client Testing and Feedback 9Future Testing 9Product End Results 9Database / Data Access 9Objects 9Administrative Interface 10Storefront 10

ii


Other Areas 10Detailed Design 11Design Overview 11Business Model 11Database Abstraction Layer 12Business Logic Tier 14Presentation Tier 15

Resources and Schedules 21 Resources 21Personal Effort Requirements 21Financial Requirements 22Project Schedules 24Fall 2004 Schedules 24Spring 2005 Schedules 26

Closure Material 28 Project Evaluation 28Project Definition 28Technology Considerations and Selection 28End-product Design 28End-product Implementation 28End-product Testing 29End-product Documentation 29End-product Demonstration 29Project Reporting/Deliverables 29Overall Project Score 29Commercialization 29Recommendations for Additional Work 30Multiple Product Images 30Extended Category Structuring 30Frequent Use of Stored Procedures 30Database Backup/Recreation Script 30Lessons Learned 30What Went Well 30What Didn’t Go Well 30What Technical Knowledge Was Gained 31What Non-Technical Knowledge Was Gained 31What Would Be Done Differently Next Time 31Risk and Risk Management 31Anticipated Potential Risks and Planned Management 31Anticipated Risks Encountered and Success in Management 31Unanticipated Risks Encountered, Attempts to Manage and Success 32Resultant Changes in Risk Management Made Because of Encountered Unanticipated Risks 32Project Team Information 32Client Information 32Faculty Advisor Information 33Student Team Information 33

iii


Closing Summary 33

iv


List of FiguresFigure 1: Architectural Overview..................................................................................................11Figure 2: Database Schema...........................................................................................................13Figure 3: Class Diagrams for Business Logic Tier........................................................................15Figure 4: Old Front Page...............................................................................................................16Figure 5: New Front Page..............................................................................................................17Figure 6: Original Item Description Page......................................................................................18Figure 7: New Item Description Page...........................................................................................18Figure 8: Project Schedule — Fall 2004........................................................................................23Figure 9: Project Deliverables — Fall 2004..................................................................................23Figure 10: Revised Project Schedule — Fall 2004........................................................................24Figure 11: Project Schedule — Spring 2005.................................................................................25Figure 12: Project Deliverables — Spring 2005............................................................................25Figure 13: Revised Project Schedule — Spring 2005...................................................................26

v


List of TablesTable 1: Previous Estimated Personal Effort.................................................................................20Table 2: Revised Estimated Personal Effort..................................................................................20Table 3: Final Personal Effort........................................................................................................21Table 4: Previous Estimated Financial Budget..............................................................................21Table 5: Revised Estimated Financial Budget...............................................................................21Table 6: Final Financial Budget....................................................................................................22

vi


List of DefinitionsASP Active Server Pages, a Microsoft technology that allows web pages to be

dynamically generated. ASP is commonly used to allow web pages to interface with database systems and other external data sources.

ASP.NET ASP.NET is the newest version of ASP, implemented as part of the .Net Framework. ASP.NET offers many significant improvements over classic ASP, and allows scripting to be written using several languages including C#. More information: http://msdn.microsoft.com/asp.net/

C# C# is a Microsoft-created object-oriented programming language similar to Java. C# was created for use with the .Net Framework and has many features designed specifically to interact with various technologies available within the framework.

CSS Cascading Style Sheets is a simple text-based mechanism that allows style information (e.g. fonts, colors and spacing) to be attached to HTML and XML documents. More information: http://www.w3.org/Style/CSS/

MSDE Microsoft SQL Server 2000 Desktop Engine is a free, redistributable version of SQL Server for client applications that require an embedded database and Web sites serving up to 25 concurrent users. It integrates well with the Windows operating system and the .NET Framework. More information: http://www.microsoft.com/sql/msde/default.asp

MySQL MySQL is an open-source database server that is frequently used in small- and medium-scale web application development. MySQL doesn’t support many of the advanced features supported by DB/2, but it is just a robust and has enough features for most applications. More information: http://www.mysql.com/

.Net Framework The .Net Framework provides a common set of tools for developers on the Windows platform. These tools can be accessed using a variety of languages, including C#. ASP.NET is part of the .Net Framework. More information: http://msdn.microsoft.com/netframework/

SVN Subversion - a version control system for controlling access to a software project and it’s files.

vii

Introductory MaterialsExecutive SummaryProblemThe Iowa State University Alumni Association is an organization meant to promote and publicize Iowa State University. One of the ways that the Alumni Association fulfills its function is by selling Iowa State branded merchandise. The merchandise directly promotes Iowa State as well as providing revenue to fund the organization. This merchandise is marketed through an online store (http://www.isualum.org/store/). The previous store was barely adequate for the purpose and the Alumni Association asked for a new system to be put in place. This senior design project was created to that end.

GoalThe goal of the project was to create three product deliverables:

An attractive online storefront An integrated and comprehensive database system A management tool suite

The storefront presents the articles available for sale by pulling appropriate information from the database system. In addition it provides comprehensive ordering capabilities by interfacing with the same database system.

The database system replaces several disparate databases that had been required to display merchandise, process orders, and maintain vendor information.

The management tool suite allows the Alumni Association staff to administer the online catalog after project completion. They are able to add, delete, and change items and prices and update vendor information without having to directly interact with the database system.

ApproachThe team used the following approach to facilitate successful implementation of the design objectives:

Improved processing flow for orders

Easily manageable catalog

Intuitive storefront

The team identified certain assumptions and limitations, and chose the development environment. The project proceeded as planned.

DesignThe design follows an object oriented approach that divides the development into three tiers: the presentation tier, business logic tier, and the data access tier. The presentation tier handles interaction with visitors to the store. The layout can be manipulated to best fit the requirements

of the team’s customer, but it has been modeled after several successful, existing stores. The business logic tier mediates interaction between the presentation and data access tiers, providing objects to represent business entities (vendors, items, etc) and business processes (shopping cart, order processing, etc). Finally, the data access tier provides a common interface to interact with the database system that stores the information needed by the application. This layer of abstraction will allow a more flexible data management solution.

Conclusions and BenefitsUpon completion of the project, the Alumni Association received an online store system that is on par with current leaders in the e-commerce field. The new store system eliminated the data duplication present in the old system, as well as reduced the amount of overhead person-hours required to complete an order. These technical benefits translate into overhead cost savings for the Alumni Association and allow the organization to better serve the Iowa State community.

AcknowledgementThe team wishes to thank Dr. Srinivas Aluru for his support and guidance as the project advisor. In addition the team would like to thank Kate Bruns and the staff at the ISU Alumni Association for guidance as well as origination of the project.

Problem StatementThe project has assisted the Iowa State University Alumni Association in their mission:

“To become the lifetime partner in engaging all alumni, students, and friends with Iowa State University.”

and vision:

“To engage the talents and resources of alumni, students, and friends in the life, work, and aspiration of Iowa State University.”

by creating a new online store system for the organization.

General Problem StatementThe ISU Alumni Association’s online store exists to raise money for and directly promote the goal of serving the alumni and promoting the visibility of Iowa State University. The money raised by the sale of Iowa State branded products is used to increase services to the alumni. The products themselves promote the university.

The main goals of this project are to improve the ability of the client’s online store to meet its goals. These goals have been accomplished by redesigning the public storefront and implementing a comprehensive suite of administrative tools to optimize all aspects of the existing ordering process.

The previous store was implemented entirely using static HTML files and several separate databases, each of which must be manually updated whenever the catalog is changed. The project team has created a new store using ASP.NET technology that dynamically updates the store and processes orders in conjunction with a new database server.

General Solution ApproachThe team built upon existing C#, ASP, and .NET knowledge in order to implement this new store and tool suite. Considerable effort was also be put into efficient database design in order to minimize data reentry. Great care was taken to ensure that modifications to the store can be made from a central location and applied to all relevant stages in the ordering process.

Operating EnvironmentThe new online store is served from the existing Alumni Association server running the .NET Framework. The database is also housed on the aforementioned machine. The new online store has similar storage and bandwidth requirements as the previous store.

Intended Users and Intended UsesThis section describes the expected users and uses of the system that will be implemented.

Intended UsersThe project has components that are intended for use by one or both of two distinct groups of users:

Online Store CustomersThe primary users of the online store are visitors to the client’s web site that wish to browse or purchase from the client’s product catalog.

Alumni Association StaffThe sole users of the administrative tool suite are the staff of the Alumni Association.

Intended UsesCustomers of the online store expect an experience similar to that found at other online stores. The public storefront is used by customers to browse the product catalog, select items for purchase, manage a “shopping cart” of items selected for purchase, and complete orders by providing shipping and billing information.

The staff of the Alumni Association use the administrative tool suite to add, remove and update products in the catalog; process orders placed through the public store front; deliver vendor invoices via e-mail; and view reports of sales statistics.

Assumptions and LimitationsThis section describes the assumptions under which the developers have been operating, as well as the limitations to which the finished product is subject.

Technical AssumptionsThe team holds certain technical assumptions about the system:

The majority of users access the public store front with a modern web browser. Modern web browsers include Microsoft Internet Explorer 5.0 or later, Netscape 6.0 or later, Mozilla Firefox and Safari.

The majority of users have an Internet connection with bandwidth sufficient to support a graphics-intensive user experience.

The client’s server has sufficient system resources to support the web application produced by the project.

The server has ASP.NET 1.1 (or later) installed.

Non-Technical AssumptionsThe team holds certain non-technical assumptions about the system:

Users of the store have previous experience with standard online store protocol. Users of non-traditional and legacy web browsers accept a marginalized yet functional user

experience. Users with lesser bandwidth availability accept a marginalized yet functional user

experience. Alumni Association staff have sufficient experience and ability to operate web-based

administrative tools.

LimitationsThe team has identified certain limitations to the system:

The online store paradigm presents many user experience limitations that are dealt with using methods most commonly used in similar commercial environments throughout the Internet.

The use of a dedicated database server has been limited by the willingness and ability of the ISU Foundation to provide access for the use of this project.

As a dedicated database server cannot be used, the system resources available on the Alumni Association’s server limit the demands that can be placed on the database solution that was selected.

Team members had to become proficient with ASP.NET technology.

Expected End Product and Other DeliverablesUpon completion, the project has produced an online store capable of presenting merchandise, accepting orders, and maintaining security. In addition, a new database has been constructed to eliminate redundant work, thus streamlining both processes and information. Finally, a comprehensive suite of administrative tools have been produced to allow Alumni Association staff to manage the catalog, process customer orders and gather store data. Presumably, this system will increase profits for the Alumni Association by eliminating unnecessary work with new management tools and increasing sales with a more attractive and usable public storefront. All code and artifacts are the property of the Iowa State University Alumni Association.

Product Approach and ResultsEnd Product Functional RequirementsThe following functions provide users with all the intended uses and benefits of the Alumni Association’s Online Store.

The system allows the customer to view lists of items in the product catalog. The system allows the customer to view details about individual items in the product catalog. The system allows the customer to add items from the product catalog to the shopping cart. The system allows the customer to update the quantity of items in the shopping cart. The system allows the customer to view the contents of the shopping cart. The system allows the customer to place an order for the items in the shopping cart. The system allows the staff to view orders placed by customers. The system allows the staff to submit orders to venders via e-mail. The system allows the staff to view statistics about orders received by the system.

Resultant Design ConstraintsThe team is constrained by the above functional requirements.

The majority of users access the public store front with a modern web browser. Modern web browsers include Microsoft Internet Explorer 5.0 or later, Netscape 6.0 or later,

Mozilla Firefox, and Safari. The majority of users have an Internet connection with bandwidth sufficient to support a

graphics-intensive user experience. The client’s server has sufficient system resources to support the web application produced

by the project. The server has ASP.NET 1.1 (or later) installed. Users of non-traditional and legacy web browsers accept a marginalized yet functional user

experience. Users with lesser bandwidth availability accept a marginalized yet functional user

experience. The online store paradigm presents many user experience limitations that are dealt with using

methods most commonly used in similar commercial environments throughout the Internet. The system resources available on the Alumni Association’s server limit the demands that

can be placed on the database.

Approaches Considered and One UsedThis section details the approaches considered for the project as well as the one that was chosen. It is important to note that much of the approach taken was defined in the project specification and the team did not spend time researching alternatives that would not have met client wishes.

Technical approach usedThe technical approach used in the final product is detailed below.

Programming language: C# Language support of needed features and interoperability with other components is determined the programming language. While C# is the official language, any language supported by ASP.NET can be used.

Database: Microsoft Desktop EngineA relational database that supports transactions was required. Originally, MySQL was to be used as it is the most robust, free, and widely supported relational database available. However, a choice was made to move to the Microsoft Desktop Engine for its increased operating system integration and the existence of a number of Windows tools for the product, additionally it more seamlessly integrates with ADO.NET, which is the .NET Framework database toolkit.

Platform: Windows Server 2000The existing server already ran this operating system. Windows best supports ASP.NET. The team suggests that the server operating system be upgraded to Windows Sever 2003 as soon as possible.

Browser support: Modern web browsers The public storefront supports modern web browsers. Non-traditional and legacy browsers are supported, but with limited functionality.

Other technical approaches consideredAs stated before, most of the technical considerations were defined in the client project specification. Thus, not all aspects of the project had additional approaches considered, below are the ones that did.

Database: MySQLMySQL is one of the most widely used and supported relational database engines available. It would be a fine fit for this project, yet was ultimately put aside in favor of the Microsoft Desktop Engine and its specific attention to the Windows operating system and ADO.NET features.

Platform: Windows Server 2003Windows Server 2003 is actually a better platform for this project, but at this time the client is unwilling to update their server operating system. As such, the team is recommending to the client that this change be implemented at the earliest possible time.

Implementation Process DescriptionThere have been several distinct phases in the implementation of this design. Each phase will now be described in detail.

Project InfrastructureThe first phase of implementation was setting up the project infrastructure. There were several things that needed to be done on the development workstations and on both development and production servers before the project could be fully implemented. First, the team needed to set up a source control system on the development server, for which it was determined that SVN was the best option. Within SVN, two repositories were created: one to store project code files, and one to store project documentation to facilitate collaborative development of non-code resources. Once the source control server was in place, the development workstations needed to be configured to connect to the repositories. For this purpose, AnkhSVN, a Visual Studio plug-in for controlling SVN operations, was used.

During this stage the database server was also installed and configured on the existing server hosted by the client. The database server was installed on the production server to facilitate its use in other ongoing client projects in addition to the online store, as many existing applications use Access databases similar to the existing store. Its use in other projects also allowed configuration problems with the database to be discovered and eliminated earlier in the development cycle, an unplanned benefit of this decision.

A few problems were encountered at this early stage of development for which solutions needed to be found before development could continue. First, there were some problems configuring SVN to work on the development server, which was a Windows environment. There was also an issue using AnkhSVN with Web projects that was quickly discovered, for which a specialized version of AnkhSVN had to be installed. Finally, because some of the developer workstations were located outside of the Iowa State University network, VPN software provided by Academic Information Technologies needed to be installed to allow the workstations to connect to the database. This was one of many minor difficulties encountered because the developers would be required to compile and test the code generated by the project on local machines instead of the client’s production server, on which the database was hosted. These issues were all quickly resolved, however, and the team moved on to the next phase of implementation.

Development Framework and Common Component CreationThe next phase of implementation required creating a Visual Studio solution with projects for all the necessary components of the project. A project was defined for each component of the design, as specified in the Detailed Design found in this document. At this point each project was also configured with necessary dependencies on other project, and this dependency structure was used to determine implementation priorities.

As was determined in the planning and design stages of the project, the first components that needed to be created were the Model and Database Abstraction Layers. These components were most tightly coupled with the rest of the design, and type and interfaces defined by them were used throughout the project. Also, potential problems with the overall design were revealed earlier in the development process because these integral components were implemented first.

Peripheral Component CreationOnce the overall solution was configured and the common components were created, implementation of the other components was possible. At this point the implementation was

essentially partitioned into three parts: business logic, model maintenance, and performance analysis; database implementation and administrative interfaces; and the public web interface. Given a relatively stable collection of common components, these activities were able to proceed with relative independence through the majority of development. As development in each of these partitions neared completion, they became increasingly dependent on each other, which slowed development by revealing unforeseen difficulties. However, because there were several team members with knowledge about each part, these difficulties were more easily resolved than they would have been with more segmented development. As the implementation neared completion, it was time to begin testing.

Implementation ImprovementsNaturally there are several improvements that could have been made to the implementation process. First, the initial phases of implementation took much longer than expected, for various reasons, delaying the ability of the team to begin work on the more difficult phases of implementation. This waiting period should have been used to test implementation ideas and to explore the technologies being used in the project, which were unfamiliar to some team members, but it was not. Additionally, many difficulties were encountered doing development on local development workstations, which would have been avoided with a more robust web development environment. This has always been a weakness of the Visual Studio family, and several team members experienced problems configuring the development environment. Finally, there were several occasions that problems arose on the boundaries of the three partitions, at which point it was unclear whose responsibility some of the changes were. It would have been beneficial to decide earlier in the cycle how these responsibilities were to be distributed

.

End-Product Testing DescriptionTesting was performed throughout development, and will continue beyond the life of the project within the context of the senior design course. Planned additions and extensions to the product will require further testing before its eventual final release to the public. The primary phases of testing activity will now be described.

Integrated Testing ProceduresThrough the initial phases of implementation, testing was integrated with the development of individual components. For example, as the objects in the Model were developed, test pages were made to test for the conditions defined in the Project Plan document. The same process was used for the higher-level implementations. As custom web controls were created for various purposes, sample pages using them were created with data designed to test the boundary conditions of each control. The database implementation, which was the most involved and intricate part of the project, was tested thoroughly during its concurrent development with the administrative interface. An interface for items would be created and then the database implementation for items would be created and tested. Problems with each component were discovered using this method, which worked quite well and justified the coupling of those development activities.

Client Testing and FeedbackAs components neared completion, they were released to certain staff members of the client for further testing and feedback. This satisfied two purposes: first, problems were exposed when the interfaces were used by non-developers; and second, client feedback was integrated into the development process earlier than would have otherwise been possible. This was particularly true for the administrative interface, as interface requests often changed after initial implementations were noted to be inefficient or generally unsatisfactory. These testing activities were continued until the client believed they had a product that satisfied their requirements and was worthy of public consumption. At this point, the store was released on a public web site and the testing address was given to the entire client staff to allow them and others to more completely test the system for remaining errors and performance problems encountered with a larger store audience. This expanded audience resulted in much fewer problems than expected and generally convinced the team and the client that the product was indeed nearly complete.

Future TestingThe client is currently considering options for further testing and eventual release of the product. Through the limited initial testing of the product, many additional features were suggested, and though they are beyond the scope of this project, they are being considered for addition to the product before its final public release. Beyond these additional features, a more extensive, yet still limited public test period might also be of value. The client is currently considering these options and related decisions will be made.

Product End ResultsEach component of the project has been completed to satisfy the basic requirements, but improvements can be made in certain areas:

Database / Data Access The database structure is finalized. It stores all relevant information. The database access layer reliably adds, modifies, and deletes information from the database. One improvement that could be made would be frequent use of stored procedures. The data access layer would be simplified, database operations would be more efficient, and it could reduce the security implications were the username and password compromised. Additionally, a script could be created that would backup the database and recreate it in case of a reinstall or database corruption.

ObjectsThe objects provide all the functionality outlined in the detailed design. No need of improvement is seen for this area.

Administrative InterfaceThe administrative interface allows manipulation of the various objects and order processing. However, many improvements could made to the user experience. The data could be organized and accessed many different ways. For example, the administrator might want be able to view the items in the store organized by category, but only show the items from a specific vendor. While the interface was designed to be as intuitive and natural as possible, it doesn't cover all options. A more flexible system might address this issue better. Additionally, a lack of a global style sheet keeps the administrator from experiencing a consistent look and feel.

StorefrontThe storefront provides browsing and ordering functionality. Use of the yet-to-be ISUAA stylesheet would ensure a consistent user experience across Alumni sites.

Other AreasA few other general areas may need changes or improvements. The authentication module for the Alumni association may change in the near future. When complete, it will need to be integrated with the store. The code is sparsely commented. Robust comments would help future teams or employees when making modifications. Formal user documentation for the administrative and storefront could reduce the support burden on Alumni employees. Along the same line, a comprehensive error handling and reporting system would help customers and employees identify problems. When the store is transferred to the production system, a few coding and setup changes will need to be made.

While many improvements could be made to the system, it is functional and satisfies the basic requirements.

Detailed DesignThis section will detail the complete design of the system, beginning with an overview followed by a more complete description of each component of the application.

Design OverviewThe system is designed using a typical three-tier architecture. The three tiers are the data tier, the business logic tier, and the presentation tier. Spanning these tiers is a set of common entities that form the business model, objects that are used by all components of the application. A general overview of the system is provided in Figure 1.

Figure 1: Architectural Overview

Business ModelThe business model defines a collection of entities that are used by various components of the system to represent important information. These business entities include objects to represent customers, addresses, items and orders. By providing a set of common objects, the various levels of the architecture are able to communicate without knowledge of their independent functionalities. The objects defined in business model are as follows:

AddressInfo1. Stores common information used for billing and shipping addresses.

CartEntry Stores an ItemInfo and an CartItemOptionsetInfo

CartInfoo Container for CartItemInfo

CartItemOptionsetEntryo Option/Value pairs

CartItemOptionsetInfoo Container for CartItemOptionsetEntry

ItemOptionCollectiono Container for ItemOptionInfo

ItemOptionInfoo Abstract class to for SelectItemOptionInfo and TextItemOptionInfo

ItemOptionValueCollectiono Container for ItemOptionValueInfo

ItemOptionValueInfoo Stores a possible choice, along with changes in price.

SelectItemOptionInfoo Implementation of ItemOptionInfo, for selecting among given choices.

TextItemOptionInfoo Implementation of ItemOptionInfo, for entering user text.

CartItemInfo2. Stores item information along with quantities

CategoryInfo3. Stores category details and item associations

CreditCardInfo4. Stores the card type and credit card number

CustomerInfo5. Stores information unique to the customer, including ISUAA membership

ItemInfo6. Catalog information about an item sold by the store

LineItemInfo7. Details about an ordered item, including customizable parameters

OrderInfo8. Information about an order, including billing and shipping information

PriceInfo9. Member, nonmember, and cost of an item

ShippingInfo10. Shipping costs for an item

VendorInfo11. Vendor information about items sold in store

InventoryStatusInfo12. Indicates if an item is available to be sold, including specific messages

ContactInfo13. Contact information for vendors or customers

PictureInfo14. Characteristics about a picture of an item

Database Abstraction LayerThe data tier consists of four main components:

Relational Database SystemA relational database will be used to store the product catalog and the orders placed using the system. The database schema is shown in Figure 2.

Figure 2: Database Schema

Database Abstraction Layer (DAL) InterfacesThese interfaces function as a façade to hide the database architecture from the business logic tier. There are five interfaces defined in DAL:

ICategory Insert(CategoryInfo NewCategory) Update(CategoryInfo ExistingCategory) Remove(int CategoryID) CategoryInfo GetCategory(int CategoryID) CategoryInfo[] GetCategories(int Category) ICustomer CustomerInfo Insert(CustomerInfo NewCustomer)

CustomerInfo Update(CustomerInfo ExistingCustomer) CustomerInfo GetCustomer(int aCustomerId) IItem ItemInfo Insert(ItemInfo NewItem) ItemInfo Update(ItemInfo ExistingItem) ItemInfo GetItem(string ItemID) ItemInfo[] GetItemsByCategory(int CategoryID) ItemInfo[] GetItemsByVendor(int VendorID) IOrder OrderInfo Insert(OrderInfo NewOrder) OrderInfo GetOrder(int OrderID) IVendor

VendorInfo Insert(VendorInfo NewVendor)VendorInfo Update(VendorInfo ExistingVendor)Remove(int VendorID)VendorInfo GetVendor(int VendorID)VendorInfo[] GetVendors()

IPicturePictureInfo Insert(PictureInfo NewPicture)PictureInfo Update(PictureInfo NewPicture)PictureInfo GetPicture(int aPictureId)Int[] GetPicturesIdsByItem(int aItemId)Remove(int aPictureId)

ICreditCardString[] GetCreditCardCompanies

IInventoryStatusInventoryStatusInfo GetStatus(int aStatusId)InventoryStatusInfo[] GetStatusOptions()

DAL Interface ImplementationsAn implementation of the DAL interface must be created for each database system that will be used with the system. Initially an implementation will be developed for the testing database, and then additional implementations will be created for the database server used by the production system.

DAL FactoryAn instance of the factory design pattern, this static object will instantiate the proper implementation of the DAL interface based on the currently-configured database system.

Business Logic TierThe business logic tier is responsible for mediating interaction between the data and presentation tiers. These responsibilities include retrieving requested information from the data tier for use by the presentation tier as well as processing and validating information from the presentation tier before it is passed to the data tier. The services provided by each component are illustrated in Figure 3: Class Diagrams for Business Logic Tier, and are described below.

-ItemInfo Insert(ItemInfo)-void Update(ItemInfo)-ItemInfo GetItem (ID)-ItemInfo[] GetItemsByCategory(ID)-ItemInfo[] GetItemsByVendor(ID)-InventoryStatusInfo[] GetStatusOptions()-InventoryStatusInfo GetStatus(int aStatusId)

Item

-OrderInfo Insert(OrderInfo)-OrderInfo GetOrder(orderID)

Order

-CustomerInfo Insert(CustomerInfo)-CustomerInfo Update(CustomerInfo)-CustomerInfo GetCustomer(int aCustomerId)

Customers-void Insert(CategoryInfo)-void Update(CategoryInfo)-void Remove(categoryID)-CategoryInfo GetCategory(id)-CategoryInfo[] GetCategories()

Category

-string[] GetCreditCardCompanies()-int[] GetYearsFromNow()-int[] GetMonths()

CreditCard-PictureInfo Insert(PictureInfo aPicture)-PictureInfo Update(PictureInfo aPicture)-void Remove(int aPictureId)-PictureInfo GetPicture(int aPictureId)-int[] GetPicturesIdsByItem(int aItemId)

Picture

-VendorInfo Insert(VendorInfo aVendor-VendorInfo Update(VendorInfo aVendor)-void Remove(int aVendorId)-VendorInfo GetVendor(int aVendorId)-VendorInfo[] GetVendors()

Vendor

Figure 3: Class Diagrams for Business Logic Tier

OrderThis object is responsible for managing the customer’s order information and shopping cart throughout a session. It also implements the IEnumerable interface to simplify iteration through the items in the cart. Finally, it provides a method to submit the order to the Alumni server.

Customers, Item, Order, Category, Picture, VendorThese objects all function as a façade between the presentation tier and the data tier, providing access to their respective DAL interface methods. Their only responsibility is to validate data, if necessary, before passing it on to the proper DAL implementation, as provided by the DAL factory. Each method then returns the result as returned by the DAL method.

Presentation TierThough the project could not function without the data or business logic tiers, arguably the most important tier is the presentation tier. This is the part of the system with which the users directly interact, and the experience it provides must meet the user’s growing expectations about how the online shopping experience should work. The public storefront has been broken down into six points of customer contact, presented below.

Unified Interface FeaturesOne of the biggest drawbacks to the existing system is the inconsistency found between parts of the shopping experience. The new system maintains a consistent interface throughout the process. Uniform side and top bars provide universal access to important features like the shopping cart and the list of categories, as well as allowing the user to log in from any page. These global elements are implemented using ASP.NET user controls, which allow changes to

the overall design to be made in a single place instead of updating several pages individually. Several individual pages make up the main part of the site, yet each page shares a common “codebehind” file and utilizes the same user controls. This architecture allows quick changes to be made to the entire site, should the client so desire.

Front PageThe front page is essential to the online shopping experience, and must invite the user into the store. The original front page, shown in Figure 4: , provides access to every item in the store, but with only minimal organization.

Figure 4: Old Front Page

Figure 5: New Front Page

The new front page greets the user with a much cleaner interface shown in Figure 5: New FrontPage, presenting a few “Featured Items” and inviting the user to explore their respective categories. The front page also introduces the user to the interface he or she will use for the remainder of his or her shopping experience.

Item Category PagesA user’s likely “next step” will be to visit a category page. Category pages allow the user to view all the items within a category. Additionally, the category page prominently displays a featured item defined by the client. All items have a thumbnail image, the name of the product, and basic pricing information shown at a glance.

Item Description PagesThe original item description pages, as shown in Figure 6: Original Item Description Page, had many limitations that are remedied by the new system. As stated before, all pages of the new store have a consistent look and feel. This extends to the item pages as well as shown in Figure7: New Item Description Page. Item pages also place more emphasis on the benefits of membership, showing precisely how much a nonmember could save, or a member is saving, with membership to the association.

Figure 6: Original Item Description Page

Figure 7: New Item Description Page

Shopping Cart PageThe shopping cart page is designed to emulate many of the popular shopping cart systems in use by stores like Amazon.com and Orvis.com. It also shares a common look and feel with the rest of the site and utilizes the same side and top bars to provide navigation to other parts of the site. Additionally, the user can also log in as an Alumni Association member directly from this page to activate the savings associated with membership.

Order Completion PageThe order completion page shows a summary of the order, complete with the final charges, payment method, and shipping address. The page provides contact information for customers with questions about their order.

Resources and SchedulesResourcesEstimated personal and financial resources predictions are given below as are the final figures for the project. The estimated figures have been revised from figures first presented in the project plan and are presented with the old data for purposes of comparison. The original figures are given in Table 1 and Table 4, and the revised figures are given in Table 2 and Table 5. Final figures are given in Table 3 and Table 6. Project definition and technology considerations were initially well-defined; the majority of the team’s efforts were devoted to the design, testing and implementation phases of the project.

Personal Effort RequirementsThe personal effort required by members of the team has been subject to a few changes based on the needs that have developed given the members’ experiences with ASP.NET, the .NET Framework and overall effectiveness.

Estimated personal effort shown in total hours during the 2004–2005 academic year.

Table 1: Previous Estimated Personal Effort

Member Class Meetings Deliverables Coding Presentation Total

Keith Dahlby 30 55 15 120 10 230

Jordan Jump 30 50 20 100 10 210

Andrew Kirpalani 30 50 35 90 10 215

Jonathan Ruhnke 30 50 25 95 10 210

Total 120 205 95 405 40 865

Table 2: Revised Estimated Personal Effort


Keith Dahlby 30 55 25 120 10.5 240.5

Jordan Jump 30 50 20 100 11 211

Andrew Kirpalani 30 51 25 90 10 206

Jonathan Ruhnke 30 49 20 95 9.5 203.5

Total 120 205 90 405 41 861

Table 3: Final Personal Effort


Keith Dahlby 30 40 30 91.5 8.5 200.5

Jordan Jump 30 40 26 67 8 171

Andrew Kirpalani 30 40 27 61.5 7.5 166

Jonathan Ruhnke 30 38 17 22.5 16 123.5

Total 120 158 100 243 40 661

Financial RequirementsThe estimated budget for the project has changed for two reasons. First, printing the poster was more expensive than anticipated. Second, the revised personal effort estimates yield a slightly decreased estimated labor cost.

Labor estimates based on labor at $12 per hour.

Table 4: Previous Estimated Financial Budget

Item Estimated Cost

Project poster $60.00

Printing & copying $10.00

Binding $5.00

Total without labor $75.00

Labor at $12.00/hour $10380.00

Total with labor $10455.00

Table 5: Revised Estimated Financial Budget

Item Estimated Cost



Binding $17.49


Labor at $12.00/hour $10332.00


Table 6: Final Financial Budget

Item Estimated Cost



Binding $17.49


Labor at $12.00/hour $6610


Project SchedulesThe following Gantt charts summarize the proposed schedules for the project. For legibility, the charts are split between the fall and spring semesters.

Fall 2004 SchedulesID Task Name1 Problem Definition2 Def ine Problem w ith Existing Implementation3 End User(s) and End Use(s) Implementation4 Constraint Identif ication5 Technology Considerations6 Selection of Server OS7 Selection of Database Server8 Selection of WWW Technologies9 End-Product Design

10 Identification of Design Requirements11 Design Process12 Documentation of Design13 End-Product Implem entation14 Identification of Limitations15 Implementation of End-Product16 End-Product Testing17 Test Planning18 Test Development19 Test Evaluation20 End-Product Docum entation21 Store Front-End Documentation22 Administrative Back-End Documentation23 End-Product Dem onstration24 Demonstration Planning25 Faculty Advisors Demonstration26 Client Demonstration27 Industrial Review Panel Demonstration28 Project Reporting29 Review Project Plan w ith Client30 Review Design Report w ith Client31 Weekly Email Reporting32 Project Deliverables33 Initial Project Plan34 Bound Project Plan35 Project Poster36 Initial Design Report37 Bound Design Report38 Final Report

10/512/7

8/29 9/5 9/12 9/19 9/26 10/3 10/10 10/17 10/24 10/31 11/7 11/14 11/21 11/28 12/5 12/12 12/19

Figure 8: Project Schedule — Fall 2004

ID Task Name32 Project Deliverables33 Initial Project Plan34 Bound Project Plan35 Project Poster36 Initial Design Report37 Bound Design Report38 Final Report

8/29 9/5 9/12 9/19 9/26 10/3 10/10 10/17 10/24 10/31 11/7 11/14 11/21 11/28 12/5 12/12 12/19

Figure 9: Project Deliverables — Fall 2004

Figure 10: Revised Project Schedule — Fall 2004

Spring 2005 SchedulesID Task Name1 Problem Definition2 Define Problem w ith Existing Implementation3 End User(s) and End Use(s) Implementation4 Constraint Identif ication5 Technology Considerations6 Selection of Server OS7 Selection of Database Server8 Selection of WWW Technologies9 End-Product Design

10 Identif ication of Design Requirements11 Design Process12 Documentation of Design13 End-Product Implem entation14 Identif ication of Limitations15 Implementation of End-Product16 End-Product Testing17 Test Planning18 Test Development19 Test Evaluation20 End-Product Docum entation21 Store Front-End Documentation22 Administrative Back-End Documentation23 End-Product Dem onstration24 Demonstration Planning25 Faculty Advisors Demonstration26 Client Demonstration27 Industrial Review Panel Demonstration28 Project Reporting29 Review Project Plan w ith Client30 Review Design Report w ith Client31 Weekly Email Reporting

10/512/7

1/9 1/16 1/23 1/30 2/6 2/13 2/20 2/27 3/6 3/13 3/20 3/27 4/3 4/10 4/17 4/24 5/1 5/8 5/15

Figure 11: Project Schedule — Spring 2005ID Task Name32 Project Deliverables33 Initial Project Plan34 Bound Project Plan35 Project Poster36 Initial Design Report37 Bound Design Report38 Final Report 4/25

1/9 1/16 1/23 1/30 2/6 2/13 2/20 2/27 3/6 3/13 3/20 3/27 4/3 4/10 4/17 4/24 5/1 5/8 5/15

Figure 12: Project Deliverables — Spring 2005

Figure 13: Revised Project Schedule — Spring 2005

Closure MaterialProject EvaluationThis section provides a team evaluation on the success of the project. Each milestone was rated independently to determine how well it was met, and a final overall score is given. Possible scores for the milestones are as follows:

Evaluation Result Score

Greatly Exceeded 5

Exceeded 4

Fully Met 3

Partially Met 2

Not Met 1

Not Attempted 0

Project DefinitionThe project had to be well defined before work could begin. The Project Definition was evaluated on how well it described the scope and desired functionality of the project.

Score: Fully Met

Technology Considerations and SelectionThough initial project definitions called for a specific language to be used for the browser oriented part of the system, the project team members still had to research available software technologies for the rest of the system (i.e., database, development environment), that would best suit the project plan and the client’s current systems. An evaluation was given based on how well the final choices fit the requirements laid out for the system.

Score: Exceeded

End-product DesignThe project was designed based on the overall architecture and the specific components that make up the application. This end-product design was evaluated based on how sufficiently and efficiently it fulfilled the functional requirements.

Score: Fully Met

End-product ImplementationAn initial version of the system was fully implemented based on the proposed End-product Design. This evaluation was given based on how closely this implementation conforms to the requirements and design and on how user-friendly the system is to both customers and administrators.

Score: Partially Met

End-product TestingThe initial version was tested to ensure it was secure and free of bugs and errors. An evaluation was given based on how completely the application was tested and problems remedied.

Score: Partially Met

End-product DocumentationThe end-product documentation provides documentation on how to use all parts of the system. An evaluation is given based on the completeness and helpfulness of this documentation.

Score: Not Attempted

End-product DemonstrationThe end-product demonstration involves showing the product, as well explaining the development process, to faculty, students, and the final client. A score is given to evaluate how clearly the demonstration presented the necessary information to the target audience.

Score: Fully Met

Project Reporting/DeliverablesThis category includes the project plan, poster, design report, and final report. An evaluation here describes how well each document served its purpose and the completeness of each.

Score: Fully Met

Overall Project ScoreThe final project score is created by averaging all of the scores from the important milestones as described above.

Overall Score: Partially Met

CommercializationThe Alumni Store is a custom system created specifically for the ISU Alumni Association. Its implementation contains components specific to their needs that are nontransferable. Commercialization was not considered

Recommendations for Additional WorkThis product meets client requirements and requires no additional work to be complete. In the future there are a few additional features that may be added to improve the product and take it beyond simply meeting requirements to the point where it exceeds original expectations. A few features that are currently under consideration for addition in this manner are listed below.

Multiple Product ImagesEach product currently has a single image associated with it. In the future the user control that is used to display images could be modified to allow multiple images to be shown for each product. For example, this could be used to display multiple views of a clothing item.

Extended Category StructuringCurrently the categories only extend one level deep, where as the system could be revised to allow many subcategories to house a larger more complex product line. Presently the Alumni Association catalog is not of sufficient size to warrant this feature.

Frequent Use of Stored ProceduresAs mentioned in the end product evaluation, the use of stored procedures would allow for the data access layer to be simplified greatly, and the database operations would be much more efficient. In the event that the site or database were compromised, security risks involving username/password would be greatly reduced as well.

Database Backup/Recreation ScriptBackup and recreation of the system is currently the responsibility of the client. In the case of a crash, this application would have to be recovered manually, and the recovery of data would be the sole responsibility of the client’s systems. With a built-in script, backup and recreation would become another solid feature of the product.

Lessons LearnedThis section outlines some of the lessons learned by the project team during the two semesters of senior design.

What Went WellThe meeting with the Alumni Association staff, along with good brainstorming, helped to form a very solid design. Though initial specifications called for the use of a specific programming language and database system, the team did a broad but shallow course of research to ensure that other options were not overlooked, and that the team would be aware of other options in the field. This scan of the state of the industry proved useful when the originally specified database was proved inadequate.

What Didn’t Go WellThe initial success in planning an design did not directly translate to success in implementation. Though work occurred throughout the scheduled time period, slow development and failure to account for changes in other parts of the system meant that a good deal of work done early in the development cycle had to be duplicated for the final product. As a result, the workload was not spread out over a healthy length of time and some long hours were required in the last few months.

What Technical Knowledge Was GainedOne of the team members already knew a great deal about C# and ASP.NET development, another had significant C# and legacy ASP experience, other team members had general programming experience as well as some web-based development experience. Due to the differences in philosophy between legacy ASP and the new ASP.NET, Andrew found that his experience with legacy ASP actually hindered his progress with ASP.NET style development. However, over the course of the project, all members developed new skills with the chosen technologies and became comfortable with the associated design philosophies.

What Non-Technical Knowledge Was GainedThis section covers the team’s experiences outside beyond the technical aspect of the project. Lessons in this area relate to team dynamics and management, as well as items relating to non-technical deliverables.

What Would Be Done Differently Next TimeIf the project were to be redone, the team would be more disciplined and vigilant in adhering to the schedule. There were times during development that the team was behind schedule but not aware of or concerned with this schedule slip. This lack of diligence led to a hectic and stressful end of the development cycle.

Risk and Risk ManagementThis section describes potential risks associated with this project as well as the steps and precautions taken to minimize damage should one or more risks manifest themselves. This section will also describe those unanticipated risks that were encountered, and the steps that were taken to manage them.

Anticipated Potential Risks and Planned ManagementWith any software project, the loss or corruption of code during the development process is a risk with potentially disastrous consequences. To mitigate this risk, the team used a source control system (SVN) to manage all code for the project. These systems prevent developers from producing conflicting changes to the code and allow for rollback to working versions should some portion of the project become inoperable. Another major risk was breakdown of communication between team members and the ensuing uncertainty with regard to the status of different portions of the project. This risk was addressed by scheduling a recurring team meeting at the same time every week and by obtaining direct contact information for each team member.

Anticipated Risks Encountered and Success in ManagementSource control prevented any problems the team may have encountered with the code of the project, however, communication proved to be a problem for the team, especially during second semester. Each team member missed at least one meeting due to other commitments, and one team member was nearly unreachable for approximately two weeks due to illness and some other issues. Missed meetings were handled via email, informing the absent team member of what he missed and inviting questions should he be confused or unsure about any aspect of the project.

The problems associated with the unreachable team member were a little more far-reaching and a bit harder to resolve. Every means possible was used to attempt to make contact with this individual, with limited success. Eventually sheer volume of communication seemed to work and he was contacted and brought back up to speed. In the meantime, other members of the projected picked up the slack created by the temporary loss of a team member.

Unanticipated Risks Encountered, Attempts to Manage and SuccessThe only unanticipated risk encountered by the team was that of restricted access to the ISU network for those members developing from off-campus locations. This issue did not affect members living and/or working on campus. ISU provides Virtual Private Network (VPN) software to students living off-campus so that these students can access the secure campus network. Installation of this software in the off-campus development environments solved this problem.

Resultant Changes in Risk Management Made Because of Encountered Unanticipated RisksThe installation of the VPN software solved the access problem for off-campus team members. If this solution had broken down, off-campus team members would have developed from on-campus locations.

Project Team InformationClient InformationISU Alumni AssociationFisher-Nickell Building214 Richardson CourtAmes, Iowa 50011-1370Phone: 515-294-6525http://www.isualum.org/

Project ContactKate BrunsAssistant Director for Electronic CommunicationsPhone: 515-294-2797Fax: [email protected]

Faculty Advisor InformationDr. Srinivas Aluru

Associate Professor3218 Coover HallAmes, IA 50011-3060Phone: 515-294-7387Fax: [email protected]

Student Team InformationKeith DahlbyComputer Engineering, Computer Science1111 Frederiksen Ct.Ames, IA 50010Phone: [email protected]

Jordan JumpComputer Engineering1111 Frederiksen Ct.Ames, IA 50010Phone: [email protected]

Andrew KirpalaniComputer Engineering2408 Knapp St.Ames, IA 50014Phone: [email protected]

Jonathan RuhnkeComputer Engineering4532 Steinbeck St. #107Ames, IA 50014Phone: [email protected]

Closing SummaryThe Iowa State University Alumni Association maintains an online store in order to sell Iowa State branded merchandise that both promotes ISU and raises money for the Alumni Association. Originally, this store was implemented in a very inefficient manner and required a great deal of work and data duplication. This project redesigned and implemented the store in order to save the Alumni Association time and money. The online storefront is both attractive and functional. The new database design minimizes data duplication. Finally, the back-end tool suite has made order processing and filling much easier and more cost-effective. With these improvements in place, the Alumni Association should be able to concentrate the efforts of its staff in other areas, as well as enjoy a larger profit margin from its merchandise.

isu alumni association online store - ecpe senior...

Documents