1 : The Context

1. 1:The Context Presented By: Joe Bolinger 11/3/09

2. Today’s Outline • Why EcoFlow? • What is EcoFlow? • The Concept • The Business Context • The Software

3. Why EcoFlow? • Our purpose • Provide an example of a real project • Our goals • Demonstrate Software Process • Show how it fits the project • Expose Architecture Examples • Show concrete architecture artifacts • Reinforce the discipline of architecting

4. Why EcoFlow • Today’s Purpose • Introduction to EcoFlow • The Business Context • Why invest in a new application?

5. 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”

6. What is EcoFlow?The Business Context • EcoFlow is primarily a methodology of analysis developed by OSU’s Center for Resilience • A standard way of modeling industrial ecology problems • A standard way of engaging multiple industry partners to do the analysis • Initially a Spreadsheet was used to implement the modeling and analysis

7. What is EcoFlow?The Original Software • The Original Spreadsheet • Yes, this is really one page of a spreadsheet!

8. 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

9. What is EcoFlow?The Value Chain

10. 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 spreadsheet • Useable by trained clients with an engineering background • No customization need on a project-by-project basis • Speedup modeling process from data collection to results • More aesthetically pleasing

11. What is EcoFlow?The New Software • EcoFlow Workbench

12. Intermission • Questions? • Next Up • The Development Process

13. 2:The Process Presented By: Joe Bolinger 11/3/09

14. Today’s Outline • Watching the Project Shape • External Factors • I can not change • Internal Factors • I can change • Our Goals • Demonstrate Tailoring the Development Process • Introducing the Pattern Approach • Organizational Patterns • Watch for them today, like “this” • Architecture Patterns, Design Patterns • Next time…

15. EcoFlow Project ShapeExternal Factors • People • 1 part time developer • Remainder of team also part-time • Most customers are geographically remote • Projects • EcoFlow modeling projects were going on before and while the software was being built • Had to transition between spreadsheet and new software as features were added • Sometimes had to go back and forth

16. 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 demands • Also 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

17. 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

18. 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

19. 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

20. 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!

21. EcoFlow Process Artifacts • Example entry on the Wiki’s “Builds Page” • Written by the software developer

22. EcoFlow Process Artifacts • Example design document for a “critical” feature • Written for the software developer

23. 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!

24. EcoFlow Development ProcessTwin Spiders • Two sides of EcoFlow

25. Next Time • Architecture • Questions?