PIPE-FLO Looking Forward

Estimated Reading Time: 6 minutes 19 seconds. Read Later

Looking at the Past & Preparing for the Future

At Engineered Software for the last 30 years we have continually upgrading our products to take advantage of improvements in computer hardware, programming language, and operating systems, but the major focus of our updates has always been to better meet our customer’s needs. Over the years PIPE-FLO has been upgraded ever 12 to 18 months. Every 7 to 10 years we have a Milestone upgrade in which major program changes take place to take advantage of new technology. We are currently in the final stages of developing our latest Milestone upgrade, which has been three years in the making.

In the early years of computer programming, maybe the mid to late-1980s, software businesses never released version 1 because they believed customers would be hesitant to be the first adopters. Quite often, version 1 was a beta, and this was way before the public would be willing to use beta software. So, in 1982 we released PIPE-FLO version 2.

The major objective of PIPE-FLO 2 was to develop quality, shrink-wrapped software for designing fluid piping system that could be used on computers using the CP/M operating system, along with the recently released IBM® PC. The program was written in C-Basic and used Access Manager so we could take advantage of all ASCII terminals (all text no graphics).

We developed a variety of companion programs (NET-FLO, ORI-FLO, PUMP-FLO, and CON-FLO) using this technology; each capable of reading PIPE-FLO’s pipeline database. Another major first for PIPE-FLO was our use of a graphical interface. Using our NET-FLO/CAD interface and AutoCAD® by Autodesk; our customers were able to insert piping system information into an AutoCAD drawing. PIPE-FLO then read the information from the drawing, set up the piping system model, calculate the results and updated the AutoCAD drawings showing the calculated results. It was well received, but the major drawback was our customer had to own AutoCAD.

 

Windows the First Milestone Upgrade 

 

In 1985 Microsoft released Windows as a graphical interface. After completing PUMP-FLO™ for Windows in 1986, we started thinking of incorporating the Windows graphical interface into PIPE-FLO. To accomplish this, PIPE-FLO had to be completely re-written using the C programing language. During this rewrite we incorporated the functionally from both our existing PIPE-FLO and NET-FLO programs, in to a single Windows application which we called PIPE-FLO version 4. 

PIPE-FLO 4 utilized a commercial database, allowing our customers to build piping systems of any size while employing automatic backup protection. Version 5 and 6 were based on this technology and during this time we integrated the drawing of the piping system directly into PIPE-FLO. We also released our utility programs for pump selection, control valve selection and flow meter sizing programs as Windows applications with the capability of reading the PIPE-FLO’s Pipeline Database. 

Our customers really liked the integrated flow sheet drawing along with the ease of use offered by Windows. In talking with our customers, they wanted us to make it easier for PIPE-FLO to select equipment such as pumps, control valves, and flow meters. In addition, they wanted to share their project with others in their company as well as customers and vendors they work with.

 

Security, Integration, and Ease of Operations 

 

In 1998 we decided to embark on next Milestone upgrade, PIPE-FLO version 7, with a final release in 2000. During this major rewrite we decided to stop using the commercial database employed in PIPE-FLO versions 4 through 6 and developed a proprietary data structure for the Piping Project. Thus introducing the .pipe file extension type into the lexicon. This allowed us to speed up disk operations, create smaller project files, and allow for easier sharing of the piping system model. We also tightly integrated the three stand-alone utilities for pumps, control valves, and flow meters into PIPE-FLO.

Another major goal was to achieve consistency of operation with other Windows applications. For example we modified PIPE-FLO’s drawing tools to reflect the operation of common CAD programs such as AutoCAD®, Visio®, and Pro/ENGINEER, this way our customers already knew how our drawing tools operated. In addition, we made our list view to look and feel more like a spreadsheet providing the opportunity to sort the list, choose items to work on, and even giving them the ability to edit on the list. The PIPE-FLO Viewer program was also introduced allowing customers to share interactive piping system models created by PIPE-FLO Professional without the other individual needing the full PIPE-FLO program. Finally the X-Link feature allowed for two-way communications between PIPE-FLO and Microsoft® Excel®. 

Our customers continually provide suggestions on ways to improve PIPE-FLO. Recently we have noticed that many of their suggestions deal with workflow within their organization. For example, engineering firms wanted to develop their own customized reports and share information with other departments (both engineering and purchasing). Our customers at industrial plants were looking for easier ways to build a PIPE-FLO model using data from other programs. 

 

Third Milestone Upgrade

 

In 2009 we started working on our third Milestone upgrade. Our product development team had grown to five engineers, six application developers, and two test developers. To accommodate this larger team we needed to streamline our internal development process so we employed the Agile development process and integrated our program testing into every stage of product development.

Regarding PIPE-FLO, we determined the upgraded program must have the same functionality as earlier versions of PIPE-FLO, but we wanted to make it easier for our customers to integrate the software in their workflow processes. 

To accomplish this, our engineers started categorizing every customer support ticket and feature request looking for ways to streamline and clarify program operations, improve consistency, and provide the added features that our customers had requested. Next they started evaluating other commercially available software including engineering, business, and software development applications.

After reviewing the programs they developed a list of guiding principles for the Milestone upgrade:
   •    Minimize the use of dialog boxes whenever possible
   •    Increase consistency of operation within the PIPE-FLO program as well as other software tools used by our customers. (CAD, Microsoft Office®, engineering analysis tools, etc.)
   •    Make it easy for PIPE-FLO to incorporate new program features in the future

With this list of goals, our engineering team started developing “stories” for all existing PIPE-FLO features. These stories document how the feature worked, how the customer used the feature, the required data input, formula used to calculate the results, along with how the results would be used.

Once each story was defined they were reviewed by the developers to help them determine how the final program would work. With the big picture provided by the various stories, the software developers created “objects” that compartmentalized the task that can be re-used for the various program elements. This is mostly behind the scenes but manifests in the ability to add new features much quicker later on. The PIPE-FLO calculation engine was also compartmentalized allowing the developers to supply the piping system data to the engine, and then utilize the calculated results.

This required major revisions to ever stage of program development. Approximately half of the development effort involved building the internal program infrastructure to provide flexibility of the engineering units, develop the various program objects, and passing of information to the various objects. Once the infrastructure was developed the various piping system elements (pumps, controls, components, tanks, pipelines, etc.) were incorporated into PIPE-FLO using the pre-defined objects.  Using this approach the engineering team was able to work with the actual PIPE-FLO program through the majority of the development cycle with new program elements being continually added.  Using this approach and the Agile development process we were able to fine tune the user interface as new components were added.

The final step in the development process was implementing the user interface items. This included multiple object selection, the addition of the printed reports and graphs, along with the ability to extract and work with input data and calculated results.

Multiple object selection is one of the major new program features. In the most previous version of PIPE-FLO, you could only select similar items in a rectangular selection window and once selected the objects could be copied, deleted, or moved. In this upcoming milestone update, you can select a group of object in a rectangle/s, select individual items from the flow sheet, select individual or multiple items from the list view, as well as de-select items. In other words, our group select tool is identical in operation to group selection tools in CAD programs and Microsoft’s Excel. Once a group of items are selected you can copy and move the objects, edit the design data, change the text font, or insert a note in a single step. This feature even applies across object types. For example, in the new PIPE-FLO, both tanks and pipelines have fluid zones, using the multiple select tool you are able to change the fluid zone in the selected pipelines and tanks in a single step. 

Multiple object selection is just one of the many new and time saving features in the next release of PIPE-FLO.  In the coming weeks we will be releasing more information about the next release of PIPE-FLO, but the biggest secret is the name for the next release, for that you must wait.

Here's a sneak peek at the upcoming version of PIPE-FLO. Make sure to send me your comments and thoughts on the new look and feel. CLICK the image to view larger.

Testing 1, 2, 3...

Estimated Reading Time: 5 minutes 26 seconds. Read Later

The Importance of Product Testing

As mentioned in my September blog, Engineered Software will be celebrating 30 years in business in 2012. In that post I listed the core value we have followed to better meet our customer’s needs and expectations, specifically:

1. Create a sustainable company
2. Create product that can be used by a wide variety of people, not just engineers
3. Play well with others.

In this month’s blog I will be sharing with you how our software testing has evolved over the years.

When we started Engineered Software both Carolyn Popp and I (the two founding principles) saw the value of developing a testing program for our software. Our feeling was, if we released a program that had a calculation error, our customers might not trust our new company. In addition, if the customer had trouble entering the necessary data or lost data due to a problem with the program, we were not providing them with the value they expected. For the first version of PIPE-FLO, we developed a series of program features; the formulas the calculations were based on, along with a set of example calculations. These example calculations included a variety of edge cases designed to test the program source code.

I developed a series of test problems from text books, technical publications such as the Crane Technical Paper 410, along with developing a series of calculations performed using an electronic calculator (remember 1982 pre-dated Lotus 123 and Microsoft’s Multi-Plan). A set of calculations sheets were developed complete with the equations, references, all input values, along with intermediate and final calculated results. Prior to every program release, these examples were entered manually into PIPE-FLO and the results validated. Carolyn, a former IBM system engineer, was just as adamant on program testing and validating prior to program release.

Our third & fourth employees, Jaclyn and Kathleen Byron (we often called them J&K), both with mechanical and civil engineering degrees, were hired to improve our program testing, provide customer technical support, and assist in software development. Based on their customer interaction they were able to created test procedures to validate all engineering calculations along with the user interface. They also were responsible for automating the test procedures by developing test scripts for each program feature.

When one of the software developers finished a new PIPE-FLO feature, J&K created an automated test, and checked the results. Any problems with the new feature were brought to the attention of the programmer and resolved. Once we had a PIPE-FLO release candidate, we would perform all automated tests again to validate the software results prior to release. The release testing took approximately 2 – 4 weeks to complete, allowing the correction of last minute program bugs, along with a review of the test results.

As our company grew, we added more programmers and engineers to our development team. In 2006 we decided it was time to update our software development and testing practices by implementing the Agile Software development process.

The major impact was to document the proposed program features and so everyone knows how the feature works. The process starts by engineers creating “stories” for each feature describing how customers used the feature. The application developers would write the program code to meet the requirements listed in the “story”, and the developers in test would develop the testing needed to ensure PIPE-FLO meets the “story” requirements.

Testing is now broken down into unit stages:

• Unit Testing
• Integration Testing

To demonstrate I’ll use an example for calculating the fluid Reynolds number. First engineering first creates a “story” defining the Reynolds number calculation, the data that must be supplied, and a variety of examples with the calculated results.

The application developers create a function for calculating the Reynolds number. The new function is placed in the function library used by all developers that need to calculate the fluid Reynolds number. In addition the developer creates a “unit test” based on the example calculations supplied by engineering in the “story.” The unit test is then placed in the unit test library that is run every time the program is compiled by any developer.

Now let’s say the developer creating the orifice sizing feature needs to calculate the fluid Reynolds number of the orifice. The software developer will use the previously defined Reynolds number function. If the function needs to be modified for the orifice sizing calculations, (say using the orifice diameter instead of the pipe diameter) then the Reynolds number function in the library may be modified by the developer writing the orifice feature. Once a developer compiles the program on their local computer the Reynolds number unit test will be performed to insure nothing was changed that would give bad Reynolds number results for either the pipeline or orifice Reynolds number calculation. If the test fails the developer knows immediately there is a problem in the Reynolds number function and makes the necessary correction.

Once the developer has completed the orifice sizing feature on their computer they check in their code to a central build server. The build server is where all programs are compiled for release. Once the code is checked in on the build server all unit tests are performed on the code, if any problems occur the developer is notified immediately. The build server performs all unit tests each time any one of the application programmers check in their source code.

Integrated Tests are developed by a separate group of programmers that specialize in software testing. The developers in test create the integrated tests to ensure the program’s higher level features work as called out in the “story.” The majority of these tests are developed to test PIPE-FLO’s user interface.

For example in PIPE-FLO the pipeline graph window shows the fluid Reynolds number over a range of flow rates. The developers in test will create an integrated test to check that the graph window is acting as defined in the story. For example the integrated test may check to see that the Reynolds numbers are graphed and displayed and the user also has the ability to change the color.

In the past the integrated testing was conducted when the feature was initially added to the program, and at the completion of the program prior to program release. The time difference between initially adding the feature releasing the program could be measured in months. During that time span a developer may make a change in a new feature that has an effect on a previously tested feature.

With our new automated testing once an integrated test is written to test a feature it is added to the test suite on the testing server. Every night the test server performs all automated tests.

In the evening, the test server takes that day’s program from the build server and loads it to the test server. The test server loads the current program onto multiple computers on the test farm. The test server then assigns the various integrated test to each computer and keeps track of the results. Currently there are about 10 computers in our testing farm and it takes approximately 6 hours to perform the test and review the results.

The next morning each member of the development team can check to see if the code they wrote yesterday has an adverse effect of the program development. If any of the tests fail the developer will be notified and can make the necessary changes that day.

This testing has paid off for both Engineered Software and our customers. In the last two versions of PIPE-FLO we have only had to issue one maintenance release to correct problems associated with the program. A more reliable program means less stress for such important engineering choices, and our aim is to make our customer’s job easier.

I would love it if you left a comment or even sent me an email to blogger @ eng-software.com. Also, we are currently welcoming guest bloggers. If you are interested, just send me a message about becoming a guest blogger, and what you would like to write about. Thanks for reading!