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

Final Report

Project LDROP: Load Dispatch Routing OPtimization

Team Members:

Zachary Paul Faltersack(Spring Team Lead)

Brian Burns(Fall Team Lead)

Stephen Kam

Industry Representatives:

Mr. Andrew McConnell (Accero)

Faculty Advisors:

Dr. Andrew Nuxoll

Other Contributors:

Dawn Burns (Century Propane, LLC)

Jeff Heyerly (Century Propane, LLC)

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE IITEAM HOWELL’S SPECTACULAR THELYPODY

Revision HistoryRev. Date Author Reason for Changes

0.1 20 March, 2011 Zachary Paul Faltersack Customizing template (mostly Technical Outcomes) for LDROP and preparing for assigning parts.

0.2 21 March, 2011 Team Set up basic bulleted list for the process outcome section

0.22 24 March, 2011 Team Put together individually written parts.

0.3 24 March, 2011 Zachary Paul Faltersack Major revisions, working on getting flow

0.9 25 March, 2011 Team Ready for FA feedback.0.95 31 March 2011 APF and BPB Revise based on FA feedback,

upgrade to v.95

0.96 8 April 2011 Team Revisions based on IR feedback1.0 10 April 2011 Team Update to version 1.0

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE IIITEAM HOWELL’S SPECTACULAR THELYPODY

Table of ContentsIntroduction.....................................................................................................................6

Technical Outcomes........................................................................................................7

High-Level Overview................................................................................................7

Model.................................................................................................................7

Controller............................................................................................................7

View...................................................................................................................8

Low-Level Descriptions...........................................................................................8

Connector Package..............................................................................................8

Controller Package............................................................................................10

Editor Package..................................................................................................12

Report Package.................................................................................................20

Process Outcomes.........................................................................................................24

Changes..................................................................................................................24

Change 1...........................................................................................................25

Change 1.1........................................................................................................25

Change 1.2........................................................................................................26

Change 2...........................................................................................................26

Change 3...........................................................................................................26

Change 4...........................................................................................................27

Change 5...........................................................................................................27

Assumptions............................................................................................................27

Milestones...............................................................................................................28

Risks.......................................................................................................................28

Changing Processor Architecture.......................................................................28UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE IVTEAM HOWELL’S SPECTACULAR THELYPODY

Long-term Maintenance....................................................................................28

Hidden Software................................................................................................29

Resource Requirements...........................................................................................29

Conclusions...................................................................................................................29

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE VTEAM HOWELL’S SPECTACULAR THELYPODY

List of FiguresFigure 1 - LDROP block diagram..........................................................................................7

Figure 2 - Project (package) diagram of LDROP...................................................................8

Figure 3 - UML diagram of LDROP Connector package.......................................................9

Figure 4 - UML diagram of LDROP Controller package.....................................................11

Figure 5 - Screenshot of the Main View produced by the Controller.....................................12

Figure 6 - UML diagram of LDROP Editor package............................................................13

Figure 7 - RecordInserter sub classes..................................................................................14

Figure 8 - A screenshot of the Delivery Inserter form...........................................................15

Figure 9 - A screenshot of a CustomerInserter form.............................................................16

Figure 10 - A screenshot of the TankInserter form................................................................17

Figure 11 - Prompt forms.....................................................................................................18

Figure 12 - RecordEditor sub classes....................................................................................19

Figure 13 - A screenshot of a CustomerEditor form..............................................................20

Figure 13 - UML diagram of LDROP Report package.........................................................21

Figure 14 - Example Route Card report................................................................................22

Figure 15 - Example Customers report.................................................................................23

Figure 16 - Example Gallons Sold report.............................................................................24

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE VITEAM HOWELL’S SPECTACULAR THELYPODY

List of TablesTable 1 - Milestones list including target and actual completion dates...................................29

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE 7TEAM HOWELL’S SPECTACULAR THELYPODY

IntroductionLDROP, the Load Dispatch Routing OPtimization or Load Dispatch Routing Optimization Program, is a piece of software designed for tracking deliveries of Liquid Petroleum Gas (LPG) or propane, to residential and commercial customers served by a small LPG retailer. The software tracks when each customer will need a delivery, and organizes daily routes so that drivers of delivery trucks will deliver within one geographic region at a time, increasing the efficiency of their deliveries.

The development of our software was fairly straightforward, but we did encounter some obstacles on the way. One of these obstacles was simply learning the tools with which we were working. We were using an unfamiliar programming language, a relatively unfamiliar Integrated Development Environment (IDE), and some unfamiliar tools such as Crystal Reports, Connector/NET, and MySQL. Each of these un-familiarities contributed some cost in terms of hours spent resolving issues experienced users of these tools might not have encountered.

Some aspects of the implementation of our project turned out to be simpler than expected, however. For example, we were not aware of how much of the interaction the tools such as the Connector/NET would handle for us, and how easy our IDE, Microsoft Visual Studio, would make it to implement the various GUI elements in our project.

The visual design of our GUI forms went very well. They came out nicely, and based on feedback from our clients, they are amply understandable. On the other hand, we could have taken much better advantage of inheritance in designing our GUI forms and other elements of the project. Unfortunately, we have a lot of repeated code throughout that could prove difficult to maintain in the future.

The remainder of this document describes the technical outcomes and process outcomes of our project.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

Model

View

Controller

MySQL Database

C# Logic

MySQL Connector /NET

C# GUI

.........

FINAL REPORT REV. 1.0 PAGE 8TEAM HOWELL’S SPECTACULAR THELYPODY

Technical OutcomesHigh-Level Overview

Our project implements a traditional Model-View-Controller (MVC) architecture, with the code for each of the data model, logical processing, and the Graphical User Interface (GUI) contained in its respective container.

Model

Our data model is comprised of a MySQL database that stores all of the user's information, including customer, tank, delivery, and other information relevant to their business process. The data is access by other parts of the software via the MySQL Connector/NET software available from the developers of MySQL.

Controller

The controller code is the home of the main window, called the Account Viewer, which loads a list of the customers in the database. The controller code is also the home of the MySQL Connector/NET software that interfaces with the database.

View

The view is handled by the Controller, Report, and Editor projects. The AccountViewer has both logic and GUI components, and the AccountViewer generates the view elements contained in the Editor and Report projects.UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

Figure 1 - LDROP block diagram

.........

FINAL REPORT REV. 1.0 PAGE 9TEAM HOWELL’S SPECTACULAR THELYPODY

Figure 2 - Project (package) diagram of LDROP

…The dependencies of the various packages in LDROP are shown in Figure 2. The team previously planned for the Report package to use the database connection set up by the Connector package. This turned out to be unnecessarily difficult, so we modified the design so that the Report package makes its own connection to the database. As we see in the diagram, the Report package no longer depends directly on the Connector package as before.

Low-Level Descriptions

This section describes the internal details of each of the packages described in the High-Level Overview. Readers not concerned with the technical intricacies of the software may skip to the following section, Process Outcomes.

Connector Package

As shown in Figure 2, the Controller and Editor packages use the Connector package to interact with the database. The details of the Connector package can be seen in Figure 3.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE 10TEAM HOWELL’S SPECTACULAR THELYPODY

Figure 3 - UML diagram of LDROP Connector package

The Connector package handles connections to the database and querying the database for other parts of the software. It mirrors the data in the database tables, making them available for C# OOP as collections. Each of the classes in the Controller and Editor packages gets references to each of relevant tables in the DataSet to work with, using pushLocalDataSet() to commit changes to the database.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE 11TEAM HOWELL’S SPECTACULAR THELYPODY

Controller Package

The AccountViewer class is the most important in the Controller package. It generates the main form that lists the customers in the database, and it generates the various forms in the Editor package that the user uses to enter and modify data. A UML diagram of the Connector package is shown in Figure 4.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE 12TEAM HOWELL’S SPECTACULAR THELYPODY

Figure 4 - UML diagram of LDROP Controller package

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE 13TEAM HOWELL’S SPECTACULAR THELYPODY

The Controller package communicates with the Connector package and provides the logic behind the main GUI window, the AccountViewer, that spawns the various forms contained in the Editor and Report packages. A screenshot can be seen in Figure 5 below.

Figure 5 - Screenshot of the Main View produced by the Controller

There is a menu bar that the user can open to obtain access to any of the forms and report options that make up LDROP. In addition, there is a table grid that lists a condensed description of customer accounts, which is able to be filtered by field type and user input.

Editor Package

The Editor package handles all of the data entry and modification the user has with the database. The two types of forms, RecordEditor and RecordInserter both inherit from the DBCommunicator class, which uses the Connector package to interact with the database.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE 14TEAM HOWELL’S SPECTACULAR THELYPODY

Figure 6 - UML diagram of LDROP Editor package

The UML diagram in Figure 6 shows the RecordInserter and RecordEditor parent classes from which each of the forms for interacting with the database inherit, as shown in Figure 7 and Figure 12.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE 15TEAM HOWELL’S SPECTACULAR THELYPODY

Figure 7 - RecordInserter sub classes

The DeliveryInserter class shown in Figure 7 generates the form shown Figure 8. This is the form that the user uses to input information about a customer’s new delivery.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE 16TEAM HOWELL’S SPECTACULAR THELYPODY

Figure 8 - A screenshot of the Delivery Inserter form

This form allows the user to enter information about a new delivery. After the information has been entered the user can press OK to commit the record to the database, or they may select Cancel at any point to ignore the data.

The CustomerInserter class shown in Figure 7 generates the form shown below in Figure 9. This is the form the user uses to enter information about a new customer. After entering the information for a new customer, the software prompts the user to open an editor form for entering tank and delivery information if they choose.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE 17TEAM HOWELL’S SPECTACULAR THELYPODY

Figure 9 - A screenshot of a CustomerInserter form

This form allows the user to enter all the data necessary to create a new customer account. Once the user has finished, they can select OK to create the account at which point they will be prompted to return to the Main View or enter the CustomerEditor form, discussed shortly. Alternatively they may select Cancel at which point the form closes and no account is created.

The TankInserter class has the same functionality as DeliveryInserter and CustomerInserter, except that it is used for entering information about a new tank. A screenshot of the form generated by the TankInserter class is shown in Figure 10.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE 18TEAM HOWELL’S SPECTACULAR THELYPODY

Figure 10 - A screenshot of the TankInserter form

Similar to the previous forms, once a user has entered the desired information they can select OK and commit the new record to the database, or they may select Cancel at which point the form closes and no additional records are created.

There are also two additional classes which are forms to prompt the user for certain information. These are shown below in Figure 11. These two forms prompt the customer to enter data about tanks and deliveries after entering a new customer and prompt the user to update the interval information about a customer.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE 19TEAM HOWELL’S SPECTACULAR THELYPODY

Figure 11 - Prompt forms

The two prompter classes shown in Figure 11 generate the prompter forms mentioned above. The CustomerAddedPrompter prompts the user to enter tank and delivery data about a customer that has just been added to the database. The IntervalSuggester class handles prompting the user to modify a customer’s delivery interval.

Similarly, there are Editor classes that have functionality related to their sister Inserter classes. UML diagrams for these classes are shown in Figure 12. Instead of handing entering new information in the database, the forms generated by these classes allow the user to modify existing data.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE 20TEAM HOWELL’S SPECTACULAR THELYPODY

Figure 12 - RecordEditor sub classes

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE 21TEAM HOWELL’S SPECTACULAR THELYPODY

The RecordEditor subclasses are one area in which the team wishes that it had taken better advantage of inheritance in duplicating functionality between the related forms. There is a lot of repeated code between the subclasses of RecordEditor and the subclasses of RecordInserter that might be difficult to maintain in the future.

The only notable difference in the user interface is with the CustomerEditor form, shown in Figure 13.

Figure 13 - A screenshot of a CustomerEditor form

From here, the user can access all data regarding a customer account. This is all the customer information, all of their tanks, and all of the deliveries made to all of the tanks. This is where the majority of work will be done.

Report Package

The report package uses SAP’s Crystal Reports to generate reports about the number of gallons of product sold, customer lists, and the daily route card used by the client to deliver on a daily basis.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE 22TEAM HOWELL’S SPECTACULAR THELYPODY

Figure 14 - UML diagram of LDROP Report package

The Report package contains its own data set to connect to the database, bypassing the connector package. This turned out to be a much simpler approach when working with Crystal Reports.

There were three reports we were asked to produce. The first report produces a daily list of deliveries that need to be done for the day. These are called Route Cards. A screenshot of an example Route Card can be seen below in Figure 15.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE 23TEAM HOWELL’S SPECTACULAR THELYPODY

Figure 15 - Example Route Card report

This report contains all of the necessary information for making a delivery to a particular tank. This includes identifier information for both the customer that owns the tank and the tank itself. In addition, it has a information to help locate the tank on the property as well as a location for any notes taken during the delivery.

The second type of report was one to list customers, not surprisingly called a Customers Report. An example of one such report can be seen below in Figure 16.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE 24TEAM HOWELL’S SPECTACULAR THELYPODY

Figure 16 - Example Customers report

This report contains a list of customers, which includes their names, the type of account they hold, and their ID number.

The final report produces the number of gallons sold by account type, including the total money received. An example of a Gallons Sold report can be seen below in Figure 17Figure 17.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE 25TEAM HOWELL’S SPECTACULAR THELYPODY

Figure 17 - Example Gallons Sold report

Currently the report displays a ‘type number.’ This is an index indicating the Account Type as a heading. This will eventually become a string that contains a more human friendly representation of the type.

The reports came out rather well. The exact layout for the variety of data is not final. The client has not begun to use this feature yet since they are still filling their database. This is part of the reason for the unpolished appearance of some of the reports. We decided other issues were more immediately important. Once they begin producing these reports we will work with them to finalize a layout suited to their taste.

Process OutcomesIn this section we will discuss how our design and development processes worked and could have been made better. In addition we will see how well our expectations and predictions from the Design Document were met.

Changes

In our Design Document we outlined, in detail, the structure of this project. As can only be expected, the design evolved over the course of the project. Our final design does not differ in

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE 26TEAM HOWELL’S SPECTACULAR THELYPODY

many great details from the one we outlined; there are however several notable exceptions, explained here.

Change 1

One of the first changes that we made was to add two tables to the database. These contain the Account Types that a customer can have as well as the Region they belong to. Originally we had intended on these being Enum type column fields within the Customer table in the database. During the development process we realized that the MySQL Enum type is static in that once the field is declared, no new elements can be added. While it was not a specific request of our client, we assumed that it is likely that they may expand into new regions and add new account types. We needed to come up with a way to allow our client to include these new additions if they should decide it was required.

Our solution was to add these two tables and create columns in the Customer table that index into the appropriate Account Type and Region. In this way it is simple to add new records into the tables that represent new types or regions that have become necessary. We felt this was a reasonable change to make because the database is already small.

We made these decisions very early in the development process during the time we were creating a stable database. We needed a reasonably stable database in order to begin to develop and test our other pieces of functionality. This allowed us to explore these issues early before any real amount of code had been written. As such, our development plan was hardly affected.

We could have caught this issue sooner had we decided that the client should be able to create new account types and define new regions. The reason we did not catch it was because it was not actually a piece of required functionality, so we didn’t even consider the issue earlier in the design phase.

Change 1.1

The introduction of these tables prompted two more slight design changes. The first was a matter of human readability. When these accounts are viewed on the main window, we did not want the Account Type and Region columns to display just the index of the value, but rather a more human friendly representation of the desired value. When the records are displayed in the table, we would need a database lookup for each cell containing one of these values. That would be two database lookups per record printed. We felt the overhead of these operations would begin to be noticed once the database got to a certain size, so an alternative was needed to keep this at a reasonable speed.

Luckily we realized that, although new records may be added to the Account Type and Region tables, they would always be relatively small tables. This prompted the idea of reading these two tables into associative arrays on startup, so that we can quickly retrieve the string representation for display to the user.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE 27TEAM HOWELL’S SPECTACULAR THELYPODY

This addition worked very well. The decision to do this was put off for a long time and wasn’t made until nearing the end of our major development phases. We actually had rolled out a test release to the client before this issue was even addressed. This decision was easy to put off because it was a feature that just made a difference in readability. All the functionality of the rest of the project worked fine without addressing this need.

Change 1.2

The second change was in updating the DataSet in our Connector package. With two new tables, we had to ensure that we could actually access the data in them, which required us to update our internal representation of the database. This change also made no impact in terms of development time, due to the tools Microsoft supplied in Visual Studio 2010, the development environment we used. There is a feature called a ‘Server Explorer’ where you can register databases on remote or local servers. Once they’re registered and a connection has been made, a list of all the tables is displayed and you simply drag-and-drop the tables you want into the main screen and a DataSet is created that reflects the structure of the database tables you chose.

Both of these changes could not have been foreseen without knowing that the two new tables were going to be there. Had the original design included these tables, it is very likely we would have caught these issues sooner.

Change 2

Another change we made again involved the database. We were assuming that at any given point we would have some certain set of information – primary keys – available that we could use to retrieve appropriate records from the database. During the development phase we realized that not all of the information we needed was always immediately or even easily accessible. This prompted some consternation until we realized that we could redefine our primary keys with the data we did have.

This change was not one to easily have caught earlier on. Part of the problem was that we did not really know exactly what information we would have available. It was not until we were actually trying to access records within the database that we realized it would be difficult in the current design. Luckily, these changes actually helped the development process by making it easier to access data and pull the records we needed.

This change did not have very far-reaching effects. The only real change it required was to update the Connector package’s internal representation of the database again.

Change 3

Originally we had intended on the Connector package being the only one to directly interact with the database. Conceptually this was very appealing because we could define our own mini-API for accessing data exactly how we wanted to anywhere in the program. Much to our surprise, it turned out that it was actually much simpler to define a separate form of access specifically for the Reports package.UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE 28TEAM HOWELL’S SPECTACULAR THELYPODY

This was a result of the type of functionality that Crystal Reports provided. It turned out that the designer that is used to create reports has extensive filtering options we were not aware of at the onset of our design and implementation. These provided a much more refined way for us to filter the data that we wanted for each specific report.

To take advantage of this, we created a DataSet within the Reports package that retrieved a copy of the tables required for a specific report and then pass the table to Crystal Reports where it was then filtered for the specific records that were desired.

This change occurred fairly late in the development phase because we had not slated any milestones that addressed this functionality earlier. We were again lucky in that this modification actually made our job easier and so did not negatively affect our project or progress.

Change 4

This ‘change’ is more a clarification. In our design document we had declared that an internal representation of the database was not necessary due to the functionality provided by the MySQL Connector/NET API. What we later realized was that this API used a DataSet to store retrieved data in. So in reality, we do have this internal representation.

We had originally meant there was no need to programmatically define an internal structural representation of the database. The difference was that rather than do it within code we were able to use Microsoft Visual Studio 2010 (MSVS2010) tools to replicate the database as a DataSet. MSVS2010 provides a tool called the ‘Server Explorer.’ This feature allows the developer to register remote or local servers and databases and explore their tables via dropdown lists. The tables can be drag-and-dropped into the main window and MSVS2010 and the Connector/NET API create a DataSet that reflects the internal structure of the tables from the chosen database. Further, the connections and appropriate adaptors are also auto-generated, thus removing any need for the developer to create and handle these connections within their code.

This was how we planned on structuring the Connector package; we just overlooked the fact that this was happening within our project and wrote it up incorrectly within the Design Document. As such, it had no effect on our project.

Change 5

Our original design called for a separate Connector from the Connector package for each table in the database. This proved incredibly inefficient as we would occasionally need multiple Connectors within a single project. A Connector is an instance that interacts with the database, retrieves a copy of a table and returns it to the caller. To fix this, we created a way to define a set of interests for a given instance of a Connector. These interests indicate which tables the Connector can access and modify. There are several reasons we took this approach. The first is that it allowed for each project to define a single Connector rather than one for each table it needed. Secondly, it inhibits the reach of the UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE 29TEAM HOWELL’S SPECTACULAR THELYPODY

Connector so that it can only modify data relevant to its current task. This provided an extra layer of security preventing the accidental modification of records within the database.

Assumptions

The assumptions that were listed in our Functional Specifications document were as follows: Client and server machines are operational with operating systems installed and

running User is capable of using a keyboard and mouse to interact with the software User has the necessary operating system privileges to load and execute programs

All of these assumptions held true throughout the course of the project, as they were necessary for the client to be able to use our product. We currently don’t have any extra assumptions besides the ones that are listed in our Functional Specifications document.

Milestones

Overall, we were able to meet most of the milestones that we had listed on time. We ended up being late on some of the milestones, particularly while implementing the Editor functionality and the Reports.

Table 1 - Milestones list including target and actual completion dates

Number Description Target Date Completion Date

1 First version of MySQL database functioning 15 Oct. 2010 15 Oct. 20102 Hello World in C# using MS Visual Studio 29 Oct. 2010 29 Oct. 20103 Interaction between C# code and MySQL database 5 Nov. 2010 5 Nov. 2010

4 Simple C# GUI with database information populating text fields 12 Nov. 2010 12 Nov. 2010

5 Database structure finalized 19 Nov. 2010 19 Nov. 20106 GUI forms constructed 21 Jan. 2011 23 Jan. 20117 Adding, removing, editing customer tanks functions 28 Jan. 2011 18 Feb. 20118 Adding, removing, editing deliveries functions 4 Feb. 2011 18 Feb. 20119 Software successfully produces route cards 11 Feb. 2011 24 Feb. 201110 Software produces gallons sold reports 18 Feb. 2011 24 Feb. 201111 Interval suggestion feature functions 25 Feb. 2011 25 Feb. 201112 Remainder reports functionality completed 4 Mar. 2011 4 Mar. 201113 Unit test construction completed 11 Mar. 2011 11 Mar. 201114 Testing completed 25 Mar. 2011 25 Mar. 201115 Bug fixes completed 1 Apr. 2011 1 Apr. 201116 Software brought to demonstration state 8 Apr. 2011 8 Apr. 2011UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE 30TEAM HOWELL’S SPECTACULAR THELYPODY

17 Successful Project Demonstration 12 Apr. 2011 To Come

As can be seen in Table 1 above, the majority of our milestones were either completed on time or within a few days of the target date. More details regarding the progress of our project throughout the implementation can be found in our program review slides. Many of the issues that arose and caused us to miss these milestones were due to our lack of familiarity with the tools we were using. For example, we set some milestones in an order that did not take into account cross-dependencies between them.

Risks

The risks that were listed in our Functional Specifications document were as follows:

Client desires too much flexibility with reports and forms

Encountering unexpected needs required to support core functionality

New system is difficult for clients to adopt

A team member becomes sick enough to be unable to complete their assigned sections

None of the risks that were listed on our Functional Specifications document proved to be very risky, and as such, we didn’t have to fall back to our contingency plans.

Changing Processor Architecture

One of the issues that occurred quite frequently was the compatibility of the product on 32-bit and 64-bit systems. This arose because while most of the team was designing using 64-bit systems, one of the members was using 32-bit system instead. Since we weren’t aware of some of the open problems that Visual Studio has with viewing forms on these different machines, the 32-bit machine did run into issues that were unable to be replicated on the 64-bit machine. This further complicated the overall process because the product would appear to be working perfectly for the majority of the team, but run into issues on another machine.

Long-term Maintenance

Another issue was that we hadn’t planned for the deployment and future development as much as we should have. This lead to some concerns as to what method would be used to place the product on the client's machine, as well as what was the best way to maintain it. To better support future development, we need a bootstrapper solution that determines exactly what libraries and runtime environments are required to run our software; as it is, we had to install our entire development environment on the client's machine in order to get our releases to run. Additionally, the team should invest in an installer that cleanly upgrades existing installations with updates.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE 31TEAM HOWELL’S SPECTACULAR THELYPODY

Hidden Software

A final issue that arose was that the Crystal Reports version that we were using during the design process was still in its beta release. When the actual release arrived and the beta version was discontinued, we ended up dealing with a lot of unforeseen issues that caused us to be late for some of our milestones. As such, we should have looked up the release date along with any change logs so that there would be an easier transition to the released installment.

Resource Requirements

The amount of time that was spent on this project was about the same overall that we had predicted it to be. We did spend more time on the connector package and in dealing with C# than we had estimated to, as due to the fact that we weren’t as fully aware of the material as we thought we were, we were unable to take full advantage of it. On the other hand, we did spend less time on the GUI material than we had estimated. We were correct in estimating that we didn’t require a budget, given that all of the programs that we needed were either free or made available through the university. The only resource that we ended up using was the Senior Design room for both brainstorming and coding sessions.

ConclusionsLDROP is a database management system designed for Century Propane, LLC in order to help them track customers and their deliveries, as well as produce reports summarizing a variety of data as requested by the client. We successfully implemented every piece of functionality they requested at the onset of the project, as well as some they requested throughout the implementation phase.

It was a bumpy road, and we did not hit every milestone perfectly on time; however we do feel that every milestone was completed within reasonable margins of error. Occasionally one was missed, most often due to poor planning. Another mistake involved the ordering of our milestones, which was not always correct in terms of getting our dependencies satisfied before continuing work on a new piece of functionality.

Regarding the design, we are very pleased with its modular structure which allows new pieces of functionality to be incorporated relatively easily. It is likely that several members will continue to work with the client for a period during the summer to ensure we have properly tailored LDROP to Century Propane’s needs. The modularity provides an exciting opportunity to really introduce novel additions our client may not have realized they wanted or needed at an earlier point.

More specifically, we are pleased with the Connector package. With a better understanding of how all of our various components work together we were able to make a well-defined object UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK

.........

FINAL REPORT REV. 1.0 PAGE 32TEAM HOWELL’S SPECTACULAR THELYPODY

with a custom API that allows us to access data from anywhere in our program in a uniform manner. This also means that, should we need to access data in a way previously unexpected, we can implement it for the given form and the change is propagated to all other projects. Further, the manners in which tables are retrieved and records are accessed make it very easy to make changes or additions and then commit them back to the database.

It would be nice if our original plan of using the Connector package as the sole form of interaction with the database had proven better founded. As was mentioned, the change to the design provided cleaner code and made the reports easier to produce. The original plan is just much more appealing from an aesthetic standpoint.

Regarding the process, we feel that our milestones could have been more explicit and had more of them at lesser intervals. Alternatively, we could have been better about splitting up the tasks relevant to each milestone in a way that we could easily track progress in a day-by-day fashion. What we noticed was that virtually no work would be done during the majority of the week followed by a stressful crunch the couple of nights preceding a milestone. While it may seem like more of a pain, being forced to produce work at a more regular rate would very easily have allowed us to fly ahead of schedule.

Another important point to stress is: Play to the strengths of your team members. Or even just be aware of them. Not everyone is good at the same things. We did this in several areas and could have done it in several more. For example, the designing of the database was left to Brian and Stephen because they had taken a databases course and had more knowledge in this area than Zachary who had not yet taken it.

An example of where we should have taken this more into account was when assigning tasks for a milestone. It is important to make sure that a weaker programmer is not given too much work for a given period of time. It can seem desirable to assign the same quantity of work to each member of a team. Unfortunately this leaves very little margin for error and unforeseen challenges can quickly push a project behind schedule. It is much better to ask those with greater programming ability to try and complete more tasks. Then, should someone complete their tasks, they can be delegated more work from someone who has uncompleted tasks.

Overall this was an extremely enlightening and fun project. A major contribution to our enjoyment was in the knowledge that our product would be used in a real-world business environment. This provided motivation in a way previously un-experienced by any member of our team. We are very pleased with the final result and are excited to continue communication with our client and hear (hopefully) that it was everything they wanted and expected. In addition, the experience of producing the Functionality Specifications and Design documents, while frustrating in the moment, was actually interesting and insightful.

We would like to conclude with thanks to Century Propane, LLC for giving us the opportunity to work with them and for entrusting us with the design and development of LDROP, allowing us to grow and mature as programmers in the real world.

UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: ZACHARY PAUL FALTERSACK