1: The Context

Presented By: Joe Bolinger

11/3/09

Today’s Outline

Why EcoFlow?

What is EcoFlow?The ConceptThe Business ContextThe Software

Why EcoFlow?

Our purpose Provide an example of a real project

Our goalsDemonstrate Software Process Show how it fits the project

Expose Architecture Examples Show concrete architecture artifactsReinforce the discipline of architecting

Why EcoFlow

Today’s PurposeIntroduction to EcoFlow The Business ContextWhy invest in a new application?

What is EcoFlow?The Concept

“An innovative decision support tool that helps maximize the financial and societal benefits of industrial ecology – converting waste to profit”

“Eco-FlowTM is the first software tool that couples visual editing of network structures with real-time mathematical optimization”

What is EcoFlow?The Business Context

EcoFlow is primarily a methodology of analysis developed by OSU’s Center for ResilienceA standard way of modeling industrial ecology

problemsA standard way of engaging multiple industry

partners to do the analysis

Initially a Spreadsheet was used to implement the modeling and analysis

What is EcoFlow?The Original Software

The Original Spreadsheet Yes, this is really one page of a spreadsheet!

What is EcoFlow?The Organization

Center for Resilience Faculty Directors Organized industry collaborators to start by-product-synergy

networks, raise awareness, publicize results EcoFlow is just one tool they are using to engage clients

Graduate students Carried out daily interactions with industrial clients Collected data, built & interpreted EcoFlow models, discussed results

with clients Acted as a “shield” of some complexity Sometimes acted as a “buffer” to prevent conflicts or ensure

confidentiality among clients that may want some details kept private

What is EcoFlow?The Value Chain

What is EcoFlow?The New Software

Limitations of a spreadsheet implementation Each project required a customized spreadsheet Time consuming & difficult to customize Very difficult for industrial clients to use directly Not visually appealing or captivating to clients

Goals of a new EcoFlow desktop application Same functionality as spreadsheetUseable by trained clients with an engineering backgroundNo customization need on a project-by-project basis Speedup modeling process from data collection to resultsMore aesthetically pleasing

What is EcoFlow?The New Software

EcoFlow Workbench

Intermission

Questions?

Next UpThe Development Process

2: The Process

Presented By: Joe Bolinger

11/3/09

Today’s OutlineWatching the Project Shape External Factors I can not change

Internal Factors I can change

Our GoalsDemonstrate Tailoring the Development Process Introducing the Pattern Approach Organizational Patterns

Watch for them today, like “this”

Architecture Patterns, Design Patterns Next time…

EcoFlow Project ShapeExternal Factors

People1 part time developerRemainder of team also part-timeMost customers are geographically remote

ProjectsEcoFlow modeling projects were going on before and

while the software was being builtHad to transition between spreadsheet and new

software as features were added Sometimes had to go back and forth

EcoFlow Project ShapeInternal Factors

Developer “Firewalls” & “Surrogate Customers”Requirements negotiated with service team internally Only representative of the “expert” user Could have sought out more input from “normal” users but deliberately

choose not too – for now!Prevented requirement variability due to specific customer

demandsAlso lead to some awkward features For example, tried to satisfy all our targeted customers by designing an

encryption feature – even though we know it would seriously limit usability Disaster!

Threw it out completely in favor of satisfying most customers

EcoFlow Project ShapeInternal Factors

Shared “Work Queue” or “Backlog” and “Group Validation”All Stakeholder were very technical in their fields and expected a

technically competent team Also only one 1 developer… No one wanted to read any sort of plan Not everyone would actually admit this

we did try at times

Visible work queue of around half a dozen planned features became cornerstone of planning & expectations Negotiated in person and then re-stated with comments on a Wiki where

prototype builds were posted prior to a review In person group review followed

EcoFlow Project ShapeInternal Factors

“Implied Requirements” versus a “Smoke Filled Room” EcoFlow can be split along two major lines

The Interface & User Experience Developer knew how to design this better (in our case)

The Mathematical Modeling & Correctness of Results Other stakeholders knew this better

For UI and experience aspects quick discussions of the desired features were favored over detailed requirements discussions Prototypes were the vehicle for communication More discussion often lead to strange design

The core modeling & analysis features were hammered out though lengthy group discussions, frequent meetings, and additional design documents If this was not done correctly nothing else mattered

EcoFlow Project ShapeExternal & Internal

Question: Should the external forces drive the internal decisions?

Looks like some did Geographic distance implies a surrogate customer

Once the “core” functionality was implemented the distance from the customer became more visible

This strategy would probably lead to an “expert-only” implementation if left unchecked forever

1 Developer implies less structured work products Initially, the stakeholders wanted more design oriented artifacts, like user stories and

use cases But they were never very effective Why? They are software engineering techniques – not so good for general

communication When? As the team became more comfortable with the use of prototypes they

stopped asking

EcoFlow Project ShapeExternal & Internal

Question: Should the external forces drive the internal decisions?

Looks like some did Geographic distance implies a surrogate customer

Once the “core” functionality was implemented the distance from the customer became more visible

This strategy would probably lead to an “expert-only” implementation if left unchecked forever

1 Developer implies less structured work products Initially, the stakeholders wanted more design oriented artifacts, like user stories and use

cases But they were never very effective Why? They are software engineering techniques – not so good for general communication When? As the team became more comfortable with the use of prototypes they stopped

asking

One should not drive the other exclusively!

EcoFlow Process Artifacts

Example entry on the Wiki’s “Builds Page”Written by the software developer

EcoFlow Process Artifacts

Example design document for a “critical” featureWritten for the software developer

EcoFlow Development ProcessRecap

Very agile with a focus on prototypes

Most valuable activities Prioritized work queue Stakeholder feedback using prototypes

More structured design and analysis methods used for “critical” features This is also where the most domain knowledge needed to be transferred to the

developers

Collaborate but avoid over using tools or leaking techniques Stakeholders may not really know how to design a UI so don’t let them do it

alone Use cases are good techniques for software engineers but poor tools for general

communication with stakeholders

Stakeholders drive development but not the process!

EcoFlow Development ProcessTwin Spiders

Two sides of EcoFlow

Next Time

Architecture

Questions?